El CTO de Hacktron, Mohan Pedhapati (s1r1us), usó Claude Opus 4.6 para construir una cadena de exploit completa contra el motor V8 de Chrome 138 —la versión bundled en Discord— gastando USD 2.283 en llamadas a la API, 2.300 millones de tokens y alrededor de 20 horas de trabajo humano durante una semana. El exploit “popped calc”: ejecutó código en el sistema objetivo.
En 30 segundos
- Mohan Pedhapati usó Claude Opus 4.6 vía API para crear un exploit funcional contra V8 (motor JavaScript de Chrome) en abril de 2026.
- Costo total: USD 2.283 en tokens de API + ~20 horas de trabajo humano para destrabar callejones sin salida.
- El exploit “popped calc”: abrió la calculadora del sistema, prueba estándar de ejecución de código arbitrario.
- Anthropic ya retuvo su modelo especializado en búsqueda de bugs por razones de seguridad, pero Opus 4.6 —disponible públicamente vía API— resultó capaz igual.
- La implicación directa: el tiempo de desarrollo de exploits cae drásticamente cuando un LLM hace el trabajo pesado.
Claude es un modelo de inteligencia artificial desarrollado por Anthropic que procesa y genera texto, responde preguntas complejas y asiste en tareas de programación y análisis de información. Disponible desde 2023 mediante API y aplicaciones web.
Claude Opus 4.6 es el modelo de lenguaje grande de Anthropic publicado en la línea Opus antes de que Opus 4.7 lo reemplazara. Está disponible vía API y, según este caso documentado por Pedhapati el 16 de abril de 2026, tiene la capacidad técnica de asistir en el desarrollo de exploits funcionales contra software de producción.
El experimento: Claude Opus exploit Chrome, paso a paso
Pedhapati no arrancó con algo oscuro o teórico. Eligió Chrome V8 —el motor JavaScript que corre dentro de Chrome y, por ende, dentro de Discord— y apuntó a un out-of-bounds error en Chrome 138. Lo interesante es que, según The Register, la versión de V8 que terminó explotando fue Chrome 146, la misma que corre el propio Claude Desktop de Anthropic. (Sí, en serio.)
La dinámica fue iterativa: una semana de ida y vuelta con el modelo, destrabando dead ends, redirigiendo cuando Claude se quedaba atascado, verificando cada pieza del exploit antes de ensamblar la cadena completa. Al final, el código ejecutó. “It popped calc” —abrió la calculadora del sistema operativo— que es la prueba de concepto estándar en seguridad ofensiva para demostrar ejecución de código arbitrario.
No fue solo “preguntale a Claude cómo explotar Chrome”. Fueron 20 horas de trabajo humano experto más 2.300 millones de tokens de modelo.
¿Por qué V8 y por qué importa que esté en Discord?
V8 es el motor JavaScript de Google. Chrome lo usa, Node.js lo usa, Electron lo usa. Y Discord está construido sobre Electron, que bundlea Chromium con su propio V8. Eso significa que un exploit contra V8 en Chrome 138 no afecta solo a los que usan ese browser: también golpea a millones de usuarios de Discord que nunca actualizaron o que corren una versión que todavía lleva ese V8 específico.
Un out-of-bounds error en V8 permite leer o escribir memoria fuera de los límites asignados a un array o buffer. En la práctica: con el payload correcto, podés ejecutar código arbitrario en el proceso del renderer, y desde ahí escalar. No es una vuln hipotética, es una clase de bugs que aparece con regularidad en los changelogs de seguridad de Chrome. Lo explicamos a fondo en a diferencia de otros modelos de Claude.
¿Alguien verificó de forma independiente el exploit completo? No hay disclosure técnico público todavía, pero Pedhapati describió el proceso con suficiente detalle en la comunidad de Hacktron como para que sea tomado en serio.
Costo vs. tiempo: lo que realmente cambia
USD 2.283 parece mucho. Y para un individuo explorando por su cuenta, es un gasto que hay que justificar. Pero poné ese número en contexto: un investigador de seguridad senior que desarrolla un exploit similar sin asistencia de IA puede tardar semanas de trabajo. Si ese tiempo valiera USD 100/hora (conservador para un especialista en ofensive security), estamos hablando de USD 4.000 a USD 16.000 solo en tiempo humano.
Pedhapati invirtió 20 horas de su tiempo más los USD 2.283 de API. El modelo hizo el trabajo pesado de generación, iteración y ajuste de código. Él fue el piloto que evitó que Claude se perdiera en callejones sin salida.
El punto no es que sea barato. El punto es que el ratio costo/resultado ya rompió el umbral donde el exploit manual era claramente más conveniente. Y ese umbral va a seguir cayendo.
Opus 4.6 público vs. el modelo que Anthropic no quiso lanzar
Acá viene la parte que más genera debate. Anthropic tiene —o tenía en desarrollo— un modelo especializado en encontrar bugs de seguridad. Decidió no lanzarlo públicamente porque les preocupaba que los atacantes pudieran encontrar vulnerabilidades antes de que los vendors tuvieran tiempo de parchear.
Decisión razonable sobre el papel.
El problema es que Opus 4.6, el modelo de propósito general que sí está disponible vía API, resultó capaz de hacer lo mismo con suficiente guía humana. No necesitás el modelo especializado si tenés un experto que sabe cómo hacer las preguntas correctas y destrabar al modelo cuando se atasca. Cubrimos ese tema en detalle en comparado con otros generadores de código.
Opus 4.6 ya fue superado por Opus 4.7, lanzado el jueves 17 de abril según el artículo de The Register. Pero Opus 4.6 sigue disponible vía API. Y lo que demostró este experimento es que la contención del modelo especializado no resuelve el problema de fondo.
¿Qué es una cadena de exploit completa?
Ponele que encontrás un out-of-bounds bug en V8. Eso solo no alcanza para hacer daño. Necesitás una cadena: primero la primitiva de lectura/escritura de memoria, después bypass del sandbox del renderer, después escalada de privilegios o persistencia, y recién ahí tenés algo que un atacante puede usar.
Cada eslabón de esa cadena requiere conocimiento técnico específico, iteración y prueba. Lo que hizo Claude en este caso fue asistir en la construcción de cada eslabón, con Pedhapati dirigiendo el proceso y corrigiendo cuando el modelo generaba código que no compilaba o que asumía primitivas incorrectas.
“Full exploit chain” en este contexto significa que el código no solo triggerea el bug sino que completa el flujo hasta ejecución de código arbitrario. El “popped calc” es la prueba visible de que ese flujo funcionó de punta a punta.
Implicaciones de seguridad: ¿quién puede hacer esto ahora?
La frase que Pedhapati dejó caer es la que se está citando en todos lados: “Eventually, any script kiddie with enough patience and an API key will be able to pop shells.”
Tomalo con pinzas, porque hoy todavía necesitás saber lo suficiente como para guiar al modelo, interpretar el output, y destracar los dead ends. Pedhapati es CTO de Hacktron y tiene background en seguridad ofensiva. No fue un experimento de alguien sin contexto. Esto se conecta con lo que analizamos en según estándares de seguridad corporativa.
Pero la dirección es clara: la barrera de conocimiento para exploit development está bajando. El modelo absorbe parte del trabajo de bajo nivel —generar código, iterar variantes, buscar gadgets—, y el humano pasa a ser más coordinador que programador. Ese cambio de rol tiene consecuencias directas para el tiempo y costo de desarrollo de exploits.
| Método | Tiempo estimado | Costo estimado | Conocimiento requerido |
|---|---|---|---|
| Exploit manual (especialista senior) | 2-6 semanas | USD 8.000-24.000 (tiempo) | Muy alto |
| Claude Opus 4.6 + experto humano | 1 semana + 20h activas | USD 2.283 API + tiempo humano | Alto (para guiar el modelo) |
| Modelo especializado en bugs (hipotético, no lanzado) | Desconocido | Desconocido | Potencialmente menor |
Las preocupaciones de Anthropic y el límite real de la contención
Anthropic tomó la decisión de no lanzar su modelo especializado en búsqueda de vulnerabilidades. La lógica es que un atacante con acceso a ese modelo podría encontrar bugs antes de que Google, Microsoft o cualquier vendor pudiera parchear. La ventana de exposición sería crítica.
El problema es que esa lógica asume que el modelo público no puede hacer lo mismo. Y este experimento muestra que la diferencia es de grado, no de naturaleza. Opus 4.6 no está optimizado para bug hunting, pero con el guido correcto llegó a un exploit funcional contra Chrome V8.
Dicho esto, hay un tradeoff real: el modelo especializado probablemente reduciría las 20 horas de trabajo humano a mucho menos, y bajaría el umbral de conocimiento requerido. Esa diferencia no es trivial. Pero el experimento de Pedhapati deja claro que la barrera ya fue cruzada por los modelos disponibles hoy.
Errores comunes al interpretar este caso
Pensar que cualquiera puede replicarlo sin conocimiento previo
Pedhapati tiene background técnico profundo en seguridad ofensiva. El modelo no puede reemplazar ese conocimiento base: necesitás saber qué preguntarle, cómo interpretar el output, y cuándo el código generado tiene un error conceptual que no va a saltar como error de compilación sino como fallo silencioso en runtime. Sin ese conocimiento, los USD 2.283 se van en tokens que no llevan a ningún lado.
Asumir que este exploit afecta a la versión actual de Chrome
El bug era en Chrome 138, y la cadena se verificó contra Chrome 146 (la versión en Discord y Claude Desktop al momento del experimento). Eso no significa que Chrome actual sea vulnerable hoy —Google parchea con frecuencia y el artículo no establece que el bug siga abierto. Si corrés Chrome actualizado, la superficie de ataque de este exploit específico puede ser diferente. Tema relacionado: tal como sucede con otros LLMs.
Creer que Anthropic puede simplemente “bloquear” este tipo de uso
Los guardrails de un modelo de propósito general tienen límites. Un experto que hace las preguntas correctas, divide el problema en partes aparentemente inocuas, y ensambla el resultado puede sortear muchos filtros de contenido. No es trivial, pero este caso muestra que es posible. Ningún fabricante de modelos tiene una solución técnica definitiva para esto todavía.
Podés ver el análisis completo en Claude Opus wrote a Chrome exploit for 2,283.
Si te interesa profundizar, revisá nuestro análisis en Claude Opus wrote a Chrome exploit for 2,283.
Preguntas Frecuentes
¿Qué significa “popped calc” en un exploit?
“Popped calc” significa que el exploit logró abrir la aplicación Calculadora del sistema operativo objetivo. Es la prueba de concepto estándar en seguridad ofensiva: si podés ejecutar calc.exe (Windows) o la calculadora equivalente en el sistema atacado, demostrás que tenés ejecución de código arbitrario. No causa daño directo, pero confirma que el exploit funciona de punta a punta y que cualquier otro payload podría correr en su lugar.
¿Cuánto costó crear el exploit de Chrome con Claude Opus?
USD 2.283 en llamadas a la API de Claude Opus 4.6, consumiendo 2.300 millones de tokens durante una semana de trabajo. A ese costo se suman aproximadamente 20 horas de trabajo humano del investigador Mohan Pedhapati, CTO de Hacktron, quien dirigió el proceso y destrabó los callejones sin salida. El costo total sigue siendo significativamente menor que el tiempo que tomaría desarrollar un exploit equivalente manualmente.
¿Por qué Anthropic no lanzó su modelo especializado en bugs al público?
Anthropic decidió retener el modelo porque les preocupaba que facilitara ataques antes de que los vendors pudieran reaccionar con parches. La lógica es que un modelo optimizado para encontrar vulnerabilidades reduciría drásticamente el tiempo de descubrimiento, acortando la ventana disponible para que Google, Microsoft u otros parcheen. Opus 4.6, aunque no está especializado en bugs, demostró ser capaz de asistir en exploit development con guía experta.
¿Qué es un out-of-bounds error en V8?
Es un bug donde el motor JavaScript lee o escribe memoria más allá de los límites de un array o buffer asignado. En V8, el motor que corre JavaScript en Chrome y aplicaciones Electron como Discord, este tipo de error puede usarse como punto de entrada para una cadena de exploit: primero se obtiene una primitiva de lectura/escritura de memoria, y desde ahí se escala hacia ejecución de código arbitrario en el proceso.
¿Cualquiera puede crear exploits con Claude Opus usando una API key?
No, al menos no hoy. El experimento de Pedhapati requirió conocimiento técnico profundo en seguridad ofensiva para guiar al modelo, interpretar el output, y corregir los errores conceptuales que Claude no detecta solo. Sin ese background, los tokens se gastan en código que no lleva a ningún exploit funcional. La barrera bajó, pero no desapareció. La frase “cualquier script kiddie con paciencia” es una proyección hacia el futuro, no una descripción del presente.
Conclusión
El caso de Pedhapati es un dato concreto en un debate que hasta ahora era mayormente teórico: los modelos de lenguaje grandes de propósito general ya pueden asistir en la construcción de exploits funcionales contra software de producción. No mañana, no con el modelo hipotético que Anthropic decidió no lanzar. Con Opus 4.6, disponible hoy, por USD 2.283 en API calls.
Eso no significa que el mundo se vino abajo. Significa que las ventanas de exposición post-descubrimiento se van a acortar, que el bug bounty va a cambiar, y que los equipos de seguridad defensiva tienen una razón más para invertir en detección y respuesta rápida en vez de asumir que la oscuridad técnica los protege.
Lo que Anthropic decide hacer con esta información —cómo ajusta sus guardrails, si publica algo sobre el incidente, si cambia los términos de uso de la API— va a ser interesante de seguir. Por ahora, la respuesta oficial fue silencio y el lanzamiento de Opus 4.7 al día siguiente.