Claude hackeó Chrome por 2.283 dólares; Anthropic intentó impedirlo y no lo logró.

Anthropic decidió no publicar públicamente el modelo Mythos, diseñado para buscar vulnerabilidades. La razón es simple: el riesgo resultó demasiado evidente. La herramienta que puede encontrar puntos débiles en el código con la misma facilidad puede indicar también cómo explotarlos, y lo haría más rápido de lo que los desarrolladores tardan en cerrar la vulnerabilidad.

Al mismo tiempo, incluso sin Mythos la situación ya ha cambiado. El investigador Mohan Pedhapati, director técnico de Hacktron, demostró que el modelo disponible Opus 4.6 es capaz de completar un ataque. Reunió una cadena de explotación completa para el motor V8, que se usa en Chrome e integra aplicaciones como Discord.

El experimento llevó alrededor de una semana. Durante ese tiempo el modelo procesó aproximadamente 2,3 mil millones de tokens y los gastos de API ascendieron a 2283 dólares. Pedhapati dirigió el proceso manualmente, sacando al modelo de callejones sin salida y corrigiendo el rumbo del trabajo. Al final consiguió el resultado clásico para demostrar una vulnerabilidad: ejecutar la calculadora en el sistema objetivo. En el entorno profesional, esto es un indicio estándar de que la ejecución de código remota fue lograda.

El detalle principal es que la vulnerabilidad utilizada no es algo exótico. Se trata de un error de desbordamiento de memoria en V8, conocido en versiones recientes de Chrome. La misma rama del motor se usa, por ejemplo, en el cliente de escritorio de Claude. Como objetivo eligieron Discord porque su versión de Electron está notablemente atrasada: incluye Chrome 138, mientras que las versiones actuales han avanzado mucho.

La propia demora en las actualizaciones hace tiempo que se considera un punto débil del ecosistema Electron. Incluso si Google lanza una nueva versión de Chrome, las aplicaciones basadas en él reciben actualizaciones con retraso. Primero se actualiza Electron, luego los desarrolladores deben integrar la nueva versión en sus productos y los usuarios deben instalar la actualización. En cada etapa existe una pausa. En el caso de Discord la brecha llegó a nueve versiones principales.

Ante tales retrasos cambia la economía de los ataques. Unos pocos miles de dólares para generar un exploit ya no parecen tan intimidantes si se comparan con el tiempo que requeriría el desarrollo manual. Sin modelos, la misma tarea podría haber llevado semanas. Al mismo tiempo, los programas oficiales de recompensas por vulnerabilidades de las grandes compañías pagan del orden de 15 000 dólares por hallazgos similares. Fuera del mercado legal las cifras pueden ser mayores, sobre todo si se trata de un 0-day reciente.

Anthropic afirma que la versión más nueva Opus 4.7 es similar en capacidades a la 4.6, pero incorpora mecanismos que monitorizan y bloquean escenarios de uso peligrosos. Al mismo tiempo la propia compañía reconoce que Mythos Preview sigue siendo una herramienta más potente en tareas de ciberseguridad. Las restricciones en los modelos públicos no cambian la tendencia general: la generación de código se vuelve cada vez más precisa y rápida.

Pedhapati considera que el problema no está en un modelo concreto, sino en el ritmo del progreso. Las mejoras continúan sin una desaceleración visible y, tarde o temprano, incluso atacantes novatos con acceso a la API podrán llevar ataques a un estado funcional en software sin actualizar. La cuestión ya no es si es posible, sino cuándo se volverá una práctica masiva.

Un riesgo separado está relacionado con las propias correcciones. Un parche a menudo indica prácticamente dónde buscar la vulnerabilidad. En proyectos de código abierto la situación es aún más difícil: los cambios son visibles inmediatamente tras publicar el commit, mientras que las compilaciones actualizadas salen más tarde. Esa brecha da tiempo adicional a quienes saben transformar rápidamente las correcciones en exploits funcionales.

En consecuencia, cambian también los requisitos para el desarrollo. El énfasis se desplaza hacia una verificación de seguridad más temprana, incluso antes de publicar el código. Hace falta vigilar las dependencias con mayor atención para no arrastrar componentes obsoletos. Según el investigador, las actualizaciones deberían instalarse automáticamente; de lo contrario los usuarios permanecen vulnerables simplemente por no pulsar el botón de actualización. Incluso el enfoque sobre la divulgación de errores puede requerir revisión: cada cambio público se convierte en una señal para quienes saben trabajar con estas herramientas.