Un modelo de inteligencia artificial aún no publicado ha encadenado vulnerabilidades para ejecutar código, acceder a datos privados y comprometer sistemas. Anthropic afirma que los fallos ya están corregidos, aunque quedan dudas sobre cuánto trabajo realizó la IA sin ayuda humana.
La inteligencia artificial está entrando en un terreno especialmente delicado: descubrir vulnerabilidades y convertirlas en ataques funcionales contra sistemas reales. Anthropic asegura que uno de sus modelos internos ha conseguido encadenar errores de seguridad en Chrome, Safari, Android, Windows y Linux para construir pruebas de concepto capaces de explotar esos fallos.
La compañía dio a conocer los resultados el 28 de octubre de 2026 a través de su equipo Frontier Red Team. Según su investigación, el modelo logró desarrollar cinco cadenas de explotación con distintos niveles de impacto, desde el acceso a datos de navegación hasta la ejecución de comandos con privilegios de administrador en un servidor Linux.
Anthropic sostiene que las vulnerabilidades se descubrieron en entornos de investigación y que no hay constancia de que estas cadenas se utilizaran en ataques reales. La empresa asegura, además, que notificó los problemas a los fabricantes y que las correcciones correspondientes ya se han publicado.
Pero la noticia plantea una cuestión que va más allá de los parches: ¿qué ocurre cuando una IA puede pasar de detectar un error a construir un exploit funcional con una intervención humana limitada? La investigación apunta a un cambio relevante para la ciberseguridad, aunque todavía existen lagunas sobre el grado exacto de autonomía del modelo y la relación entre algunas de las cadenas descritas y los registros públicos de vulnerabilidades.
Cinco cadenas de ataque contra sistemas y navegadores
El equipo de investigación de Anthropic describe cinco pruebas de concepto desarrolladas con un modelo interno que no ha sido publicado de forma general. La compañía afirma que bastó con una orientación inicial y una intervención humana reducida, pero no ofrece un desglose detallado de todas las tareas realizadas por el modelo y por los investigadores.
Las cadenas analizadas afectan a diferentes plataformas y requieren condiciones distintas. No todas permiten tomar el control de un equipo ni tienen el mismo nivel de gravedad.
| Plataforma | Capacidad descrita por Anthropic | Condición principal |
|---|---|---|
| Google Chrome | Ejecutar código fuera del entorno aislado del navegador | Visita a una página maliciosa en un Mac con Chrome |
| Safari | Leer datos de otros sitios web en los que el usuario tiene sesión iniciada | Visita a una página maliciosa |
| Android | Extraer fotografías y otros datos de un teléfono bloqueado | Acceso físico al dispositivo mediante USB |
| Windows | Provocar una denegación de servicio y mantener el sistema inactivo | Un servicio HTTP/3 accesible por red |
| Linux | Ejecutar comandos con privilegios de administrador desde la red | Un servidor con un servicio TCP multipath activo |
La tabla resume las capacidades que Anthropic atribuye a sus pruebas. No significa que todos los dispositivos que utilizan esos sistemas estén expuestos actualmente, ni que las cinco cadenas puedan ejecutarse en cualquier configuración.
La compañía afirma que los fabricantes recibieron las notificaciones correspondientes. Sin embargo, en algunos casos la correspondencia entre la explicación técnica y los registros públicos no está completamente acreditada con fuentes independientes.
Chrome: una página web podía terminar ejecutando código en el ordenador
La cadena desarrollada contra Google Chrome es una de las demostraciones más llamativas. Según Anthropic, una página web maliciosa podía activar una secuencia de vulnerabilidades que terminaba ejecutando código fuera del entorno aislado del navegador en un ordenador Mac.
La prueba de concepto llegó a abrir la aplicación Calculadora en un equipo estándar con Chrome después de cargar la página, sin necesidad de que el usuario hiciera clic en un botón. La demostración sirve para ilustrar el resultado de la explotación, aunque abrir una aplicación no equivale por sí solo a demostrar un control ilimitado sobre todos los recursos del equipo.
El ataque combinaba cuatro vulnerabilidades distintas. Cada una permitía superar una barrera adicional hasta llegar a la ejecución de código fuera del sandbox, el mecanismo que restringe las operaciones que puede realizar una página web.
Cómo se encadenaron los fallos de Chrome
Según la explicación de Anthropic, el primer paso aprovechaba un error de corrupción de memoria en V8, el motor JavaScript de Chrome. El fallo permitía alterar el comportamiento del proceso que ejecuta el código de una página.
Una segunda vulnerabilidad permitía escapar de las restricciones del aislamiento de memoria de V8 y comprometer el componente de Chrome encargado de representar el contenido web.
La cadena continuaba con una condición de carrera en CacheStorage, una función utilizada para almacenar recursos de aplicaciones web. El error permitía leer memoria que no debería estar disponible y obtener información sobre la estructura del proceso del navegador con mayores privilegios.
Por último, una vulnerabilidad de uso de memoria liberada en FedCM, la tecnología de Chrome relacionada con la gestión de identidad y el inicio de sesión, permitía completar la salida del entorno aislado.
La importancia del caso está en la combinación: un fallo inicial no habría bastado para conseguir el resultado final. El exploit debía aprovechar cada vulnerabilidad en el orden adecuado para superar sucesivas barreras de seguridad.
Google publicó correcciones para las vulnerabilidades
Anthropic afirma que notificó a Google 62 vulnerabilidades, que posteriormente fueron identificadas mediante registros CVE y corregidas en Chrome 156. Según la empresa, todas se clasificaron como de gravedad alta o crítica, y 13 estaban relacionadas con la evasión del entorno aislado.
No obstante, conviene diferenciar entre el conjunto de vulnerabilidades comunicadas por Anthropic y los fallos que forman parte de la cadena concreta descrita en el artículo. Las notas de lanzamiento de Google atribuyen determinadas correcciones a Xinyang Ge, de Anthropic, con ayuda de Claude, pero esa atribución no demuestra por sí sola que las 62 vulnerabilidades fueran descubiertas o explotadas mediante el mismo procedimiento.
Google publicó las notas de la versión estable de Chrome 156 el 20 de octubre de 2026, según el enlace incluido en la información original.
Safari: una cadena que podía romper la separación entre páginas web
La investigación describe un enfoque diferente para Safari, el navegador de Apple. En este caso, la prueba de concepto no necesitaba ejecutar código arbitrario en el dispositivo: su objetivo era conseguir que una página web pudiera acceder a información perteneciente a otros sitios.
Los navegadores utilizan la política del mismo origen para impedir que una página lea libremente los datos de otra. Esta protección separa el contenido de sitios diferentes, incluso cuando el usuario tiene varias sesiones abiertas.
Según Anthropic, la cadena de Safari conseguía acceso de lectura y escritura a zonas de memoria del navegador y modificaba un valor para desactivar esa política de seguridad. El resultado podía permitir que una página maliciosa leyera información de otros sitios en los que la víctima tuviera una sesión activa.
Entre los datos potencialmente afectados se encontrarían información del historial y cookies, aunque el alcance real depende de las protecciones concretas de cada servicio y de las condiciones de la explotación. Las cookies protegidas mediante mecanismos adicionales no deben darse por comprometidas automáticamente.
La consecuencia más importante sería la posibilidad de que un sitio malicioso intentara acceder a información de servicios sensibles, incluidas cuentas personales o financieras, aprovechando las sesiones abiertas en el navegador.
Apple atribuyó una corrección a investigadores y a Claude
La noticia original señala que Apple corrigió un problema de uso de memoria liberada mediante iOS y iPadOS 26.5.2, una actualización publicada el 29 de junio de 2026.
La documentación de Apple atribuye la corrección a Milad Nasr y Nicholas Carlini, junto con Claude, de Anthropic. Esta mención constituye una atribución pública del fabricante, aunque no revela todos los pasos que el modelo realizó durante el descubrimiento y desarrollo de la prueba de concepto.
La corrección es relevante porque muestra que, al menos en este caso, Apple reconoció la participación de investigadores y de una herramienta de IA en la solución del problema.
Android: datos de un móvil bloqueado, pero con acceso físico
La cadena relacionada con Android presenta un escenario diferente. Según Anthropic, la prueba de concepto permitía copiar fotografías y otros datos de un teléfono robado y bloqueado.
La condición resulta determinante: el ataque descrito necesitaba acceso físico al dispositivo mediante USB. Por tanto, no se trata de una vulnerabilidad que permita extraer los datos de cualquier móvil Android a distancia con solo visitar una página web.
El acceso físico cambia el escenario de riesgo, pero no elimina su importancia. Un teléfono robado puede contener fotografías, documentos, comunicaciones y otra información personal. Si una vulnerabilidad permite eludir las protecciones de un dispositivo bloqueado, el impacto potencial sobre la privacidad puede ser considerable.
Anthropic afirma que Google corrigió el problema, aunque la información original indica que no se localizó un registro público que permitiera verificar de forma independiente todos los detalles de la vulnerabilidad.
Por ese motivo, no es posible establecer únicamente a partir de la noticia qué versiones concretas de Android estuvieron afectadas, qué parche corrigió el problema ni cuál fue la secuencia técnica completa.
Windows: un ataque de denegación de servicio, no de robo de datos
La cadena relacionada con Windows requiere una precisión importante: según la descripción de Anthropic, no permitía ejecutar código arbitrario ni robar información, sino provocar una denegación de servicio.
Este tipo de ataque busca que un sistema deje de responder o que un servicio quede fuera de funcionamiento. La empresa afirma que unos pocos paquetes de red podían bloquear la máquina y que la repetición del ataque permitía mantenerla inactiva.
La condición descrita era que el servidor respondiera a solicitudes HTTP/3. La investigación atribuye el problema a una lectura fuera de límites en el tratamiento de QUIC dentro del kernel de Windows.
Sin embargo, existe una discrepancia documental que conviene no pasar por alto.
La relación con CVE-2026-33096 necesita cautela
Anthropic relaciona su hallazgo con CVE-2026-33096, un registro que identifica una vulnerabilidad en HTTP.sys, el controlador integrado de Windows utilizado para procesar solicitudes web.
El registro público asigna al fallo una puntuación de 7,5 sobre 10. Sin embargo, la descripción técnica del registro no coincide de forma evidente con la explicación de Anthropic sobre QUIC y el kernel.
La información original reconoce que no existe una fuente pública independiente que permita confirmar que ambas descripciones se refieren exactamente al mismo componente y al mismo fallo.
Por tanto, la vinculación entre la cadena descrita por Anthropic y ese identificador CVE debe atribuirse a la propia compañía, no presentarse como una correspondencia técnica demostrada de manera independiente.
A finales de octubre de 2026, según el artículo original, el registro tampoco figuraba en el catálogo de vulnerabilidades explotadas conocidas de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA). La ausencia de ese catálogo no demuestra que un fallo sea imposible de explotar, sino que no consta allí como una vulnerabilidad confirmada dentro de los criterios de inclusión de la agencia.
Linux: ejecución de comandos como administrador desde la red
La cadena de Linux es la que Anthropic describe con mayor impacto potencial. Según la compañía, la prueba de concepto permitía ejecutar comandos con privilegios de root, la cuenta con el máximo nivel de permisos del sistema, sin iniciar sesión y sin requerir una acción del usuario.
La condición principal era que el servidor tuviera activo un servicio de escucha TCP multipath. Esta exigencia limita el número de sistemas afectados: no basta con que un servidor utilice Linux, sino que debe contar con la configuración específica que permite activar la vulnerabilidad descrita.
Cómo describe Anthropic la explotación
Según la investigación, el modelo primero obtenía una dirección de memoria del kernel para sortear una protección llamada KASLR. Esta técnica de seguridad dificulta los ataques al aleatorizar la ubicación de componentes del sistema en memoria.
Una vez superada esa barrera, la prueba de concepto aprovechaba un error de condición de carrera para redirigir la ejecución hacia código controlado por el atacante. El resultado descrito era una consola con privilegios de root.
Anthropic asegura que el proceso tardó aproximadamente 48 minutos en obtener la dirección de memoria y otros cinco minutos en conseguir la consola. También afirma que un intento fallido no bloqueaba el sistema, lo que permitía repetir la operación.
Estas cifras proceden de la demostración de la empresa y no deben interpretarse como tiempos garantizados para cualquier equipo. El rendimiento de una explotación depende de la configuración, la versión del software, las defensas activas y las condiciones de red.
La correspondencia con CVE-2026-98432
Anthropic vincula esta cadena con CVE-2026-98432, una vulnerabilidad de uso de memoria liberada en el kernel que, según la información original, recibió una puntuación de 9,8 sobre 10 y fue corregida en una versión principal el 15 de octubre de 2026.
No obstante, el registro público describe una corrección relacionada con TCP IPv4, mientras que la explicación de Anthropic se refiere a TCP multipath. La publicación de la empresa es el vínculo que relaciona ambos elementos, pero la noticia original no aporta una fuente independiente que confirme que las dos descripciones corresponden exactamente al mismo componente.
La distinción es importante para administradores y equipos de seguridad: antes de atribuir una exposición concreta a un servidor, es necesario comprobar el aviso del proveedor, las versiones afectadas y las condiciones técnicas exactas.
El verdadero cambio: la IA no solo detecta fallos, también los encadena
Durante años, buena parte del debate sobre la inteligencia artificial y la ciberseguridad se ha centrado en su capacidad para revisar código, localizar errores y ayudar a los equipos técnicos a corregirlos.
La investigación de Anthropic plantea un paso adicional: utilizar un modelo para encadenar vulnerabilidades independientes y convertirlas en una prueba de concepto funcional.
Esta capacidad importa porque un fallo aislado puede tener un alcance limitado. Una vulnerabilidad que permite leer una pequeña zona de memoria, por ejemplo, no equivale necesariamente a ejecutar código con privilegios elevados. Pero varios errores conectados pueden permitir superar las protecciones que impiden llegar a ese resultado.
La dificultad técnica está en descubrir cómo se relacionan los componentes, qué condiciones necesita cada fallo y en qué orden deben activarse. Anthropic afirma que su modelo pudo realizar buena parte de ese trabajo con una intervención humana reducida.
Aun así, la compañía no ha publicado un registro exhaustivo de cada acción del modelo y de cada intervención de los investigadores. Sin esa información, no puede verificarse de manera independiente hasta qué punto el proceso fue autónomo ni cuánto trabajo de ingeniería adicional resultó necesario.
La demostración constituye una señal relevante sobre las capacidades de los modelos de investigación, pero no basta para concluir que cualquier usuario pueda producir exploits avanzados con una simple instrucción.
El doble uso de la inteligencia artificial en ciberseguridad
Las herramientas capaces de detectar vulnerabilidades pueden beneficiar a los defensores y, al mismo tiempo, reducir las barreras técnicas para quienes buscan explotarlas.
Para los fabricantes, una IA que encuentre errores antes de que sean utilizados en ataques puede acelerar la corrección de software. Para las empresas, puede ayudar a analizar grandes cantidades de código y priorizar los problemas más graves.
El riesgo aparece cuando las mismas capacidades se utilizan para construir pruebas de explotación contra sistemas vulnerables. Una herramienta que identifica una debilidad y demuestra cómo activarla puede aportar información útil para reparar el fallo, pero también puede facilitar el trabajo de un atacante.
El equilibrio depende de factores como los controles de acceso, la supervisión humana, las restricciones sobre la generación de código dañino y los procedimientos de divulgación responsable.
En este caso, Anthropic afirma que siguió una política de divulgación coordinada, con un plazo de 90 días para que los desarrolladores corrigieran las vulnerabilidades y otros 45 días antes de divulgar información adicional más allá de los avisos públicos.
La empresa presenta el procedimiento como una forma de dar a los fabricantes tiempo para proteger a sus usuarios antes de publicar detalles que puedan facilitar la explotación.
Anthropic defiende el uso de sus modelos por parte de los equipos de seguridad
La compañía ha utilizado los resultados para defender la utilidad de sus modelos en tareas avanzadas de investigación defensiva. También remite a su programa ampliado de verificación cibernética, que proporciona acceso a determinados modelos de Claude a profesionales verificados.
La iniciativa busca facilitar el trabajo de especialistas que investigan vulnerabilidades, evalúan riesgos y ayudan a los fabricantes a corregir errores antes de que puedan convertirse en ataques generalizados.
No obstante, el acceso restringido no elimina todos los riesgos. La seguridad del programa dependerá de la verificación de los participantes, las condiciones de uso, los mecanismos de supervisión y la capacidad de responder ante posibles abusos.
Además, las afirmaciones sobre el rendimiento del modelo deben valorarse teniendo en cuenta que proceden de la propia empresa. Las correcciones reconocidas por los proveedores ofrecen elementos de verificación, pero no demuestran por sí solas todos los detalles sobre la autonomía del sistema.
Qué deben hacer empresas y usuarios
Para los usuarios domésticos, la principal recomendación es mantener actualizados el navegador, el sistema operativo y las aplicaciones. Las actualizaciones de seguridad reducen la exposición a vulnerabilidades conocidas, aunque no garantizan una protección absoluta frente a todos los ataques.
Las empresas y los administradores deben adoptar medidas adicionales:
- Comprobar las versiones instaladas de Chrome, Safari, Android, Windows y las distribuciones Linux utilizadas en su infraestructura.
- Revisar los avisos oficiales de seguridad y confirmar qué versiones están afectadas por cada vulnerabilidad.
- Aplicar los parches disponibles de acuerdo con la criticidad del sistema y la exposición a Internet.
- Desactivar servicios de red innecesarios, especialmente cuando una vulnerabilidad depende de una función concreta.
- Vigilar los registros y la disponibilidad de los servicios, para detectar posibles intentos de explotación o denegación de servicio.
- Separar los sistemas críticos y limitar privilegios, de modo que un fallo en un componente no proporcione automáticamente acceso a toda la infraestructura.
No debe suponerse que una actualización concreta soluciona todos los fallos descritos. La versión y el parche aplicables dependen de cada plataforma y de la correspondencia exacta con el aviso del proveedor.
La nueva carrera entre los defensores y quienes buscan vulnerabilidades
La investigación de Anthropic apunta a un escenario en el que los modelos de inteligencia artificial pueden asumir tareas cada vez más complejas dentro de la investigación de seguridad. La capacidad de encontrar errores y combinarlos en una prueba de concepto podría acelerar tanto la corrección de vulnerabilidades como el desarrollo de ataques.
La diferencia entre ambos resultados dependerá de quién pueda utilizar las herramientas, con qué controles y bajo qué condiciones. Los fabricantes necesitarán mejorar sus procesos de revisión y parcheado, mientras que los equipos de seguridad tendrán que evaluar cómo integrar la IA sin perder trazabilidad ni supervisión.
La principal incógnita no es solo si una IA puede encontrar una vulnerabilidad, sino hasta qué punto puede convertirla en una vía de ataque reproducible con poca intervención humana. Anthropic afirma haber dado un paso importante en esa dirección, pero la autonomía exacta del modelo y algunos detalles técnicos de las cadenas todavía requieren más documentación independiente.
Lo que sí deja claro el caso es que la seguridad informática tendrá que adaptarse a herramientas capaces de investigar software a gran escala. Y cuanto más fácil resulte automatizar el descubrimiento y la explotación de errores, más importante será que los fabricantes corrijan las vulnerabilidades con rapidez y que las empresas mantengan sus sistemas protegidos.
Toqueteo
Toqueteo
Toqueteo