Anthropic afirma que Claude encontró cinco cadenas de explotación y vulnerabilidades críticas

Cinco investigaciones, no una auditoría independiente

Anthropic publicó un informe en el que describe el uso de un modelo interno de investigación, todavía no publicado, para buscar vulnerabilidades en software ampliamente utilizado. La empresa presenta cinco cadenas de explotación: una en Chrome, otra en Safari, un bypass de pantalla de bloqueo en Android, una denegación remota de servicio en Windows y ejecución remota de comandos en Linux. Son afirmaciones de Anthropic sobre su propio trabajo, no resultados verificados de forma independiente en la documentación disponible.

El informe aporta detalles técnicos y dice que las vulnerabilidades se comunicaron a los proveedores correspondientes. Anthropic afirma que los fallos descritos fueron corregidos, pero el grado de detalle público no es idéntico en los cinco casos y no permite tratar cada cadena como una prueba reproducida por terceros. Además, el modelo empleado era interno y no publicado: los resultados no demuestran que cualquier usuario pueda obtener las mismas capacidades con un modelo disponible al público.

La distinción importante es entre descubrir un fallo, construir una prueba de concepto y demostrar un impacto bajo una configuración concreta. El documento ofrece ejemplos de las tres etapas, pero la descripción de Anthropic no equivale a una evaluación externa de la tasa de éxito, los recursos necesarios o la generalización del método a otros productos. Tampoco basta para atribuir a un modelo, por sí solo, todo el trabajo de análisis, selección y comprobación que forma parte de una investigación de seguridad.

Chrome y Safari: cadenas que combinan varios fallos

En Chrome, Anthropic describe una cadena que comenzaba con un fallo de corrupción de memoria en V8, el motor de JavaScript. Según el informe, el proceso avanzaba mediante otros defectos para salir de límites de memoria y del aislamiento del navegador, hasta alcanzar ejecución de código fuera del sandbox. La demostración citada por la empresa abría la aplicación Calculadora en un Chrome con configuración predeterminada en macOS. Ese ejemplo ilustra el impacto alegado en una configuración concreta; no demuestra que todas las instalaciones o versiones fueran vulnerables.

La publicación señala que Google asignó 62 identificadores CVE a los hallazgos y que, a fecha del informe, se habían corregido en Chrome 156; Anthropic los describe como de gravedad crítica o alta. También atribuye a ese conjunto 13 escapes de sandbox y 21 fallos que podían comprometer el proceso renderer. Estos números se refieren al recuento comunicado por Anthropic y no deben interpretarse como 62 cadenas completas de explotación independientes.

Para Safari, el informe presenta un ataque distinto: el objetivo era eludir la política del mismo origen, que normalmente impide que una página lea datos de otros sitios. Anthropic describe una combinación de un uso después de liberar en JavaScriptCore, acceso de lectura y escritura fuera de una zona protegida y una vulnerabilidad en el mecanismo IPC del sandbox. La cadena habría permitido acceder a datos locales del navegador y modificar una señal de seguridad para desactivar la política del mismo origen. La empresa precisa que no dependía de ejecución arbitraria de código; combinaba acceso a memoria y cambios de estado.

El caso muestra por qué un fallo aislado no siempre explica el riesgo completo. Algunas condiciones descritas serían comportamientos previstos que, combinados con otras debilidades, contribuyeron al ataque. Anthropic afirma que Apple reconoció el reporte e implementó una corrección disponible para usuarios. El artículo no aporta una evaluación externa que permita medir cuántos usuarios estuvieron expuestos ni el alcance de explotación real.

Android, Windows y Linux: tres objetivos y tres impactos

En Android, Anthropic describe un bypass que habría permitido extraer fotos y otra información personal de un teléfono Pixel 9 bloqueado. La investigación combinó análisis de partes de código abierto, ingeniería inversa de componentes de Google Play y pruebas en un dispositivo físico. La cadena reportada atravesaba varias protecciones: transferencia USB, autorización de emparejamiento, verificación de un código y un control sobre el envío de archivos. Google habría abordado el problema, según la publicación. El informe no ofrece en el extracto una lista completa de versiones afectadas o de dispositivos expuestos.

En Windows, el hallazgo fue una lectura fuera de límites en la implementación del protocolo QUIC del kernel. Anthropic afirma que un atacante remoto podía enviar unos pocos paquetes a un servidor que respondiera a solicitudes HTTP/3 y provocar que se bloqueara y reiniciara. La empresa dice que Microsoft corrigió el fallo y le asignó el identificador CVE-2026-33096. El trabajo descrito se basó en análisis de un ejecutable y herramientas de ingeniería inversa; el impacto señalado es denegación de servicio, no toma de control remoto.

Para Linux, Anthropic informa de una vulnerabilidad de uso después de liberar causada por una condición de carrera en la pila de red del kernel, en sistemas con un listener MPTCP. La cadena alegada tenía dos etapas: revelar una dirección del kernel y luego alterar el flujo de control para ejecutar un comando como administrador. La empresa indica que la vulnerabilidad recibió el identificador CVE-2026-98432, se corrigió en el proyecto y se trasladó a las ramas estables mantenidas. Anthropic calcula que su prueba de concepto tardaba unos 48 minutos en obtener una dirección del kernel y otros cinco en alcanzar la ejecución de comandos; esos tiempos describen esa demostración, no una garantía de rendimiento general.

Los tres ejemplos no son intercambiables: el caso de Windows es una interrupción remota del servicio, mientras que los ejemplos de Chrome y Linux describen ejecución de código o comandos bajo las condiciones detalladas. Android se centra en el acceso a datos sin desbloquear el dispositivo. Evaluar el riesgo requiere considerar el producto, la versión, la configuración y las correcciones instaladas, no solo la etiqueta de gravedad.

El método: muchos escáneres y verificación posterior

Anthropic atribuye parte de los resultados a una plataforma que ejecuta numerosos agentes de análisis en paralelo. La empresa dice que mide cuánto aporta cada escáner y sigue la cobertura del código. Las estrategias descritas incluyen buscar fallos función por función, perseguir objetivos concretos —como la exposición de datos— y comprobar si una aplicación rompe su modelo de amenazas documentado.

El informe también menciona análisis automatizado de variantes: una vez confirmado un hallazgo, se buscan casos similares. Anthropic afirma que los resultados pasan por un proceso estandarizado de verificación y clasificación de riesgo. Eso es relevante porque generar una hipótesis sobre un fallo no basta para establecer que sea reproducible o explotable. Sin embargo, la publicación no detalla en profundidad los criterios completos de aceptación, la cantidad de falsos positivos ni una comparación controlada con equipos humanos o herramientas alternativas.

Como recomendación para desarrolladores, Anthropic propone integrar análisis de seguridad durante la revisión de cambios de código, además de resolver vulnerabilidades ya conocidas. La lógica es preventiva: revisar cambios nuevos puede ayudar a detectar defectos antes de incorporarlos. Pero una recomendación o un análisis automatizado no garantiza que todo fallo sea detectado, ni que el software resultante esté libre de vulnerabilidades. La eficacia dependerá del alcance del escaneo, el contexto disponible, la revisión humana y la respuesta del equipo.

La publicación también destaca el escalado del cómputo durante las pruebas y la diversidad de escáneres. Son decisiones de configuración y metodología que, según la empresa, aumentaron el número de vulnerabilidades encontradas en su proceso. No implican que aumentar recursos siempre produzca mejores resultados ni que un modelo genere hallazgos correctos sin revisión. El propio énfasis en la verificación muestra que la detección y la confirmación son etapas distintas.

Qué cambia para defensores y qué no demuestra el informe

El resultado más relevante para los equipos de seguridad es que, según Anthropic, un modelo fue capaz de conectar varios defectos en productos complejos y construir pruebas de concepto con impactos distintos. La investigación automatizada podría ampliar la capacidad de revisar código y acelerar el análisis de variantes. La misma capacidad también tiene un uso ofensivo potencial, por lo que los hallazgos refuerzan la importancia de gestionar parches, limitar exposición y someter los sistemas a pruebas autorizadas.

Anthropic sostiene que estas habilidades, antes concentradas en equipos especializados, pueden quedar al alcance de modelos con poca intervención humana. Esa es una interpretación de la empresa basada en sus experimentos; el informe no presenta una comparación independiente que cuantifique cuánto trabajo humano se necesitó ni cuánto más rápido fue el proceso frente a métodos habituales. Tampoco permite inferir que un atacante sin experiencia pueda reproducir con facilidad las cinco cadenas.

El documento identifica al modelo como un sistema interno de investigación aún no publicado. Por tanto, no es correcto trasladar automáticamente estos resultados a versiones públicas de Claude ni asumir que una interfaz accesible reproduce el mismo comportamiento. El acceso a herramientas, el tiempo de cómputo, la información inicial, los límites de seguridad y la supervisión humana pueden cambiar sustancialmente el resultado.

La cautela es especialmente importante al comparar esta publicación con otros incidentes de seguridad. La publicación de Anthropic sobre vulnerabilidades en productos de terceros no confirma que una empresa externa haya penetrado los sistemas internos de Anthropic, ni aporta datos sobre un supuesto ataque de Cathedral. Son asuntos distintos. Con la información disponible aquí, no hay base suficiente para afirmar quién habría accedido a qué sistemas, cuánto habría tardado o qué datos habría obtenido.

Para organizaciones que gestionan software, la conclusión práctica no es confiar en que un modelo encuentre todos los fallos. Conviene mantener inventario de activos, aplicar actualizaciones, revisar componentes expuestos y validar los hallazgos en un entorno autorizado. Los equipos pueden usar herramientas automatizadas como apoyo, pero deben conservar controles de acceso, revisión humana y procedimientos de divulgación coordinada. El informe ofrece ejemplos concretos de riesgos y reparaciones comunicadas; no es una garantía de seguridad ni una demostración universal de capacidad.

Cómo interpretar el valor operativo de estos hallazgos

Los detalles técnicos tienen valor porque permiten distinguir clases de impacto y entender cómo los fallos se refuerzan entre sí. En una revisión defensiva, una cadena puede ser más importante que un defecto aislado si combina una vulnerabilidad de memoria con una vía para cruzar un límite de seguridad. Aun así, la prioridad de respuesta debe basarse en la exposición real, las versiones desplegadas, la disponibilidad de parches y la posibilidad de mitigación, no solo en una demostración llamativa.

Los equipos pueden usar los hallazgos publicados para comprobar inventarios y actualizaciones de los productos afectados, sin intentar reproducir una cadena contra sistemas ajenos. Si se estudia una vulnerabilidad, el trabajo debe hacerse en laboratorios controlados, con autorización y versiones preparadas para pruebas. Las pruebas de concepto de seguridad pueden generar efectos no deseados si se ejecutan en producción o contra infraestructura de terceros.

La recomendación de incorporar revisiones en el proceso de desarrollo tampoco elimina la necesidad de defensa en profundidad. Las comprobaciones automáticas pueden detectar patrones conocidos o señalar código sospechoso, mientras que el análisis humano aporta contexto y decide el riesgo. Ninguno de los dos mecanismos, por separado, garantiza cobertura total. La utilidad reside en combinar detección, validación, corrección y seguimiento.

En suma, el informe presenta evidencia detallada de lo que Anthropic dice haber logrado en una investigación interna y de los pasos de divulgación y reparación que atribuye a los proveedores. Es una señal relevante sobre la evolución de la investigación asistida por modelos, pero su alcance debe mantenerse acotado: resultados de una empresa, en sistemas concretos y con un modelo no publicado, sin una replicación independiente documentada en las fuentes disponibles.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.