Cuando tu agente encuentra una vulnerabilidad

Nicholas Carlini, científico investigador en Anthropic, apuntó Claude Code al código fuente del kernel de Linux y le dijo que buscara vulnerabilidades. La configuración: un script de bash de 10 líneas más un contenedor Docker con builds instrumentados con ASAN. Itera sobre archivos fuente, pide al modelo que busque bugs, pasa al siguiente archivo.¹³

El resultado, tal como lo detalla el artículo de Michael Lynch sobre la charla:² un desbordamiento de búfer en el heap explotable de forma remota en la caché de reintento de NFSv4 LOCK, presente desde marzo de 2003, anterior al propio Git. Dos clientes NFS cooperantes pueden leer memoria sensible del kernel desbordando un búfer de 112 bytes con un ID de propietario de bloqueo de 1.024 bytes. Carlini encontró al menos cuatro vulnerabilidades más en el kernel en la misma pasada. Por separado, la misma metodología produjo 122 inputs que provocaban crashes enviados a Mozilla, de los cuales 22 recibieron CVE.³ Describió “varios cientos de crashes” que no ha tenido tiempo de validar y reportar.²

Carlini confirmó estas vulnerabilidades y las reportó a los mantenedores. Las encontró con Opus 4.6, la misma clase de modelo que los profesionales usan a diario para revisión de código, refactorización y desarrollo de funciones. Carlini presentó los hallazgos en la conferencia de seguridad de IA [un]prompted en abril de 2026.¹

Sí, los agentes de IA pueden encontrar vulnerabilidades de seguridad reales que los expertos humanos pasaron por alto durante décadas. Un investigador de Anthropic usó Claude Code con un script de bash de 10 líneas para descubrir un desbordamiento de búfer en el heap explotable remotamente de 23 años de antigüedad en el kernel de Linux y produjo 22 CVE de Firefox a partir de 122 inputs que provocaban crashes. La metodología no requiere ningún framework personalizado: itera sobre archivos fuente con builds instrumentados con ASAN y pide al modelo que busque bugs.

TL;DR

La metodología de Carlini fue mínima: iterar sobre archivos fuente, pedir a Claude que busque vulnerabilidades en cada uno, verificar los hallazgos con aserciones de ASAN. Opus 4.6 encontró sustancialmente más vulnerabilidades que Opus 4.1 (8 meses más antiguo) o Sonnet 4.5 (6 meses más antiguo), lo que sugiere que la capacidad cruzó un umbral recientemente.² El cuello de botella ahora es la validación humana, no el descubrimiento por IA. El cambio tiene implicaciones directas sobre cómo los profesionales construyen hooks de seguridad, ejecutan revisiones de código y piensan sobre auditorías asistidas por agentes.

Puntos clave

• Ingenieros de seguridad: La capacidad es real y mejora rápido. Si ejecutas revisiones de código asistidas por agentes, tus hooks de seguridad PreToolUse importan más que nunca. No para bloquear a Claude, sino para controlar qué puede hacer con lo que encuentra.
• Constructores de harnesses: El cuello de botella de verificación (“varios cientos de crashes que no he validado”) es un problema del harness. El triaje automatizado, la deduplicación y la clasificación de severidad son la siguiente capa de infraestructura.
• Todos los demás: El mismo modelo que introduce regresiones de rendimiento de 446x también encuentra bugs que 23 años de revisión humana pasaron por alto. Ambas cosas son ciertas simultáneamente.

La metodología

El enfoque de Carlini no requirió un framework de seguridad personalizado, un modelo ajustado ni prompts especializados. Lo describió como un “script de bash de 10 líneas más un contenedor Docker”:³

1. Compilar el objetivo con instrumentación ASAN (AddressSanitizer)
2. Iterar a través de archivos fuente, usando el modelo para evaluar la relevancia de seguridad
3. Pedir a Claude Code con un enfoque de capture-the-flag para los archivos de alta relevancia
4. Ejecutar múltiples pasadas por objetivo (de 5 a 20 según el código base)
5. Usar agentes de crítica automatizados para verificar los hallazgos antes de la divulgación

El enfoque de capture-the-flag importa. Decirle al modelo “este código tiene un bug” activa un modo diferente al de “revisa este código en busca de problemas”. Los desarrolladores notan el mismo patrón en el uso diario: Claude encuentra más problemas cuando le dices que existe un problema que cuando le preguntas si podría existir uno.²

La pasada cuesta API tokens, no persona-meses. Carlini encontró cinco vulnerabilidades confirmadas del kernel de Linux y 22 CVE de Firefox usando un agente commodity CLI.³ La misma herramienta que escribe tus tests unitarios y formatea tus imports.

El umbral de capacidad

El hallazgo más llamativo es la brecha entre generaciones de modelos. Carlini intentó reproducir sus resultados con modelos más antiguos:²

• Opus 4.6 (lanzado ~2 meses antes de la charla): encontró el desbordamiento de heap y múltiples vulnerabilidades adicionales
• Opus 4.1 (8 meses antes): encontró solo una pequeña fracción
• Sonnet 4.5 (6 meses antes): encontró solo una pequeña fracción

Algo cruzó un umbral entre generaciones de modelos. La capacidad de mantener un código base complejo en contexto, razonar sobre el flujo de datos a través de los límites de las funciones e identificar desajustes sutiles en las especificaciones parece haber emergido en lugar de mejorar gradualmente.

Carlini lo dijo claramente: “Nunca en mi vida había encontrado uno de estos. Esto es muy, muy, muy difícil de hacer. Con estos modelos de lenguaje, tengo un montón”.²

La paradoja

La misma arquitectura de agentes que introduce regresiones de rendimiento — 118 funciones con ralentizaciones de entre 3x y 446x — también encuentra vulnerabilidades de seguridad que décadas de revisión humana experta pasaron por alto. Son aspectos complementarios del mismo perfil de capacidad. La investigación de vulnerabilidades es fundamentalmente coincidencia de patrones contra clases conocidas (desbordamientos de búfer, use-after-free, signedness de enteros), que es una fortaleza del LLM.⁴ La optimización de rendimiento requiere lo opuesto: razonar sobre contextos de ejecución específicos, comportamiento de caché y complejidad algorítmica. El modelo reconoce un desbordamiento de búfer a lo largo de millones de líneas de código, pero no puede decirte que un hash map es más lento que un arreglo ordenado para tu patrón de acceso. Construye tu harness en consecuencia, con hooks de seguridad que marquen hallazgos y hooks de rendimiento que midan antes de hacer commit.

El cuello de botella de la verificación

La admisión más reveladora de Carlini: “Tengo tantos bugs en el kernel de Linux que no puedo reportar porque aún no los he validado”.²

El cuello de botella ahora está en el triaje, no en el descubrimiento. Encontrar vulnerabilidades potenciales cuesta menos que confirmar que son reales. La inversión crea un nuevo problema de infraestructura para los equipos de seguridad:

El descubrimiento está automatizado. Un agente puede barrer un código base en horas.

La verificación es manual. Cada vulnerabilidad potencial necesita una prueba de concepto, una evaluación de impacto y un proceso de divulgación responsable.

El triaje es la brecha. Clasificar cientos de hallazgos generados por agentes en vulnerabilidades reales, falsos positivos y ruido de baja severidad es el trabajo que aún no tiene buenas herramientas.

El patrón refleja la revisión de código asistida por agentes: el agente produce output crudo más rápido de lo que los humanos pueden evaluarlo. El valor no vive en la generación sino en la infraestructura que procesa, filtra y enruta la salida.

Para los constructores de harnesses, esto significa que el próximo hook de alto valor no es un escáner de seguridad. Es un sistema de triaje de seguridad: deduplicación, clasificación de severidad, filtrado de falsos positivos y generación automática de pruebas de concepto. Los hooks de gobernanza que controlan la salida del agente son más importantes que las propias capacidades de escaneo.

Qué significa esto para los profesionales

Si ejecutas Claude Code en código base de producción, ya estás ejecutando un sistema capaz de encontrar vulnerabilidades reales. La pregunta no es si la capacidad existe sino si tu harness puede manejar lo que el agente encuentra.

Tres movimientos prácticos:

Añade un barrido de seguridad a tu pipeline de revisión. Un hook PostToolUse en Write/Edit puede desencadenar un escaneo de seguridad dirigido sobre los archivos modificados. El hook lee la ruta del archivo desde stdin (Claude Code pasa el JSON del evento por stdin a los hooks):

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking, runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

El hook anterior es un punto de partida, no algo listo para producción. Añadirías deduplicación, filtrado por severidad y límites de tasa. Pero el patrón central coincide con la metodología de Carlini: un bucle sobre archivos con un prompt dirigido.³

Construye infraestructura de triaje. Los hallazgos de vulnerabilidades crudos sin clasificación de severidad son ruido. Si tu agente produce 50 hallazgos por barrido, necesitas deduplicación automatizada y puntuación de prioridad antes de que un humano vea la lista. El cuello de botella es un problema del harness, no un problema del modelo.

Acepta la paradoja. El mismo modelo que necesita salvaguardas de rendimiento es genuinamente excelente en la coincidencia de patrones de seguridad. Diseña tu harness para aprovechar la fortaleza y compensar la debilidad. Hooks de seguridad que escanean. Hooks de rendimiento que miden. Hooks de calidad que verifican. Cada uno cubre lo que los otros pasan por alto.

La vulnerabilidad de 23 años en Linux no estaba escondida. Estaba a la vista, en un archivo que miles de ingenieros habían leído. El modelo la encontró porque la coincidencia de patrones a escala es lo que hacen estos sistemas. La lección no es que los agentes sean mejores que los humanos en seguridad. La lección es que los agentes cubren una superficie diferente — y el harness que orquesta ambos es lo que hace que la combinación sea confiable.

Actualización (7 de abril de 2026): Anthropic anunció Project Glasswing, un nuevo modelo llamado Claude Mythos que escaló el enfoque de Carlini a miles de zero-days en todas las plataformas principales. Mythos sigue restringido a 12 partners y no está disponible públicamente. El artículo anterior cubre la investigación original de Carlini; la continuación cubre la productización.

Fuentes

Preguntas frecuentes

¿Puedo reproducir el enfoque de Carlini con Claude Code?

Carlini documentó la metodología en la entrevista del podcast.³ El bucle central: compilar con ASAN, iterar sobre archivos fuente, pedir a Claude con un enfoque de capture-the-flag, verificar los hallazgos. Carlini reportó que Opus 4.6 encontró significativamente más vulnerabilidades que modelos más antiguos, así que los resultados con otras generaciones de modelos pueden variar.

¿Significa esto que los agentes de IA son mejores que los humanos encontrando bugs de seguridad?

No. Significa que los agentes cubren una superficie diferente. Los agentes destacan en la coincidencia de patrones contra clases conocidas de vulnerabilidades en códigos base grandes. Los humanos destacan en entender vectores de ataque novedosos, fallos de lógica de negocio y propiedades de seguridad dependientes del contexto. La combinación es más fuerte que cualquiera de las dos por separado.

¿Debería preocuparme por atacantes que usen esta capacidad?

Carlini advirtió explícitamente sobre “una gran ola que se aproxima”. La misma capacidad que ayuda a los defensores a encontrar vulnerabilidades está disponible para los atacantes. La asimetría es que los defensores pueden automatizar el triaje y el parcheo, mientras que los atacantes aún necesitan desarrollar exploits. Pero la brecha de descubrimiento se está cerrando.