Claude Code descubrió una vulnerabilidad de Linux oculta durante 23 años

• Claude Code de Anthropic detectó automáticamente una vulnerabilidad del kernel de Linux explotable de forma remota, encontrando un desbordamiento de búfer en el heap del controlador NFS que había pasado desapercibido durante 23 años
• Con solo el prompt “¿dónde están las vulnerabilidades de seguridad?”, analizó todo el kernel e identificó la falla casi sin supervisión
• El error se originó en el diseño de un búfer fijo de 112 bytes en código del kernel de 2003 y apareció después, al agregarse la operación LOCK, por la falta de un límite para la longitud del owner ID
• Además, Carlini encontró cientos de posibles vulnerabilidades del kernel, pero la mayoría aún no se reporta debido al cuello de botella de la verificación humana
• El modelo más reciente, Claude Opus 4.6, mostró una capacidad de detección muy superior a la de versiones anteriores, por lo que se considera un punto de inflexión para la investigación de seguridad basada en IA

---

Claude Code descubrió una vulnerabilidad de Linux oculta durante 23 años

• Nicholas Carlini, investigador de Anthropic, encontró varias vulnerabilidades del kernel de Linux explotables de forma remota usando Claude Code
  • Una de ellas fue una vulnerabilidad de desbordamiento de búfer en el controlador NFS (Network File System) que había permanecido sin descubrir durante 23 años
  • Carlini expresó su sorpresa por el desempeño de Claude Code, diciendo que “nunca había encontrado personalmente este tipo de vulnerabilidad”

• Cómo detecta vulnerabilidades Claude Code

  • Claude Code detectó vulnerabilidades de seguridad en el kernel de Linux casi sin supervisión
    • Carlini simplemente le dio el prompt “¿dónde están las vulnerabilidades de seguridad?” y lo configuró para recorrer todos los archivos fuente del kernel
  • El script utilizado estaba diseñado para que Claude Code, asumiendo un escenario de CTF (competencia de hacking), registrara la vulnerabilidad más grave de cada archivo en /out/report.txt
    • Con el comando find se recorrían todos los archivos y, para cada uno, se ejecutaba repetidamente Claude Code para buscar vulnerabilidades
  • Se diseñó para evitar reportes duplicados de la misma vulnerabilidad, analizando individualmente todos los archivos del kernel

• Vulnerabilidad de NFS (Network File System)

  • La principal vulnerabilidad encontrada por Claude Code fue un desbordamiento de búfer en el heap del controlador NFS de Linux, que permitía a un atacante leer memoria del kernel a través de la red
  • El escenario de ataque se realiza con dos clientes NFS que cooperan (Client A, Client B) contra un mismo servidor NFS
    • Client A solicita y obtiene un bloqueo de archivo usando un owner ID largo de 1024 bytes
    • Luego, cuando Client B solicita un bloqueo sobre el mismo archivo, el servidor lo rechaza y genera un mensaje de respuesta
  • El problema es que este búfer de respuesta de rechazo solo tiene 112 bytes, mientras que el mensaje real, incluyendo el owner ID, llega a 1056 bytes en total
    • Como resultado, el kernel escribe 1056 bytes en un búfer de 112 bytes, sobrescribiendo memoria del kernel con datos controlados por el atacante
  • Al reportar esta vulnerabilidad, Claude Code incluso generó e incluyó automáticamente un diagrama de protocolo ASCII

• Por qué no se descubrió durante 23 años

  • El error se originó en código introducido en el kernel de Linux en marzo de 2003
    • El mensaje del commit de entonces indicaba que un búfer fijo de 112 bytes llamado NFSD4_REPLAY_ISIZE era suficiente para operaciones de NFSv4 como OPEN y CLOSE
    • Después, al añadirse la operación LOCK, no se tuvo en cuenta el límite de longitud del owner ID, lo que dio lugar a la vulnerabilidad
  • Este código proviene de cambios anteriores a la adopción de Git (2005), por lo que se basa en código tan antiguo que hoy ni siquiera es posible enlazarlo directamente

• Cientos de vulnerabilidades adicionales aún no reportadas

  • Carlini también encontró cientos de posibles vulnerabilidades adicionales del kernel de Linux, pero la mayoría todavía no ha sido reportada debido al cuello de botella del proceso de verificación humana
    • Mencionó: “Como no puedo enviar resultados no verificados a los mantenedores del kernel, hay cientos de fallos que aún no he podido confirmar”
  • Hasta ahora, se confirma que Carlini corrigió o reportó personalmente 5 vulnerabilidades
    • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
    • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
    • futex: Require sys_futex_requeue() to have identical flags
    • ksmbd: fix share_conf UAF in tree_conn disconnect
    • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

• Avances en la detección de vulnerabilidades basada en IA

  • Carlini encontró esta vulnerabilidad usando Claude Opus 4.6 (dos meses antes de su lanzamiento)
    • No pudo reproducir el mismo resultado con versiones anteriores como Opus 4.1 (hace 8 meses) y Sonnet 4.5 (hace 6 meses)
    • El modelo más reciente pudo detectar muchas más vulnerabilidades
  • Según él, “en los próximos meses, tanto investigadores como atacantes reconocerán el poder de estos modelos de IA, y llegará una ola de descubrimientos masivos de vulnerabilidades de seguridad”

• Presentación y otra información

  • Este contenido fue presentado en [un]prompted AI security conference 2026
  • El caso descubierto por Claude Code se considera un ejemplo de cómo la IA puede aumentar de forma drástica la productividad de la investigación real en seguridad

[m3op0w94]

Versión esperanzadora: se descubrió una vulnerabilidad en Linux
Versión desesperanzadora: se eliminó el bounding de curl

[GN⁺]

Comentarios de Hacker News

• No sorprende. Lo que no se menciona en el artículo es que Claude Code también encontró 1,000 bugs falsos positivos, y a los desarrolladores les tomó 3 meses filtrarlos

  • Ahora ya no funciona así. El LLM filtra por sí solo los bugs que no se pueden reproducir en una segunda pipeline. Verificar si una vulnerabilidad realmente se puede activar es mucho más fácil que encontrarla, así que al final quedan casi solo bugs reales con una precisión cercana al 100%. Todavía hay mucha gente que niega el avance de los LLM, pero es difícil negar su utilidad
  • Me da curiosidad la fuente. Nunca he visto algo así. En mi experiencia, la tasa de falsos positivos de detección de vulnerabilidades de Claude Opus 4.6 fue menor al 20%
  • Las herramientas de análisis estático/dinámico también siempre encuentran vulnerabilidades. La mayoría de los proyectos grandes ya tienen un backlog de issues arrojado por escáneres. El problema es identificar cuáles de esos realmente son peligrosos. Es interesante que Claude haya encontrado un bug antiguo, pero esto siempre pasa cuando aparece un escáner nuevo
  • El artículo no dice que haya muchos falsos positivos. Más bien menciona que “todavía hay demasiados bugs sin validar”
  • La lección no es que Claude Code no sirve, sino que en las manos correctas puede ser una herramienta poderosa

• Pegar mucho código nuevo de golpe y preguntarle a Claude “¿qué me faltó? ¿dónde hay bugs?” es un enfoque muy convincente para desarrolladores que apenas están entrando al mundo de la IA. En especial encuentra rápido bugs de threading o de sistemas distribuidos. A estas alturas seguramente ya están analizando en masa códigos de criptomonedas

  • A mí me gusta sesgar el prompt para que Claude asuma que “hay un bug”. Si le preguntas “Este código tiene un bug. ¿Puedes encontrarlo?” o le agregas “El bug no es obvio”, me ha funcionado mejor
  • Yo también uso CC/codex casi de esa manera
  • Lo uso preguntando algo como “Este código lo escribió Codex, ¿ves algo raro?”

• Más que un bug “oculto”, sería más correcto decir que “nadie lo revisó”. Era una estructura donde se escribían 1056 bytes en un buffer de 112 bytes. Es un problema que incluso un analizador estático puede detectar fácilmente, pero si le pides a un LLM “revisa todos los buffers de tamaño fijo”, también puede mezclar alucinaciones en los resultados. Aun así, es un buen punto de partida

  • La mayoría de las vulnerabilidades siguen ahí porque “nadie las revisó”. A medida que se acumula la complejidad del sistema, se vuelve difícil para las personas seguirle el ritmo. Si esto puede resolver ese problema, es una gran noticia. Los analizadores estáticos reportan todas las rutas posibles de copia de buffers, pero como a veces la entrada real está limitada, eso no encaja bien en el kernel de Linux
  • En realidad, que “nadie lo revisó” se debe a falta de personal. Había una cantidad limitada de personas y tiempo para encontrar vulnerabilidades en open source. Pero ahora, como los modelos se han vuelto lo bastante capaces, ese límite se está rompiendo. Siento que este año va a ser muy interesante
  • Dicen que un analizador estático podía encontrarlo fácilmente, pero en la práctica nadie pudo encontrarlo durante más de 20 años. Da risa que cada vez que un LLM hace algo genial, siempre sale la reacción de “eso no es para tanto”

• Curiosamente, 3 o 4 de los 5 bugs descubiertos probablemente habrían sido mitigados por los parches de linux-hardened. Por ejemplo, desactivar io_uring, crash del kernel ante UAF y prevención de explotación de heap overflow

• Da risa ese tipo de anuncio de “Estamos publicando un arma peligrosa, así que ayúdennos a hacer el mundo más seguro. Eso sí, paguen la suscripción”. Es como si un bioquímico liberara una bomba química y dijera “si quieren detener esto, paguen”. La industria del software de estos días es realmente irónica

  • Eso no tiene sentido. Comparar encontrar y reportar vulnerabilidades con dispersar armas bioquímicas es exageradísimo

• Repliqué el experimento en varios codebases de producción, y había muchos duplicados, falsos positivos y bugs no explotables. Aun así, también hubo bastantes vulnerabilidades críticas reales (crit)

• Me dio curiosidad el video que se reprodujo de fondo durante la sesión de preguntas y respuestas de la presentación. ¿Era una demo de exploit usando un bug de NFS a través de una red USB?

• Es trabajo relacionado de nuestro laboratorio de seguridad. Solo este año encontramos 23 vulnerabilidades con agentes de seguridad de IA

  • Reporte de Security Lab
  • Guía de ejecución de Taskflow

• Parece que las reservas de 0-days de las agencias de tres letras (servicios de inteligencia) van a reducirse drásticamente

• No esperen que de aquí en adelante salgan más reportes de vulnerabilidades; más bien hay que anticipar más intentos de ataque