Claude encontró un bug de 29 años que nadie había visto — y ahora los gobiernos quieren controlar la IA que puede hacer esto
El 18 de enero de 1997, un desarrollador de Squid Proxy cometió un commit. Era una línea de código diseñada para manejar un servidor FTP de NetWare que ponía cuatro espacios extra entre el timestamp y el nombre de archivo en sus listados de directorio.
NetWare fue un sistema operativo de red de Novell que prácticamente nadie usa desde hace dos décadas. FTP es un protocolo que los navegadores modernos dejaron de soportar hace años. Y el bug que ese commit introdujo — una línea de C que no verifica el null terminator antes de llamar a strchr — sobrevivió 29 años de releases, auditorías de seguridad, rewrites del codebase, y revisiones de código por ingenieros de todo el mundo.
En junio de 2026, Claude Mythos Preview lo encontró en minutos.
El bug requería conectar tres hechos que ninguna pieza de código establece de forma explícita: un shim de compatibilidad de 1997 para un sistema operativo de red en desuso, la definición específica y no obvia del estándar C sobre lo que strchr hace con un byte nulo, y el comportamiento de reutilización interna de un allocator personalizado que no está documentado en ningún lugar cerca del código de parsing que depende de él. Cualquiera de esos hechos en aislamiento parece completamente poco notable. Es la conjunción lo que es peligrosa.
Y la conjunción es exactamente lo que una IA con acceso a décadas de contexto simultáneo puede ver — y un humano haciendo una revisión de código normal tiende a perder.
Qué es Squidbleed y por qué importa
Squidbleed, rastreado como CVE-2026-47729, es una vulnerabilidad de heap buffer overread en el parser de listados de directorio FTP de Squid Proxy. Cuando es explotada, causa que Squid lea memoria más allá de un heap-allocated buffer y retorne esa data obsoleta — potencialmente incluyendo la solicitud HTTP de otro usuario, authorization headers, o API keys — como parte de una respuesta de listado de directorio FTP.
El nombre no es accidental. Los investigadores la nombraron Squidbleed por su similitud con Heartbleed — la vulnerabilidad crítica de OpenSSL de 2014 que sacudió la infraestructura de internet. En ambos casos, el fallo lleva a leer datos más allá de los límites del buffer y a filtrar el contenido de la memoria.
Para entender la magnitud real, hay que entender qué es Squid y dónde vive. Squid es un proxy web ampliamente utilizado (incluyendo en soluciones embebidas), frecuentemente desplegado para cachear, filtrar o inspeccionar tráfico en entornos compartidos como escuelas, empresas y redes de Wi-Fi público.
Es exactamente en esos entornos multiusuario donde Squidbleed se vuelve peligroso: cuando un atacante tiene acceso al mismo proxy Squid y puede hacer que el proxy se conecte a un servidor FTP controlado por el atacante, puede recuperar datos de solicitudes HTTP de otras sesiones — incluyendo credenciales, cookies, tokens de sesión, headers de autorización y API keys.
La mecánica del bug: una línea de C, 29 años de silencio
Para los que quieren entender el bug en términos concretos, la explicación técnica es elegante en su simplicidad — y en su horror.
El fallo se rastrea hasta un commit fechado el 18 de enero de 1997, que añadió lógica para manejar servidores FTP de NetWare que colocaban cuatro espacios entre el timestamp de modificación de un archivo y su nombre. El fix introdujo un loop while(strchr(w_space, *copyFrom)) diseñado para saltar el espacio extra en blanco. Sin embargo, hay un error crítico: strchr en C trata al null terminator (\0) como parte del string de búsqueda, según el C11 §7.24.5.2.
En lenguaje llano: el código asume que cuando llega al final del string, el loop para. Pero strchr no para — sigue buscando más allá del final del string porque el estándar C dice que el terminador nulo es parte del string. El puntero se mueve más allá de la memoria reservada, y lo que encuentra es memoria reciclada del sistema — que puede contener los datos del request HTTP anterior de otro usuario.
Squid recicla sus buffers de 4KB sin zerear. Un buffer que acaba de contener el request HTTP de una víctima todavía contiene la mayor parte de ese contenido: la corta línea FTP solo sobreescribe los primeros bytes, y el overread fuera de los límites retorna el resto. Un atacante puede así recuperar el Authorization header de un usuario que usa el mismo proxy vulnerable.
El fix, cuando llegó, fue de una sola línea:
// ANTES (vulnerable — 29 años):
while (strchr(w_space, *copyFrom))
// DESPUÉS (corregido):
while (*copyFrom && strchr(w_space, *copyFrom))
Un null check. Una condición adicional. Eso es todo lo que separó a la infraestructura de internet de esta vulnerabilidad durante casi tres décadas.
Los peligros del acceso directo a memoria en C son bien conocidos, pero las sutilezas de funciones de la librería estándar como strchr son más fáciles de ignorar. Pocos developers adivinarían que buscar \0 tiene éxito, lo que puede explicar cómo un bug de una línea sobrevivió cerca de 30 años de revisión de código.
Cómo Claude Mythos lo encontró — y por qué los humanos no pudieron
Cuando pedí a Claude Mythos Preview que "spawneara más agentes para investigar mejor el comportamiento completo del state machine FTP", uno de los primeros bugs que encontró fue en el parser de listados de directorio FTP de Squid. El bug predecía todo el historial de commits disponible en el repositorio de GitHub de Squid.
Esa frase — "spawneara más agentes" — es la clave de lo que hizo diferente a esta investigación. Lam Jun Rong de Calif.io no le pidió a Claude Mythos que encontrara bugs. Le pidió que investigara el FTP state machine. El agente decidió por sí mismo lanzar subagentes para cubrir distintas partes del codebase en paralelo. Uno de esos subagentes llegó al parser de listados FTP y encontró algo que no cuadraba.
Claude Mythos Preview, habiendo sido entrenado en la referencia completa del estándar C, trata esta peculiaridad como simplemente otro hecho. Cuando se le apuntó al código correcto, identificó el bug casi de inmediato.
La razón por la que los humanos no lo encontraron no es incompetencia. Conjunciones como esa — que requieren conectar hechos de contextos completamente distintos: un protocolo en desuso, un comportamiento no obvio del estándar C, y la mecánica interna de un allocator personalizado — son exactamente lo que es fácil perder durante un pase de revisión normal y comparativamente manejable para un modelo que puede mantener los tres pedazos de contexto al mismo tiempo y está dispuesto a "spawnear más agentes" para seguir el FTP state machine hasta que algo no cuadra.
No es que la IA sea más inteligente que los auditores humanos. Es que puede mantener simultáneamente más contexto del que cualquier humano puede tener en mente durante una revisión de código, y puede lanzar docenas de agentes en paralelo para explorar distintas partes del codebase al mismo tiempo.
El patrón: no es solo Squidbleed
Squidbleed no es una anomalía. Es la última entrada en una serie que se está acelerando.
Dos semanas antes de Squidbleed, la misma firma Calif.io publicó HTTP/2 Bomb — una cadena de denegación de servicio contra nginx, Apache, IIS, Envoy y Pingora, descubierta por el agente Codex de OpenAI. Calif también colaboró con OpenAI en su iniciativa Patch the Planet, anunciada el mismo día.
El patrón que emerge en 2026 es claro: firmas de seguridad especializadas están usando agentes de IA frontier para hacer bug hunting a escala industrial en infraestructura de open source. Y los resultados están llegando con una velocidad que los procesos tradicionales de auditoría no pueden igualar.
Jeff Brown, Faculty de IANS, lo formuló con precisión: "El dispositivo que filtró los datos era un proxy — esa cosa que desplegaste para inspeccionar y proteger el tráfico. La infraestructura aburrida y de confianza es donde va a aterrizar la próxima ola de divulgaciones de bugs antiguos que acabamos de descubrir."
Y George Gerchow añadió lo más inquietante de todo: "No está detrás de Mythos. Los investigadores han demostrado que modelos pequeños, baratos y open-weight pueden encontrar las mismas clases de bugs. El descubrimiento es ahora una mercancía."
Eso es lo que más debería preocupar a los equipos de seguridad: si los defensores pueden usar IA para encontrar estas vulnerabilidades, los atacantes también pueden hacerlo. Y no necesitan acceso a Mythos.
La paradoja que nadie estaba esperando
Aquí está la ironía que convierte esta historia en algo más que un reporte técnico de seguridad.
El gobierno de EE.UU. ordenó a Anthropic apagar Claude Fable 5 y Mythos 5 el 12 de junio de 2026, tres días después de su lanzamiento público. El motivo oficial: reportes de una técnica para bypasear los safety guardrails del modelo, que potencialmente lo convertía en una herramienta de ciberataque irrestricta.
El mismo modelo que encontró Squidbleed — una vulnerabilidad de 29 años que ningún auditor humano había detectado, en infraestructura usada por millones de sistemas alrededor del mundo — fue apagado por el gobierno porque ese mismo poder de análisis podría usarse para atacar en lugar de defender.
Como lo formuló el investigador de ciberseguridad Peter Girnus: "Si describes tu producto como una munición en cada comunicado de prensa, eventualmente un gobierno te toma la palabra. Escribieron el precedente legal ellos mismos y lo llamaron una marca."
La tensión no tiene resolución fácil. Un modelo con la capacidad de leer décadas de código C en paralelo, conectar contextos de tres fuentes distintas, y encontrar el bug que todos perdieron — es exactamente el mismo modelo que, con las restricciones incorrectas, podría generar exploits antes que los defensores puedan parchear.
Agentic coding está transformando la seguridad en dos direcciones al mismo tiempo. A medida que los modelos se vuelven más poderosos y mejor alineados, construir seguridad en los productos se vuelve más fácil. Ahora cualquier engineer puede usar IA para realizar revisiones de seguridad, hardening y monitoreo que antes requerían expertise especializado. Pero las mismas capacidades que ayudan a los defensores también son capaces de ayudar a los atacantes.
Lo que esto significa para tu stack hoy
Si tienes Squid Proxy en producción, la respuesta inmediata es concreta.
Primero, verifica tu versión y el parche. Hay confusión sobre qué versión exacta incluye el fix para CVE-2026-47729. Inicialmente se reportó Squid 7.6, pero el maintainer de Squid, Amos Jeffries, publicó una corrección en la mailing list oss-sec clarificando que el fix real para CVE-2026-47729 está programado para 7.7. La versión 7.6 cubre CVE-2026-50012, una vulnerabilidad separada. Si parcheaste a 7.6 asumiendo que también cerrabas Squidbleed, no lo hiciste.
Segundo, deshabilita FTP si no lo usas. La configuración es simple: acl FTP proto FTP seguido de http_access deny FTP. Chrome y todos los navegadores basados en Chromium dejaron de soportar FTP hace años — la mayoría de las redes ven prácticamente cero tráfico FTP legítimo. Deshabilitar FTP remueve esta superficie de ataque sin ningún costo operativo.
Tercero, verifica el parche en el código fuente, no solo el número de versión. Las distribuciones hacen sus propios builds. Debian, por ejemplo, aún distribuye Squid 5.7. Más allá de verificar solo el número de versión, confirma que el parche está presente en el archivo FtpGateway.cc.
Cuarto, revisa si tienes TLS inspection habilitado. El impacto es situacional: la mayoría del tráfico es HTTPS, que el proxy transmite como un túnel CONNECT opaco, por lo que solo el HTTP en texto claro y los setups que terminan TLS están expuestos. Si tu Squid descifra e inspecciona tráfico TLS, el riesgo se amplifica.
La lección más grande: tu infraestructura aburrida es el nuevo campo de batalla
Squidbleed no es solo un bug en Squid. Es una señal sobre dónde se van a encontrar los próximos bugs, y quién los va a encontrar primero.
"Cuando una IA puede leer décadas de código en una tarde, la parte de tu stack que parece más segura — la vieja, aburrida, la que nadie ha tocado en años — se convierte en el campo de caza más rico."
Los equipos de seguridad han operado durante décadas bajo una suposición implícita: el código que lleva mucho tiempo en producción sin incidentes conocidos es probablemente seguro. Ha sido auditado. Ha sido probado. Si hubiera bugs críticos, alguien los habría encontrado.
Squidbleed demuestra que esa suposición ya no aplica. Un modelo que puede leer el C standard completo en contexto, lanzar subagentes en paralelo para cubrir distintas partes del codebase, y conectar hechos de fuentes que ningún revisor humano tendría simultáneamente en mente, puede encontrar en una tarde lo que nadie encontró en 29 años.
La recomendación práctica que emerge de la comunidad de seguridad después de Squidbleed tiene tres partes:
Inventario real y SBOM. La recompensa llegará cuando caiga el próximo Squidbleed: poder responder "¿dónde corremos esto, y qué versión?" en minutos, antes de que los scanners siquiera generen una firma.
AI-assisted code review en componentes legacy. Si tienes código C o C++ que lleva más de cinco años sin auditoría formal, los mismos workflows que encontraron Squidbleed están disponibles — no necesitas acceso a Mythos, como señaló Gerchow. Modelos open-weight baratos ya pueden encontrar las mismas clases de bugs.
Asumir que el atacante ya tiene la herramienta. El PoC de Squidbleed está disponible públicamente en GitHub desde el día de la divulgación. Cualquier threat actor con un agente de IA y motivación para encontrar bugs en proxies compartidos tiene el mismo punto de partida que los defensores. La ventana de tiempo entre divulgación y explotación activa se comprime cuando los atacantes también tienen agentes.
El bug que cambió cómo pensamos en la auditoría
El bug predecía todo el historial de commits disponible en el repositorio de GitHub de Squid. Sobrevivió tres décadas de releases, revisiones de código y auditorías de seguridad independientes.
Y lo encontró un modelo de IA en minutos, siguiendo el FTP state machine hasta que algo no cuadraba.
Eso no significa que los auditores humanos sean redundantes. Significa que el tipo de análisis que Mythos hizo — mantener simultáneamente el contexto del estándar C, la mecánica interna del allocator, y el comportamiento del FTP state machine, todo al mismo tiempo — no es el tipo de análisis que una revisión de código humana puede hacer de manera consistente.
La implicación para cualquier equipo que mantiene software: los bugs más difíciles de encontrar no son los más complejos. Son los que requieren conectar hechos de tres contextos distintos que ningún revisor individual tiene en mente simultáneamente. Y eso es exactamente lo que los agentes de IA pueden hacer bien.
El mismo poder que preocupa a los gobiernos es el mismo poder que puede encontrar el próximo Squidbleed antes de que lo encuentre alguien con otras intenciones.
Esa es la paradoja con la que vive la industria de seguridad en julio de 2026. Y todavía no tiene una respuesta clara.
¿Tienes Squid Proxy en tu stack? ¿Ya verificaste si el parche está en FtpGateway.cc? Cuéntalo en los comentarios. Y si quieres una guía de cómo usar Claude Code para hacer tu propio audit de dependencias legacy, déjalo abajo.
Comentarios