Durante los últimos meses, hemos utilizado un modelo de investigación interno no publicado para encontrar vulnerabilidades críticas en algunos de los software más utilizados del mundo, como navegadores y sistemas operativos. En esta publicación, compartimos detalles de cinco cadenas de ataque, que condujeron a ejecución remota de código y otros impactos críticos con poca o ninguna interacción del usuario. Estas cadenas de ataque demuestran la capacidad del modelo para crear exploits sofisticados de múltiples pasos tanto en software de código abierto como propietario. Cualquier vulnerabilidad en estos productos podría afectar a miles de millones de usuarios. También se encuentran entre los software más críticos para la seguridad del mundo, lo que los convierte en un referente para probar la investigación de vulnerabilidades y las capacidades cibernéticas de los modelos.
Reportamos cada vulnerabilidad al proveedor afectado bajo nuestra divulgación coordinada de vulnerabilidades, que otorga a los desarrolladores 90 días para parchear y 45 días adicionales antes de que discutamos detalles más allá de lo que ya está incluido en un aviso público.
1. Ejecución remota de código con un solo clic en Chrome
Tras la petición inicial, Claude escribió una cadena de exploit completa que permitía a un atacante ejecutar código arbitrario como el usuario, fuera del sandbox del navegador. Nuestra prueba de concepto lanza la aplicación Calculadora desde un navegador Chrome con configuración predeterminada de fábrica en macOS en cuestión de segundos después de que la página cargue, sin ninguna interacción adicional del usuario:
- Claude descubrió una vulnerabilidad en el motor JavaScript de Chrome, V8, que permitía a una página web maliciosa corromper la memoria de heap de V8.
- Claude descubrió una segunda vulnerabilidad para salir del sandbox de la región de memoria de V8 y derrotar ASLR. Este paso localizó el código de Chrome en la memoria y usó una cadena de programación orientada al retorno (ROP) para tomar el control total del proceso de renderizado.
- El renderizador comprometido estaba confinado por el sandbox de procesos de Chrome. Claude entonces descubrió una condición de carrera en CacheStorage. El renderizador comprometido usó la condición de carrera para leer memoria fuera del sandbox y conocer la distribución de memoria del proceso privilegiado del navegador.
- Finalmente, Claude descubrió un use-after-free en FedCM, la función de inicio de sesión federado de Chrome, que permitía al exploit ejecutar código arbitrario fuera del sandbox.
Hemos reportado nuestros hallazgos a Google: se han asignado 62 CVE y han sido parcheados a partir de Chrome 156, con todos ellos calificados como de severidad crítica o alta. Entre ellos hay 13 escapes de sandbox y 21 vulnerabilidades que podrían haberse usado para comprometer el renderizador.
2. Una cadena de exploit de un solo clic en Safari
Tras la petición inicial, Claude escribió una cadena de exploit que permitía que el JavaScript de cualquier sitio web eludiera por completo la política del mismo origen (SOP). El exploit podía acceder al historial de Safari de un usuario, a las cookies y a otros datos sensibles, y podía enviar solicitudes HTTP autenticadas a otros dominios y leer las respuestas. Por ejemplo, si el usuario ha iniciado sesión en su cuenta de correo electrónico, el atacante ahora puede leer su correo; si está conectado a su cuenta bancaria, el atacante puede ver los saldos de la cuenta o intentar transferencias.
Para lograr esto, Claude derrotó varias capas de protección integradas en Safari:
- Claude descubrió una vulnerabilidad de use-after-free (UAF) en JavaScriptCore, el motor JavaScript de Safari, que está escrito en C++. Ciertas operaciones de TypedArray escribían a través de punteros obsoletos a memoria liberada, sobrescribiendo los metadatos de TypedArray.
- El Gigacage de WebKit mitiga este tipo de ataque al aislar los datos de TypedArray en una región separada de la memoria. Claude descubrió que ciertas variables en esta región se usaban para indexar otras regiones, lo que le dio una primitiva de lectura/escritura arbitraria fuera del Gigacage.
- Todo el JavaScript de los sitios web se ejecuta en el sandbox de WebContent, que evita que errores como el UAF alcancen los datos sensibles del navegador en el disco. Claude descubrió una vulnerabilidad en el mecanismo IPC del sandbox que permitió al exploit leer el historial almacenado de Safari, las cookies y las bases de datos de sesión desde el disco.
- Finalmente, Claude usó el UAF para sobrescribir una variable en la memoria y desactivar la SOP, permitiendo que la página del atacante leyera datos de cualquier otro origen.
La cadena es interesante porque es un ataque de solo datos que nunca depende de la ejecución arbitraria de código. En su lugar, utiliza acceso completo de lectura/escritura a la memoria del proceso del navegador para modificar un indicador de seguridad, el tamaño de un objeto y una URL. Varias de las debilidades no son vulnerabilidades por sí mismas, sino comportamientos intencionales que se vuelven explotables cuando se combinan.
Apple reconoció nuestro informe el mismo día que lo enviamos e implementó una corrección con prontitud. Esa corrección está disponible para los usuarios.
3. Omisión de la pantalla de bloqueo de Android
Tras la solicitud inicial, Claude escribió un exploit que permitía a un atacante extraer fotos y otra información personal de un teléfono Android robado sin desbloquearlo. El trabajo combinó tres métodos: análisis de código fuente de las partes de código abierto de Android, ingeniería inversa y desofuscación de los binarios de Google Play services, y pruebas en vivo sobre un Google Pixel 9 físico. Esto reveló una amplia gama de vulnerabilidades tanto en los componentes de código abierto como en los propietarios. Claude luego encadenó tres de ellas en el exploit final.
Android tiene varias capas de protección contra este ataque. Claude encontró la forma de sortear cada una de ellas:
- Un teléfono Android bloqueado está diseñado para no transferir datos por USB. Claude descubrió que un host USB con una configuración específica eludía esta protección.
- El protocolo de transferencia de dispositivo a dispositivo rechaza los comandos de datos de pares no autorizados. Claude encontró una manera de omitir la verificación de autorización e iniciar el proceso de emparejamiento.
- El emparejamiento está protegido por un acuerdo de claves autenticado que pide al usuario verificar un código de seis dígitos. Claude encontró una falla que saltaba esta verificación y se comportaba como si el usuario hubiera tocado «Permitir».
- Las transferencias USB no deberían transportar contenidos de archivos, tal como lo hace cumplir una comprobación integrada en el código. Claude encontró un mecanismo alternativo que enviaba bytes sin procesar por USB y no estaba cubierto por la comprobación. El exploit solicitó los contenidos de los archivos a través de este mecanismo.
Google ha solucionado este problema.
4. Denegación de servicio remota en Windows
Tras la solicitud inicial, Claude escribió un exploit que habría permitido a un atacante bloquear remotamente cualquier máquina Windows que responda a solicitudes HTTP/3 utilizando la implementación nativa de Windows. La dificultad en este caso estaba en identificar la vulnerabilidad en primer lugar. Tras esa solicitud inicial, reportamos esta vulnerabilidad directamente a Microsoft, que resolvió la vulnerabilidad y le asignó el identificador CVE-2026-33096.
La vulnerabilidad que Claude identificó fue una lectura fuera de los límites, un problema de seguridad de memoria, en la implementación de QUIC del kernel de Windows. Un atacante podía llegar al código vulnerable de forma remota a través de la red y enviar unos pocos paquetes de datos a un servidor en escucha para bloquear y reiniciar la máquina. Enviando estas solicitudes repetidamente, es posible bloquear el servidor de forma continua, lo que provoca la pérdida de acceso al servidor para todos los usuarios. Estimamos que probablemente hay varios millones de servidores de este tipo en escucha en internet.
Claude descubrió esta vulnerabilidad mediante análisis binario. Proporcionamos al modelo una copia del ejecutable de Windows y le pedimos a Claude que aplicara ingeniería inversa para entender cómo funciona el software utilizando las herramientas existentes de ingeniería inversa (como Ghidra), que escribiera un programa en C completamente anotado que reprodujera las características relevantes, que comparara el comportamiento del programa reproducido con el binario para garantizar su corrección, y luego que estudiara el código en busca de vulnerabilidades. Cuando le pedimos a Claude que identificara problemas de mayor riesgo potenciales, esta vulnerabilidad explotable de forma remota salió a la luz.
5. Ejecución remota de código sin interacción del usuario en Linux
Si bien esta publicación se centra en productos de terceros, nuestro trabajo en código abierto ha continuado. Con Claude, descubrimos vulnerabilidades de escalada de privilegios locales en OpenBSD, FreeBSD y Linux; varias evasiones de sandbox en infraestructuras de sandboxing populares; y numerosas vulnerabilidades en aplicaciones web importantes. También hemos encontrado vulnerabilidades de ejecución arbitraria de código activables de forma remota (sin interacción del usuario) en la pila de red del kernel de Linux, que desde entonces han sido corregidas upstream y divulgadas públicamente. Detallamos un ejemplo de esto a continuación.
Tras la solicitud inicial, Claude escribió un exploit que permite a un atacante remoto enviar paquetes a servidores Linux con un listener multipath TCP para ejecutar comandos arbitrarios como root, sin ninguna credencial ni interacción del usuario. La vulnerabilidad subyacente es un bug UAF causado por una condición de carrera en la pila de red del kernel. La explotación completa tiene dos etapas clave:
- En la primera etapa, el atacante derrota KASLR de forma remota. Explota la condición de carrera para hacer que el kernel lea un campo de longitud controlado por el atacante y copie bytes adicionales que envía de vuelta al atacante, y mientras una de estas lecturas excesivas contenga un puntero del kernel en la respuesta, el atacante conoce la disposición del espacio de direcciones del kernel.
- En la segunda etapa, el atacante secuestra el flujo de control. Explota el mismo bug UAF para desbordar un búfer y sobrescribir un puntero de callback con la dirección de un payload que el atacante ya ha preparado en la memoria del kernel mediante una característica ordinaria del protocolo. Cuando el kernel invoca el callback, el payload encadena una serie de llamadas a funciones existentes del kernel, terminando con un comando de shell elegido por el atacante ejecutándose como root.
Una propiedad clave que hace posible esta condición de carrera es que perder la carrera solo hace fallar el handshake sin bloquear todo el sistema, por lo que un atacante decidido puede reintentar indefinidamente hasta lograrlo. En nuestra prueba de concepto, toma 48 minutos filtrar un puntero del kernel y otros cinco minutos llegar a la ejecución del comando de shell. Esta vulnerabilidad (CVE-2026-98432) fue corregida upstream y portada a todas las ramas estables del kernel mantenidas.
Lo que aprendimos
A lo largo de nuestro proceso de uso de Claude para este trabajo de seguridad, identificamos una serie de ideas que moldearon nuestro enfoque. Creemos que dos son particularmente importantes.
El escalado de cómputo en tiempo de prueba y la diversidad de escáneres aumentan sustancialmente la cantidad de vulnerabilidades que se encuentran. Construimos una plataforma que ejecuta grandes cantidades de agentes de escaneo en paralelo, mide cada escáner según cuántas vulnerabilidades adicionales aporta a la mezcla, y rastrea la cobertura dinámicamente para que los escáneres procesen toda la base de código.
Las estrategias van desde la cobertura pura (¿hay alguna vulnerabilidad en esta función?) hasta las basadas en objetivos (¿expone esta aplicación algo que pueda comprometer los datos de los clientes?) y las basadas en modelos de amenazas (¿hay algo en esta aplicación que eluda su modelo de amenazas documentado?). También usamos Claude para ejecutar análisis automatizado de variantes sobre cada hallazgo confirmado. Todos los hallazgos pasan por un flujo estandarizado de verificación y calificación de riesgos, de modo que podemos experimentar libremente con nuevos escáneres sin bajar el nivel de calidad.
Corregir el backlog existente solo resuelve la mitad del problema; la otra mitad es reducir la velocidad a la que entran nuevas vulnerabilidades en el código base. Para eso, recomendamos escanear en el momento del PR. Incorporamos orientación de seguridad directamente en nuestro proceso de desarrollo mediante un plugin de Claude Code, que hemos publicado abiertamente.
Lo que esto significa para los defensores
Los modelos de frontera tienen la capacidad de descubrir y combinar múltiples vulnerabilidades en un exploit funcional. Estas habilidades históricamente han sido el dominio de pocos equipos especializados con experiencia en estos objetivos. Ahora, es algo que los modelos pueden hacer con poca intervención humana, y luego demostrar produciendo un exploit funcional que cualquiera puede ejecutar y verificar.
Dotar a los defensores de modelos potentes es fundamental para darles ventaja en la corrección de sistemas antes que los atacantes. Recientemente, lanzamos una versión ampliada de nuestro Cyber Verification Program, que pone capacidades cibernéticas avanzadas y clasificadores de bloqueo reducidos a disposición de profesionales de seguridad cualificados. Incluye acceso a nuestros modelos más capaces, incluidos Claude Opus 5.5, Claude Sonnet 5.5, Claude Mythos 5.1 y otros modelos nuevos en el futuro. Nuestro consejo para los defensores sigue siendo el mismo: escanear su propio código es más importante que nunca.
Autores y agradecimientos
Colaboradores
Nicholas Carlini, David Dworken, Xinyang Ge, Ben Morris, Milad Nasr, Chris Rohlf, Luna Tong