WhatsApp, la aplicación de mensajería más utilizada del planeta, basa parte de su éxito en la sencillez: basta con añadir un número a la agenda para saber si esa persona usa la plataforma y poder ver su foto de perfil. Lo que millones de usuarios perciben como comodidad se convirtió, sin embargo, en la puerta de entrada al que podría ser el mayor acceso no autorizado a datos personales jamás documentado: la exposición de prácticamente todas las cuentas de WhatsApp a nivel mundial.

Un equipo de investigadores de la Universidad de Viena y SBA Research demostró que, sin técnicas avanzadas ni intrusiones, era posible reconstruir el directorio completo de la plataforma, accediendo a 3,5 mil millones de números, además de fotos de perfil, textos públicos, claves criptográficas y otros metadatos sensibles.

Según los propios autores, si esta extracción masiva hubiera sido realizada por delincuentes y no como parte de una investigación realizada por profesionales éticos, estaríamos hablando de "la mayor filtración de datos de la historia".

¿En qué consistía el fallo?

WhatsApp permite saber si un número existe en la plataforma simplemente añadiéndolo como contacto. Esta funcionalidad, pensada para facilitar la comunicación, no contaba con limitaciones de velocidad ni mecanismos anti‐explotación en ciertas interfaces, especialmente en WhatsApp Web.

Los investigadores no hicieron más que automatizar lo que cualquier usuario puede hacer manualmente:

1. Generar números válidos de todo el mundo.
2. Consultar a WhatsApp si esos números tenían cuenta.
3. Descargar los datos públicos asociados.

El sistema no detectaba actividad excesiva ni bloqueaba peticiones, lo que permitió realizar 100 millones de comprobaciones por hora. Así, entre diciembre de 2024 y abril de 2025, con solo cinco cuentas autenticadas y un servidor universitario, lograron consultar 63 mil millones de números y confirmar 3.5 mil millones de cuentas activas.

Qué datos quedaron expuestos

• Números de teléfono: El dato básico, pero también el más sensible: un identificador personal único y persistente.
• Fotos de perfil y mensajes 'info': El 57% de los usuarios tenía su foto visible a cualquier desconocido, y un 29% mostraba texto público con información personal —a veces extremadamente delicada— como afiliaciones religiosas, políticas o incluso enlaces a redes como Tinder u OnlyFans. Sólo en Norteamérica, la descarga de fotos visibles supuso 3.8 terabytes de imágenes. En un muestreo, dos tercios contenían rostros reconocibles mediante algoritmos de reconocimiento facial.

En Genbeta

Si acabas de actualizar WhatsApp en Windows, verás que su consumo de RAM se ha multiplicado. Hay una razón para eso

• Claves criptográficas y metadatos técnicos: De forma inesperada, los investigadores accedieron también a claves públicas utilizadas para el cifrado de extremo a extremo. No se comprometieron mensajes, pero sí se identificaron 2.9 millones de casos de reutilización de claves (un grave problema de seguridad).
• Información sobre dispositivos vinculados: WhatsApp revelaba cuántos dispositivos tenía asociada cada cuenta, un dato que puede sugerir hábitos de uso o prácticas sospechosas (como el uso múltiple en redes de spam) .

Un riesgo desigual según el país

Los datos permitieron construir un mapa detallado del uso global de WhatsApp. Entre los hallazgos más llamativos:

• India: 749 millones de cuentas; el 62% mostraba foto pública.
• Brasil: 206 millones; 61% con foto visible.
• Estados Unidos: 137 millones; 44% con foto y 33% con texto público.
• Irán: 60 millones pese a la prohibición vigente de la app, un riesgo enorme para los usuarios si el Estado hubiese accedido a la información.
• China: 2,3 millones de cuentas pese a la prohibición oficial que impera también en China respecto a la app de Meta.

Una crisis de privacidad estructural

Los investigadores señalan que la raíz del problema no es solo la ausencia de límites de consulta, sino el propio uso del número de teléfono como identificador universal. Los números telefónicos:

• son fáciles de enumerar,
• siguen patrones conocidos por país,
• no están diseñados para servir como credenciales secretas.

Por tanto, cualquier plataforma basada en ellos queda expuesta a ataques de enumeración masiva. Sin un ritmo de consulta extremadamente limitado, la privacidad depende más de la opacidad por volumen que de la seguridad real. WhatsApp parece haber tomado nota: ya ha empezado a testear un sistema de nombres de usuario, que podría reducir esta dependencia del número telefónico.

La respuesta de Meta: ocho años tarde

El primer aviso documentado sobre esta vulnerabilidad se remonta a 2017, cuando un investigador independiente ya demostró la posibilidad de enumerar números y perfiles. Meta respondió entonces que la aplicación funcionaba 'según lo diseñado' y no consideró el hallazgo como un error remunerable en su programa de recompensas. En 2024 y 2025 los avisos se multiplicaron, pero Meta no actuó hasta que la publicación del estudio era inminente.

En Genbeta

Signal vs. WhatsApp: las grabaciones que la Guardia Civil posee de Santos Cerdán desvelan un curioso debate sobre qué app es más segura

Finalmente, en octubre de 2025 implementó una limitación del ritmo de consultas que bloquea la automatización a gran escala. La compañía, sin embargo, insiste en que:

• toda la información expuesta era 'pública',
• no hay pruebas de que actores maliciosos explotaran el fallo,
• y los mensajes siempre permanecieron cifrados.

Los investigadores, por su parte, afirman que no encontraron defensa alguna durante la extracción y que no está garantizado que otros actores no hayan realizado la misma operación en los años previos.

Consecuencias potenciales: del spam al peligro físico

La reconstrucción del directorio global de WhatsApp abre la puerta a múltiples abusos:

• Estafas y spam: Una base de 3.5 mil millones de números activos es oro puro para redes de phishing, fraudes financieros y campañas automatizadas.
• Doxxing y extorsión: Las fotos públicas y textos personales permiten identificar a individuos, asociarlos a perfiles sociales o incluso a ubicaciones, gracias a elementos visibles en las imágenes .
• Persecución estatal: En países donde la aplicación es ilegal, la mera enumeración masiva permitiría detectar y localizar a quienes la utilizan.
• Robo de identidad y cruces con otras filtraciones: La exposición coincide con bases filtradas previamente, como la fuga de Facebook de 2021, lo que facilita correlaciones peligrosas .

¿Qué pueden hacer los usuarios?

Aunque Meta ha corregido el fallo, la exposición ya ocurrió. Expertos recomiendan:

• Configurar foto de perfil, 'info' y privacidad de conexión como datos visibles sólo para sus contactos.
• Evitar información personal sensible en la sección 'info'.
• Revisar dispositivos vinculados y eliminar aquellos desconocidos.
• Desconfiar de mensajes sospechosos, especialmente si provienen de números extranjeros.
• Considerar el uso de alias o nombres de usuario cuando la función esté plenamente disponible.

Vía | Wired

Imagen | Marcos Merino mediante IA

En Genbeta | Mi móvil estaba "secuestrado" por 70 GB de chats y archivos de WhatsApp: así logré vaciarlos sin perder nada

En el mundo de la ciberseguridad, encontrar vulnerabilidades reales en sistemas y programas es una tarea compleja, laboriosa y sumamente valiosa. Por ello existen los llamados bug bounty programs —programas de recompensas por errores—, mediante los cuales empresas e instituciones pagan a investigadores de ciberseguridad por reportar fallos de seguridad antes de que los delincuentes puedan localizarlos y explotarlos. Los pagos pueden llegar a ser millonarios.

Sin embargo, en los últimos meses ha emergido una nueva amenaza inesperada: las vulnerabilidades falsas inducidas por la IA. Y es que estamos experimentando una oleada de "descubrimientos" inexistentes que está inundando las plataformas de referencia de bug bounty como HackerOne o Bugcrowd, en un intento de usuarios por conseguir recompensas rápidas sin hacer investigación real.

El fenómeno ha alcanzado tal nivel que incluso proyectos emblemáticos como cURL, una de las herramientas más utilizadas de la red, han tenido que tomar medidas drásticas: bloquear de inmediato a quienes envían reportes generados por IA.

Qué está pasando realmente

El caso de cURL es ilustrativo. Su responsable principal, Daniel Stenberg, recopiló recientemente decenas de reportes de 'vulnerabilidades' supuestamente críticas enviadas al programa oficial de recompensas de la herramienta. Los títulos suenan bastante alarmantes:

• “Buffer Overflow Vulnerability in WebSocket Handling”
• “HTTP/3 Stream Dependency Cycle Exploit”
• “Use of Deprecated strcpy() with Fixed-Size Buffers”

Pero tras una revisión mínima, se descubrió que ninguna de ellas tenía la más mínima base técnica. Los informes repetían patrones comunes de descripciones generadas por IA: lenguaje vago, ejemplos de código inventado, ubicaciones de archivo incorrectas y referencias a funciones inexistentes.

En Genbeta

Siete hackers se hicieron millonarios 'cazando' vulnerabilidades en 2019: qué son los programas de 'bug bounty' que lo hacen posible

En palabras de los propios responsables del proyecto:

"Nuestra política actual establece que banearemos instantáneamente a todos los que envían 'AI slop'".

El término AI slop (literalmente 'papilla de IA') es uno de esos que seguramente estará generalizado en unos meses: se usa ya en varios entornos para describir contenido de baja calidad generado por modelos de lenguaje (coherente a simple vista, pero carente de sustancia técnica o de verificación factual).

Cómo se detecta el 'slop' generado por IA

Los responsables de seguridad están desarrollando estrategias para filtrar automáticamente este tipo de reportes. Como decíamos, algunos indicios comunes son:

• Repetición de frases idénticas en múltiples informes.
• Referencias a funciones, rutas o ficheros que no existen.
• Código de ejemplo que no compila o carece de coherencia lógica.
• Falta total de Proof of Concept (prueba de concepto) o de exploit verificable.

La economía del bug bounty y los incentivos perversos

Los bug bounty programs ofrecen incentivos financieros legítimos: grandes empresas como Google, Meta o Apple pagan entre cientos y miles de dólares por vulnerabilidades comprobadas. Esto ha generado un ecosistema de investigadores, muchos de ellos 'freelance', que dedican su tiempo a auditar código y buscar errores reales.

Pero con la expansión de herramientas generativas, apareció una tentación obvia: ¿y si una IA puede redactar un informe convincente de 'caza de bugs' sin que el supuesto experto se moleste en hacer su trabajo?

En Genbeta

Vio que podía ganar dinero arreglando bugs... y empezó a crearlos a propósito. Cinco ejemplos de malos incentivos para programadores

Algunos usuarios han empezado a alimentar a modelos con repositorios completos de código fuente y pedirles que 'encuentren vulnerabilidades', o simplemente que inventen ejemplos plausibles. En cuestión de minutos, generan descripciones que parecen profesionales y las envían a plataformas de recompensas.

El resultado: un volumen creciente de reportes falsos, que consumen tiempo de revisión y reducen la confianza en los investigadores legítimos.

Un problema ético y de confianza

Todo esto no es más que un reflejo de un fenómeno que afecta a toda la red: la sobreproducción de contenido artificial sin verificación humana. Lo que antes era un campo de perfil técnico y hasta artesanal —la búsqueda de vulnerabilidades— se está viendo colonizado por el mismo ruido que invade la escritura, el arte o las redes sociales.

La IA puede ser una aliada poderosa en ciberseguridad —para análisis estático, detección de anomalías o simulaciones de ataque—, pero sólo si se usa con criterio y bajo supervisión humana.

El impacto de este fenómeno va más allá del tiempo perdido. Los bug bounty dependen de la confianza entre las partes:

• La empresa asume que quien reporta actúa de buena fe.
• El investigador confía en que su trabajo será valorado justamente.

La llegada de reportes fabricados por IA erosiona esa relación. Los equipos de seguridad se vuelven más escépticos y los verdaderos investigadores pueden ser penalizados injustamente por la desconfianza generada.

Además, existe un dilema ético: ¿debería considerarse válido el uso de IA como apoyo para analizar código, siempre que el resultado sea verificado por una persona? La frontera entre asistencia legítima y fraude automatizado es cada vez más difusa.

Imagen | Marcos Merino mediante IA

En Genbeta | El 'vibe coding' hará que cada vez escribamos menos código. Así que los ingenieros de software tendrán una tarea titánica 

En el vasto mundo de los torrents —esa red de intercambio descentralizada que muchos asocian con la descarga no autorizada de películas, pero que también sirve para distribuir software libre como distribuciones de Linux o modelos de inteligencia artificial— hay piezas clave que suelen pasar desapercibidas: los trackers.

Recientemente, un usuario con las dosis suficientes de curiosidad y habilidad decidió averiguar qué sucedía con esos trackers muertos que aparecen en las listas de muchos clientes de torrent como qBittorrent.

¿Qué es un tracker de torrents?

Un tracker es como un punto de encuentro para los clientes de torrent. No contiene los archivos en sí, pero sí indica quién los tiene. En otras palabras, cuando tú bajas un archivo vía BitTorrent, tu cliente se comunica con el tracker para saber qué otros usuarios tienen partes del archivo y cómo conectarse con ellos.

Aunque existen métodos más descentralizados, como la DHT (Distributed Hash Table), los trackers siguen siendo cruciales para que muchos torrents funcionen con fluidez. Sin ellos, compartir archivos se vuelve más difícil, más lento y menos fiable.

Pero, una vez conectados, la descarga puede proseguir incluso sin el tracker, si hay una red activa de peers. Por eso, algunos archivos sobreviven durante años, circulando entre usuarios sin depender de servidores centrales.

El experimento: revivir un tracker muerto

Durante una descarga particularmente lenta, el protagonista de esta historia se percató de que la mayoría de los trackers en su cliente estaban muertos: los dominios ya no existían o no respondían. En ese momento se le ocurrió una idea brillante (y un poco temeraria): ¿Qué pasaría si él mismo registrara uno de esos dominios caídos?

Eligió 'open.demonii.si', un antiguo tracker que parecía abandonado, y procedió a comprar el dominio. Luego, alquiló un servidor privado virtual anónimo y configuró allí el software opentracker, uno de los más ampliamente usados para esta tarea.

Con unos pocos comandos en Linux, compiló e instaló el software necesario, y preparó el entorno para que actuara como tracker. Y luego, simplemente, esperó.

En Xataka

Trackers privados de BitTorrent: antiguos, inaccesibles, pero sorprendentemente vivos

El despertar de los muertos: millones de conexiones

Antes siquiera de iniciar el servicio, el servidor comenzó a recibir una avalancha de tráfico en el puerto UDP 1337. Cuando activó el tracker oficialmente, la magnitud de lo que había hecho se hizo evidente: en apenas una hora, su servidor había recibido conexiones de más de 3 millones de usuarios (peers) y estaba rastreando cerca de 1,7 millones de torrents diferentes.

Estos resultados demuestran que, aunque el dominio original estuviera caído, los clientes de torrent en todo el mundo habían seguido intentando comunicarse con él todo este tiempo. Muchos de estos dispositivos estaban ejecutando clientes de BitTorrent antiguos, descargando archivos o simplemente "sembrando" (compartiendo archivos) sin intervención humana desde hace años.

Experimento finalizado

En el pasado, las autoridades de algunos países han perseguido a sitios como The Pirate Bay por alojar y promover contenido con derechos de autor. Sin embargo, simplemente operar un tracker —sin hacer publicidad, sin ofrecer archivos directamente ni inducir a la infracción— estaba en una zona bastante gris desde el punto de vista legal (al menos en la jurisdicción desde la que opera nuestro usuario).

Por eso, su experimento fue breve y decidió cerrar todo rápidamente por precaución. Como él mismo señala, el haber pagado el dominio con una tarjeta de crédito ya había sido un paso que comprometía su anonimato. Poco después, borró el servidor y liberó el dominio.

¿Qué aprendemos de esto?

Esta claro que la infraestructura de Internet no se borra fácilmente: Dominios muertos, direcciones olvidadas o servicios caídos pueden seguir generando tráfico durante años. Pero el experimento de este usuario deja claro algo aún más importante: cualquiera con conocimientos técnicos puede revivir partes importantes de la red P2P.

En este caso, se hizo con fines de investigación, pero también podría ser explotado con fines maliciosos: cualquier persona con control sobre un dominio que alguna vez fue usado como tracker puede ver quién se conecta, qué archivos están intentando compartir y con qué frecuencia.

En Genbeta

Esta web de torrents española cambia de dominio tres veces al mes para sortear los bloqueos de las operadoras. Lo están logrando

Esto abre la puerta a varios vectores de ataque o vigilancia:

• Vigilancia masiva no autorizada: Al controlar el tracker, un atacante puede registrar millones de IPs y deducir qué archivos comparten, y hay que tener en cuenta que algunos de los cuales pueden ser sensibles.
• Ataques dirigidos: Un atacante podría identificar clientes vulnerables (por software desactualizado) y lanzar ataques específicos contra ellos.
• Inyecciones maliciosas: En casos extremos, si el cliente es vulnerable, un tracker malicioso podría enviar respuestas manipuladas que comprometan la máquina del usuario.

En esencia, un simple experimento revela una grieta en la arquitectura del software que millones de personas aún usan sin saberlo. Un servidor muerto puede revivir con fines benignos… o no tanto.

¿Qué se puede hacer?

Algunas posibles acciones para mitigar este tipo de situaciones incluyen:

• Limpiar archivos torrent antiguos: Revisar y eliminar trackers obsoletos de archivos .torrent aún activos.
• Actualizar los clientes de BitTorrent: Las versiones antiguas pueden contener fallos de seguridad.
• Limitar el tiempo de actividad de archivos inactivos: Los usuarios pueden configurar sus clientes para que cierren torrents no utilizados tras cierto tiempo.
• Promover el uso de DHT y PEX: Tecnologías descentralizadas que eliminan la necesidad de trackers.

El problema de la persistencia digital

Este fenómeno también arroja luz sobre la persistencia del software. A diferencia de los humanos, los programas no "olvidan" si no se les dice que lo hagan. Y, por eso, la infraestructura obsoleta puede permanecer activa en segundo plano, generando ruido y, potencialmente, vulnerabilidades.

Imagen | Marcos Merino mediante IA

En Genbeta | Las mejores webs para descargar torrents que siguen funcionando en 2024 

En marzo de 2016 ocurrió un suceso insólito que puso en evidencia la fragilidad de nuestra infraestructura digital: un sencillo y poco conocido paquete 'open source' compuesto de tan sólo 11 líneas en JavaScript, fue eliminado por su autor del repositorio NPM (una referencia para los programadores web de todo el mundo), y eso bastó para que buena parte del ecosistema de desarrollo web colapsara durante varias horas. ¿Cómo fue posible que algo tan pequeño tenga consecuencias tan enormes?

La historia del paquete left-pad lo explica todo. El paquete left-pad tenía una función muy simple: agregar caracteres a la izquierda de una cadena de texto para que alcanzara una longitud específica: por ejemplo, convertir el número '7' en '007', una tarea trivial que cualquier programador podría escribir en minutos.

Sin embargo, precisamente por su trivialidad, tenía sentido prescindir de reescribir las mismas 11 líneas una y otra vez, por lo que el paquete que las contenía fue ampliamente adoptado como dependencia en otros proyectos, muchos de ellos fundamentales en el ecosistema JavaScript: Babel, Webpack, React... entre muchos otros.

En la práctica, el correcto funcionamiento de millones de proyectos terminó dependiendo, directa o indirectamente, de este pequeño fragmento de código.

El detonante: una disputa por un nombre

Azer Koçulu, el desarrollador que mantenía left-pad (y otros muchos paquetes), se vio envuelto en una disputa con la empresa Kik Messenger: ésta reclamaba para sí el nombre del paquete 'kik' en NPM, pese ser anterior a la fundación de dicha compañía. Todo se torció cuando los responsables del repositorio favorecieron la postura de Kik y expropiaron al desarrollador de la propiedad del nombre para transferírsela a la empresa sin el consentimiento de Koçulu.

En protesta, Koçulu decidió retirar todos sus paquetes de NPM, una lista compuesta de casi 300... que incluía al ya mencionado left-pad. El problema, como decíamos, era que muchos proyectos dependían de left-pad para poder construirse o instalarse. Así que, cuando el paquete desapareció del repositorio, innumerables desarrolladores de todo el mundo comenzaron a ver errores al intentar compilar o ejecutar sus aplicaciones.

En Genbeta

El gestor de paquetes NPM, usado para difundir malware entre los desarrolladores de aplicaciones NodeJS

Durante varias horas, amplios sectores del ecosistema de JavaScript quedaron paralizados. No es que las aplicaciones web dejaran de funcionar: pero nuevas instalaciones y despliegues fallaban, especialmente en entornos de integración continua (CI/CD). Y 'NPM' tuvo que reaccionar reinstaurando (de nuevo a espaldas de Koçulu) el paquete con el mismo nombre, algo que normalmente no está permitido, debido a la urgencia de la situación.

En definitiva, un episodio bastante movido que terminó generando todo un debate ético y técnico sobre la gobernanza del software libre.

¿Qué aprendimos? (¿O qué deberíamos haber aprendido?)

Este incidente puso de relieve varias lecciones clave sobre el desarrollo de software moderno:

• La interdependencia extrema: un software aparentemente insignificante puede estar en el corazón de cientos o miles de otros sistemas.
• Falta de redundancia: muchas empresas dependían de servidores externos sin tener copias locales de sus dependencias.
• Gobernanza y control: los conflictos entre desarrolladores independientes y plataformas centralizadas como NPM pueden tener consecuencias técnicas de gran alcance.
• Licencias abiertas y sus límites: left-pad estaba bajo la licencia WTFPL ('Do What The Fuck You Want With It', algo así como "Haz lo que te dé la pulcra gana con esto"...y sí, existe), que permite hacer prácticamente cualquier cosa con el código. Esto facilitó su reinstauración, pero también ilustró los riesgos de tener software crítico sin responsabilidad clara.

El caso de left-pad nos recuerda que gran parte de la tecnología que usamos a diario se sostiene sobre proyectos de código abierto mantenidos por personas que, muchas veces, no reciben compensación alguna. Esta situación sigue vigente hoy. Por eso, además de utilizar software libre, es crucial apoyarlo: económicamente, con tiempo o al menos con reconocimiento.

Porque, al final, todo Internet puede terminar dependiendo de un puñado de líneas de código escritas por un desarrollador solitario en su tiempo libre.

Pese a ello, pocos fueron los que aprendieron la lección. Esa falta de aprendizaje quedó patente con otro incidente aún más grave: Log4Shell.

Log4Shell: cuando todo volvió a fallar

En diciembre de 2021, se descubrió una vulnerabilidad crítica (CVE-2021-44228) en Log4J, una biblioteca de código abierto usada para registrar eventos en aplicaciones Java. Este fallo permitía la ejecución remota de código, lo que convertía a millones de servidores en objetivos accesibles para los atacantes.

La respuesta fue veloz: en apenas 24 horas, los mantenedores —tres voluntarios que trabajaban en su tiempo libre— lanzaron un parche. Sin embargo, el escándalo fue otro: ¿cómo era posible que una biblioteca esencial para empresas multimillonarias estuviera mantenida por tres personas no remuneradas, personas que tuvieron que pasarse toda una noche sin dormir para evitar problemas masivos de ciberseguridad?

Volvía a reverlarse un patrón familiar: el corazón tecnológico de las mayores corporaciones del mundo late gracias a esfuerzos individuales poco reconocidos, y peor aún, precarizados: estos desarrolladores, lejos de recibir apoyo, fueron víctimas de ataques injustos mientras intentaban contener el desastre.

En Genbeta

El respaldo a los proyectos 'open source', motivo de una cumbre en la Casa Blanca convocada para evitar casos como el de Log4Shell

¿Cómo evitar el próximo "left-pad"?

La caída de left-pad debía habernos enseñado sobre la fragilidad del ecosistema de software libre (que es como decir el ecosistema de todo Internet). Pero no aprendimos. En lugar de reforzar los cimientos del open source, las grandes tecnológicas continuaron capitalizando sus beneficios sin invertir proporcionalmente en su sostenimiento.

La solución no pasa solo por hacer forks o tener listas copias de respaldo de los paquetes. Amplios sectores del mundo del código abierto y/o el desarrolló web piden tomar medidas:

1. Financiación estable: patrocinios, fondos públicos y modelos sostenibles que remuneren el mantenimiento.
2. Gobernanza comunitaria: evitar que proyectos críticos dependan de una sola persona.
3. Auditoría y mantenimiento continuo: establecer estándares mínimos de seguridad, testing y actualización.
4. Cultura de la dependencia consciente: no importar paquetes triviales solo por conveniencia.

Imagen | Marcos Merino mediante IA
En Genbeta | Qué fue de los programadores que hace dos años trabajaron gratis para evitar pérdidas millonarias a grandes tecnológicas

Microsoft está decidida a transformar la experiencia del usuario en Windows 11 recurriendo a la inteligencia artificial. En su conferencia Build, la compañía anunció la integración nativa en el mismo del MCP (Model Context Protocol), abriendo así la puerta a una nueva era de automatización inteligente de las funciones y aplicaciones de su sistema operativo.

Pero, al igual que ocurrió hace tiempo con ActiveX y OLE Automation en Microsoft Office e Internet Explorer, esta ambiciosa iniciativa también podría convertirse en un problema de seguridad de enormes dimensiones.

¿Qué es MCP y qué propone Microsoft?

El Model Context Protocol (MCP) fue presentado por la empresa Anthropic hace apenas seis meses como un protocolo estandarizado para que las aplicaciones con funciones de IA puedan acceder a datos de distintos sistemas. Sin embargo, su evolución (como su éxito) ha sido rápida: ahora se perfila como la base para una automatización más generalizada, no solo dentro de una aplicación, sino entre múltiples servicios.

MCP permite que los servidores —locales o remotos— informen sobre sus capacidades y reciban comandos para ejecutar tareas. Con base en eso, el objetivo de Microsoft es ambicioso: que un solo comando, en lenguaje natural, pueda iniciar una cadena de acciones que abarquen desde la recopilación de datos hasta la creación de gráficos en Excel y el envío automático por correo electrónico.

Windows será un 'sistema operativo para agentes'

Con la inclusión de MCP en Windows, Microsoft quiere convertir el sistema operativo en lo que llama un "agentic OS": un entorno donde los agentes de IA pueden ejecutar acciones complejas en nombre del usuario. Para hacerlo posible, se introducirán varias novedades:

1. Registro local de MCP: permitirá descubrir los servidores MCP instalados.
2. Servidores MCP integrados: expondrán funciones del sistema como el acceso al sistema de archivos, manejo de ventanas y el Subsistema de Windows para Linux (WSL).
3. 'App Actions': una nueva API que habilita a las aplicaciones de terceros a exponer sus propias acciones como servidores MCP, facilitando la automatización entre apps.

Ya se han anunciado colaboraciones con empresas como Figma, Perplexity, Zoom, Todoist y Spark Mail, lo que evidencia el interés de la industria por esta infraestructura.

Automatización sí, pero ¿a qué precio?

A pesar del potencial de MCP, los riesgos de seguridad son considerables. El propio David Weston, vicepresidente de seguridad empresarial y del sistema operativo en Microsoft, advirtió sobre siete vectores de ataque que amenazan esta arquitectura:

• 'Cross-prompt injection': comandos maliciosos que modifican las instrucciones del agente.
• Falta de autenticación robusta: estándares actuales inconsistentes e inmaduros.
• Filtración de credenciales.
• 'Tool poisoning': uso de servidores MCP no verificados que podrían estar comprometidos.
• Ausencia de contención entre procesos.
• Escasa revisión de seguridad en muchos servidores MCP.
• Riesgos en la cadena de suministro, por la inclusión de servidores maliciosos.

En Genbeta

Microsoft lanzó una IA capaz de verlo todo en Windows 11, pero fue retirada por seguridad. Este experto no cree que esté lista aún

Estos problemas son las que recuerdan a las vulnerabilidades históricas de ActiveX y OLE Automation en Office, tecnologías que, aunque facilitaron una tímida automatización primigenia, también fueron explotadas por ciberdelincuentes durante años.

¿Cómo planea Microsoft mitigar estos riesgos?

Microsoft asegura que la seguridad es su máxima prioridad. Para ello, ha propuesto una serie de medidas:

1. Proxy intermediario: gestionará todas las interacciones MCP cliente-servidor para aplicar políticas de seguridad, auditoría y consentimiento.
2. Nivel de seguridad base para los servidores MCP: incluirá requisitos como firma de código, pruebas de seguridad en las interfaces y declaración de privilegios necesarios.
3. Aislamiento en tiempo de ejecución y permisos granulares, que limiten las acciones según contexto y origen.

No obstante, muchas de estas medidas no estarán disponibles a tiempo para la 'preview' inicial que se proporcionará en unas semanas a los desarrolladores.

Lecciones del pasado: ¿se repetirá la historia?

Para entender los riesgos del Model Context Protocol (MCP), basta con echar la vista atrás a las tecnologías de automatización que Microsoft ha impulsado en el pasado. Dos ejemplos especialmente ilustrativos son ActiveX y OLE Automation, pilares fundamentales para la automatización en Office y otros productos de Microsoft durante décadas, pero también notorias por su historial de vulnerabilidades.

ActiveX: el caballo de Troya en Internet Explorer

ActiveX, introducido en los años 90 como una forma de ejecutar componentes COM dentro del navegador Internet Explorer, prometía enriquecer la experiencia web con formularios interactivos, reproductores multimedia, herramientas de edición, etcétera. En teoría, permitía a las páginas web ofrecer funcionalidades similares a las de una aplicación de escritorio... en la práctica, ActiveX fue un desastre de seguridad.

Debido a su alto nivel de permisos y escasa contención, los controles ActiveX podían ejecutar código arbitrario en el sistema del usuario. Esto permitió a atacantes distribuir malware simplemente con que el usuario visitara una página web: así, se convirtió en un vector común de infecciones por troyanos, keyloggers y spyware. Aunque Microsoft implementó más tarde medidas como el 'killbit' o el uso de zonas de seguridad, el daño a la reputación de esta tecnología ya estaba hecho.

OLE Automation: el truco detrás de los macros maliciosos

Por otro lado, OLE Automation permitió que algunas aplicaciones de Office, como Word y Excel, interactuaran con otras aplicaciones y sistemas a través de scripts y macros escritos en VBA (Visual Basic for Applications). Esta capacidad convirtió a Office en una poderosa herramienta de automatización empresarial... y también en una de las puertas de entrada favoritas para ataques basados en macros maliciosos.

En Genbeta

Claude 4, la nueva IA de Anthropic, amenazó a sus ingenieros con difundir su información privada si se atrevían a desconectarlo

Durante años, los cibercriminales aprovecharon las macros de Excel y Word para ejecutar cargas maliciosas, descargar ransomware o establecer puertas traseras en los sistemas. Incluso hoy, a pesar de restricciones recientes (como la desactivación por defecto de macros descargadas de Internet), OLE y VBA siguen siendo un vector relevante de ataque, especialmente en entornos corporativos donde estas funciones aún se utilizan.

El paralelismo con MCP

MCP comparte con estas tecnologías un principio fundamental: permitir que diferentes componentes —sistemas, aplicaciones y ahora agentes de IA— se comuniquen entre sí para automatizar tareas. Pero lo hace desde un nivel más alto de abstracción y, sobre todo, con una nueva capa de inteligencia artificial.

Este salto conceptual añade utilidad, pero también amplifica los riesgos. Un agente de IA que tenga acceso a múltiples servidores MCP podría, por ejemplo, consultar datos privados, modificar archivos, lanzar aplicaciones, o enviar correos... con una sola orden maliciosa si no se han establecido límites claros.

Además, como ocurre con ActiveX y OLE, el éxito de MCP dependerá en gran medida de cómo se regulen los servidores de terceros. Sin una verificación estricta de estos componentes —algo que Microsoft ha dicho que planea hacer... en un futuro—, MCP podría abrir la puerta a un nuevo tipo de ataque: uno orquestado por agentes conversacionales.

¿Será diferente esta vez? La historia demuestra que cuando la automatización es demasiado poderosa y accesible sin suficientes controles, los atacantes no tardan en explotar sus debilidades. Si bien Microsoft ha mostrado más conciencia de estos riesgos desde el principio con MCP, aún queda por ver cómo se implementarán sus promesas de seguridad en entornos reales.

Imagen | Marcos Merino mediante IA

En Genbeta | Excel bloqueó las macros para evitar la entrada de malware, pero la alternativa que nos ofrece también es cada vez menos segura

Google ha lanzado una actualización de emergencia de su navegador Chrome con el objetivo de solucionar una vulnerabilidad crítica que, según se había descubierto, los hackers habían identificado antes que ellos y se habían asegurado de empezar a explotarla antes de que se lanzaran parches.

Identificado como CVE-2025-2783, este 'bug' permite a los atacantes sortear las protecciones del navegador y ejecutar código malicioso en sistemas Windows.

Según Kaspersky, la empresa de ciberseguridad que dio la voz de alarma, los responsables de haber estado haciendo uso de esta vulnerabilidad serían un grupo APT (de 'amenaza persistente avanzada') patrocinado por un Estado, que estarían ejecutando una operación de ciberespionaje altamente sofisticada, que ha sido bautizada como Operation ForumTroll.

¿Qué es la vulnerabilidad CVE-2025-2783?

CVE-2025-2783 es una vulnerabilidad de alta gravedad (con una puntuación CVSS de 8,3 sobre 10), que afecta al sistema de comunicación entre procesos (IPC) utilizado por Chromium en entornos Windows: se trata de un error lógico en la interacción entre Chrome y el sistema operativo Windows, lo que permite burlar el 'sandboxing' del navegador, una de las principales barreras de seguridad que permite aislar la ejecución de código malicioso en el sistema del usuario.

La operación ForumTroll

Los investigadores de Kaspersky destectaron que el ataque comenzaba con un e-mail de phishing personalizado que contenía enlaces falsos, supuestamente relacionados con el foro académico ruso Primakov Readings.

En Genbeta

Este troyano puede tomar el control de tu PC y afecta especialmente a usuarios de Google Chrome: Microsoft lanza una alerta

Las víctimas eran incitadas a hacer clic en dichos enlaces, que redirigían a sitios maliciosos controlados por los atacantes.

Una vez abierto el enlace desde Google Chrome en un sistema Windows, el exploit se activaba automáticamente, sin requerir acciones adicionales por parte del usuario, lo que deja clara su peligrosidad.

El objetivo final era el espionaje y la obtención de información confidencial, de forma silenciosa y dirigida.

Un ataque sofisticado

Los expertos de Kaspersky han calificado la campaña como altamente técnica y profesional, lo cual apunta inequívocamente a un grupo APT con respaldo estatal. Además, la explotación de CVE-2025-2783 no se realizaba de forma aislada: estaba acompañada de un segundo exploit no identificado que permitía la ejecución remota de código.

Aunque este segundo exploit no pudo ser recuperado para su análisis, el simple hecho de combinar dos vectores de ataque sugiere una cadena de infección avanzada diseñada para evadir defensas y mantenerse oculta.

Respuesta de Google y lanzamiento de parches

El equipo de seguridad de Google lanzó de forma urgente la versión 134.0.6998.177/.178 de Chrome para Windows, corrigiendo el fallo de seguridad. La actualización está disponible tanto para usuarios con actualizaciones automáticas como para aquellos que deben hacerlo manualmente.

Además, se ha recomendado que otros navegadores basados en Chromium, como Microsoft Edge, Opera, Brave y Vivaldi, apliquen parches en cuanto estén disponibles.

Vía | Kaspersky

Imagen | Marcos Merino mediante IA

En Genbeta | Qué fue de los programadores que hace dos años trabajaron gratis para evitar pérdidas millonarias a grandes tecnológicas 

Un grave bug en el portal web de Kia permitió a un equipo de expertos en ciberseguridad controlar millones de vehículos de forma remota. La vulnerabilidad, localizada en la infraestructura web del fabricante surcoreano, posibilitó a los hackers desbloquear, encender y rastrear vehículos... y para ellos les bastó con conocer un número de matrícula.

Así se aprovecharon los atacantes

El pasado junio, un equipo de investigadores descubrió que un simple error en la plataforma web de Kia permitía el acceso no autorizado a millones de vehículos modernos. Descrita por el investigador Neiko Rivera como una vulnerabilidad propia de una "seguridad web muy pobre", ésta dejaba expuestos diversos modelos de Kia vendidos en los EE.UU. a toda una serie de amenazas...

...los hackers podían desbloquear puertas, encender motores e incluso rastrear el paradero de los vehículos con solo introducir el número de matrícula en una aplicación personalizada que desarrollaron como prueba de concepto.

Dicha aplicación funcionaba utilizando comandos directos a la API de Kia, una interfaz de software que permite a los usuarios interactuar con las funciones del vehículo a través de Internet. En tan sólo unos segundos, podían localizar un coche, abrirlo y encenderlo.

Los investigadores también lograron extraer información personal del propietario del vehículo, como su nombre, número de teléfono, dirección de correo electrónico y dirección residencial. Esto hizo posible que los atacantes agregaran sus propios dispositivos como administradores de los vehículos sin el conocimiento del propietario.

Consecuencias de la vulnerabilidad

Aunque es cierto que este ciberataque no permitía a los atacantes controlar directamente la dirección o los frenos del automóvil, la posibilidad de desbloquear y encender el vehículo representa también un grave riesgo: según Sam Curry, miembro del equipo de investigación, este bug pudo facilitar robos o situaciones de acoso, además de exponer la privacidad de los usuarios. En el caso de modelos equipados con cámara de 360 grados, los atacantes podían incluso ver el entorno del vehículo.

Según la firma de seguridad Kaspersky,

"esta vulnerabilidad podría usarse fácilmente para rastrear a su titular, robar objetos de valor que quedan dentro del coche (o plantar algo allí) o alterar la vida de quien conduce con acciones inesperadas desde el coche".

El origen (y el alcance) de la vulnerabilidad

Los investigadores identificaron el problema en un error simple en el 'backend' de Kia. El portal de Kia permitía el acceso con privilegios administrativos sin verificar adecuadamente si el usuario en cuestión era un concesionario autorizado. Esto daba a cualquier persona la capacidad de controlar remotamente las funciones del vehículo. Además, los hackers encontraron una forma de convertir un número de matrícula en el número de identificación del vehículo (VIN), facilitando la explotación de la vulnerabilidad.

En Genbeta

Han conseguido hackear un Tesla: ahora pueden activar a distancia sus luces, el claxon o el limpiaparabrisas

Además, esta vulnerabilidad no es exclusiva de Kia. Según el equipo de investigación, marcas como Honda, Hyundai, Toyota y BMW presentan problemas similares en sus sistemas web. Los hackers encontraron vulnerabilidades en más de una docena de fabricantes, revelando un patrón de deficiencias en la ciberseguridad web de la industria automotriz.

El investigador Rivera señaló que la industria automotriz se ha centrado más en la seguridad de los componentes integrados de los vehículos, como los frenos y el sistema de dirección, mientras que la seguridad web ha quedado en segundo plano. Con el creciente número de funciones conectadas a Internet en los automóviles, la 'superficie de ataque' se ha ampliado enormemente, poniendo en riesgo a los usuarios.

Stefan Savage, profesor de ciencias de la computación en UC San Diego, señala la razón última de este problema:

"¿Cómo se decide retrasar el lanzamiento de un vehículo seis meses porque el código web no está listo?".

Vía | Sam Curry

Imagen | Marcos Merino mediante IA

En Genbeta | Otro caso Alcasec: así extrajo este veinteañero durante años 40 millones de matrículas de la DGT para comercializarlas

La comunidad de usuarios y desarrolladores de Linux se ha visto sacudida por la revelación de un 'pack' de vulnerabilidades críticas en el sistema CUPS (Common Unix Printing System), un componente esencial en la mayoría de las distribuciones de Linux, utilizado para gestionar las tareas de impresión.

La amenaza, descubierta y reportada por el experto en ciberseguridad Simone Margaritelli, tiene el potencial de permitir la ejecución de código remoto (RCE) en sistemas GNU/Linux, y posiblemente en otros sistemas operativos Unix como BSD, ChromeOS y Solaris.

Así, el encadenamiento de una serie de fallos de seguridad podrían permitir a un atacante tomar el control de un PC a través de algo tan simple como una tarea de impresión.

CUPS y la vulnerabilidad

Margaritelli descubrió múltiples fallos en el sistema, específicamente en el servicio cups-browsed y otras bibliotecas relacionadas con la impresión. Estos fallos permiten que un atacante, sin autenticación, envíe paquetes maliciosos a través del puerto UDP 631, aprovechando la confianza del sistema en los datos entrantes.

La vulnerabilidad ha sido categorizada con identificadores CVE (la nomenclatura estándar de las vulnerabilidades informáticas) que incluyen:

• CVE-2024-47176: Relacionado con el servicio cups-browsed, que acepta cualquier paquete de cualquier fuente.
• CVE-2024-47076: En la biblioteca libcupsfilters, que no valida adecuadamente los atributos devueltos por una solicitud maliciosa.
• CVE-2024-47175: Afecta a libppd, que no sanitiza los atributos de la impresora al escribirlos en un archivo temporal.
• CVE-2024-47177: En cups-filters, donde se ejecutan comandos arbitrarios a partir de datos maliciosos.

En Genbeta

Cuanto más popular es Linux, más vulnerable: vemos dos ejemplos de malware desvelados en el último mes

Por separado, las cuatro vulnerabilidades no serían especialmente relevantes. Pero, al encadenarlas, un atacante podría ejecutar comandos arbitrarios cuando el usuario inicia una tarea de impresión.

Margaritelli demostró que es posible aprovechar esta cadena de fallos para crear una impresora falsa, que el sistema Linux detectaría y añadiría automáticamente sin intervención del usuario. Cuando el usuario inicia una tarea de impresión en esta impresora comprometida, se ejecutan los comandos maliciosos, otorgando al atacante control sobre el sistema.

Problemas a la hora de divulgar de forma controlada el bug

Por si esto fuera poco, el habitual proceso de divulgación de estas vulnerabilidades ha estado marcado por los conflictos entre el investigador y los desarrolladores de CUPS. Margaritelli, tras intentar alertar a estos últimos y recibir respuestas que consideró insuficientes, optó por hacer públicas las vulnerabilidades.

En su publicación, criticó duramente el proceso de reporte de fallos de seguridad y la falta de atención por parte de los responsables del proyecto. Además, una filtración de los detalles de su investigación a un foro de ciberdelincuencia aceleró su divulgación pública (en origen, prevista para el día 30), y ha generado bastante preocupación en los círculos de ciberseguridad.

¿Cómo de grave es realmente la amenaza?

Aunque algunos expertos en seguridad, como Benjamin Harris de watchTowr, han restado importancia al riesgo de esta vulnerabilidad, otros insisten en la necesidad de una acción inmediata. Harris señaló que solo una pequeña fracción de los sistemas Linux estaría expuesta, lo que sugiere que la vulnerabilidad podría no ser tan devastadora como se pensaba inicialmente.

Un reconocido experto como Kevin Beaumont denuncia que Margaritelli ha estado generando 'hype' en redes sociales sobre la amenaza, y que muchos medios están haciendo que el problema "parezca lo que no es".

Sin embargo, Margaritelli calculó que existen entre 200.000 y 300.000 dispositivos vulnerables conectados públicamente, lo que subraya el potencial de una explotación masiva si los atacantes deciden actuar.

La vulnerabilidad recibió una puntuación preliminar de 9,9 en el CVSS (Sistema de Puntuación de Vulnerabilidad Común), una clasificación que normalmente indica un riesgo crítico. Sin embargo, la necesidad de interacción del usuario para iniciar una tarea de impresión ha llevado a algunos expertos a cuestionar si la gravedad merece tan alta puntuación.

Los responsables de Red Hat, por su parte, aclaran que en su web que conceden a este conjunto de vulnerabilidades

"un impacto de gravedad de 'Importante'. Si bien todas las versiones de RHEL están afectadas, es importante tener en cuenta que los paquetes afectados no son vulnerables en su configuración predeterminada".

En Genbeta

Un bug en Linux de hace 12 años permite obtener acceso root en casi cualquier distro, y ya lo han explotado

Así que, en resumen, la vulnerabilidad de CUPS plantea una amenaza considerable, pero no es ningún apocalipsis inminente... si bien la falta de parches disponibles aumenta el riesgo de que los atacantes encuentren formas más sofisticadas de aprovecharla.

Consejos para mitigar el riesgo

Mientras los parches oficiales están en desarrollo, se han sugerido varias medidas de mitigación:

1. Desactivar o eliminar el servicio 'cups-browsed' si no es necesario. Lo primero se puede hacer con el comando 'sudo systemctl stop cups-browsed', y lo segundo con 'sudo systemctl disable cups-browsed'.
2. Actualizar la instalación de CUPS en cuanto estén disponibles los parches.
3. Bloquear el acceso al puerto UDP 631 y considerar bloquear también los servicios de descubrimiento de impresoras, como DNS-SD.
4. Si no se necesita CUPS para imprimir, desinstalarlo por completo podría ser la mejor opción.

Imagen | Marcos Meirno mediante IA

En Genbeta | Una vulnerabilidad crítica en Sudo permite ganar acceso root en casi cualquier distro Linux

Cuando existe un agujero de seguridad en un sistema, un hacker tiene tres formas de proceder: aprovecharlo para beneficio propio o para una causa, encontrar una solución para después informar sobre ello o, simplemente, no hacer nada. Muchas grandes compañías cuentan con programa de recompensas para aquellos que encuentren vulnerabilidades, mientras que otras prefieren ofrecer un reconocimiento cordial, como es el caso de la NASA.

Conocido en redes como ‘7h3h4ckv157’, ya es la segunda vez que hackea a la NASA para encontrar vulnerabilidades en sus sistemas e informar de ello a la agencia. Como reconocimiento de su labor, la agencia le envió una carta agradeciendo lo que hizo firmada por Mike Witt, responsable superior de seguridad de la información de la NASA.

Hackeó la NASA, Google, Apple y X

No es la primera vez que este hacker encuentra vulnerabilidades para grandes compañías y agencias. En su palmarés se encuentran algunas como Google, Apple, X, y ahora la NASA, agencia en la que se ha adentrado varias veces en sus sistemas.

La anterior tuvo lugar en 2022, cuando realizó un informe acerca de una vulnerabilidad en el sitio web de la NASA. Aquí, utilizó la técnica Cross-Site Scripting (XSS), un ataque que permite a los hackers ejecutar código malicioso en el navegador de otra persona.

Haz clic en la imagen para ir a la publicación

Según informaba aquel año el hacker, existen tres variantes de XSS: XSS reflejado, XSS almacenado y basado en DOM, cada uno con diferentes formas de ataque y niveles de peligrosidad. Aunque se esperaría que la seguridad de la NASA fuera muy alta, el autor encontró que era vulnerable como muchas otras organizaciones.

Aprovechando esta técnica, se dio cuenta de que la página de la NASA no manejaba correctamente los datos que los usuarios introducían (como en formularios o campos de búsqueda). En lugar de texto normal, un hacker puede enviar código malicioso, que la página web refleja o almacena. Luego, cuando otra persona visita la web, ese código se ejecuta en su navegador sin darse cuenta. Esto podría permitir al hacker robar información, como contraseñas o datos privados, o controlar la cuenta de la víctima.

Aquella vez, el hacker no obtuvo reconocimiento ni recompensa alguna por parte de la NASA, según escribía en su blog. Sin embargo, para esta última ocasión, la NASA le envió una carta firmada en agradecimiento por su labor para mejorar la seguridad de la agencia. El hacker publicó la prueba a través de su cuenta en X, aunque aún no ha ofrecido detalles sobre esta nueva vulnerabilidad.

En Genbeta

Esta hacker española es la nueva jefa de ciberseguridad de Kamala Harris, tras años en Google: la historia de Soledad Antelada

Que aún no se sepa el tipo de vulnerabilidad encontrada recientemente en los sistemas de la NASA no es extraño, pues debe pasar un tiempo hasta que se cercioren de que está resuelto para que otras personas no puedan aprovechar el agujero de seguridad. Es posible que algún día el hacker escriba cuál fue el problema en su blog, aunque para ello tendremos que esperar.

Imagen de portada | Space Foundation

En Genbeta | Un hacker dejó sin Internet a Corea del Norte. Acaba de desvelar quién es y por qué lo hizo

Los administradores de sistemas Windows no se habían recuperado aún de la debacle de CrowdStrike de hace unos días, y hoy ya se ven de nuevo sacudidos por un fallo crítico que afecta a todas las versiones de Windows con IPv6 habilitado, y que Microsoft identificado como CVE-2024-38063.

Sin embargo, la compañía ha advertido que, dado que IPv6 está habilitado por defecto en todas las versiones modernas de Windows, esta vulnerabilidad presenta un riesgo generalizado. Además, ha encendido todas las alarmas debido a su potencial para ser explotado por atacantes de forma remota.

El descubrimiento y la naturaleza del fallo

El investigador 'XiaoWei', del laboratorio de ciberseguridad Kunlun Labs, fue quien identificó esta vulnerabilidad, rápidamente catalogada como de alta peligrosidad. El problema reside en una 'vulnerabilidad de subdesbordamiento de enteros' en el protocolo TCP/IP, lo que podría permitir a los atacantes ejecutar código arbitrario en los sistemas vulnerables.

¿Un sub-qué de cuál? Un 'subdesbordamiento de enteros' ocurre cuando un número es demasiado pequeño para ser manejado por el sistema y "se pasa" del límite mínimo que puede soportar. Es como si tuvieras un recipiente que no puede tener menos de 0 litros de agua, pero intentas restar más agua de la que hay.

Este error favorece, en este caso, la realización de un tipo de ataque conocido como 'ejecución remota de código' que podría dar a los hackers el control total del sistema afectado sin necesidad de autenticación previa.

En Genbeta

Microsoft señala a un responsable inesperado de la gran caída de ordenadores del viernes: la Comisión Europea

Lo que agrava aún más la situación es que este fallo puede propagarse automáticamente de un sistema a otro sin intervención del usuario, lo que podría desencadenar un ataque masivo y devastador en poco tiempo.

A pesar de que, hasta la fecha, no se ha documentado ningún ataque masivo destinado a explotar CVE-2024-38063, Microsoft ha indicado que el hecho de que alguien termine explotando esta vulnerabilidad es altamente probable, dada la simplicidad con la que puede ser explotada mediante el envío de paquetes IPv6 especialmente diseñados.

No es la primera vez que IPv6 ha sido el centro de una vulnerabilidad crítica en Windows. En los últimos años, Microsoft ha parcheado varias fallas relacionadas con este protocolo, incluyendo las conocidas vulnerabilidades "Ping of Death" (CVE-2020-16898/9).

La reacción de Microsoft

Ante la seriedad del hallazgo, Microsoft ha actuado con celeridad, lanzando un parche de seguridad en su última actualización de Windows. La compañía recomienda encarecidamente a todos los usuarios que instalen la actualización de seguridad de inmediato.

Aquellos que no puedan actualizar sus sistemas de forma inmediata tienen la opción de desactivar manualmente IPv6 como medida temporal de mitigación. No obstante, Microsoft también ha señalado que desactivar IPv6 podría generar problemas de rendimiento en ciertos casos, lo que sitúa a los usuarios en una difícil encrucijada entre seguridad y funcionalidad.

Imagen | Marcos Merino mediante IA

En Genbeta | "Apaga tu móvil al menos una vez a la semana". Es un consejo de la Agencia de Seguridad Nacional de EE.UU., y esta es la razón