Qué filtra realmente Squidbleed
Squidbleed, registrado como CVE-2026-47729, es una sobrelectura de búfer en el analizador de listados de directorios FTP de Squid, uno de los proxys web más desplegados de internet. Cuando Squid representa un listado FTP al que le falta el nombre de archivo, un bucle que salta espacios en blanco avanza un paso de más y lee memoria más allá del búfer previsto. Como Squid reutiliza la memoria liberada entre peticiones, esos bytes perdidos son a menudo fragmentos del tráfico de otros usuarios: peticiones HTTP en claro con contraseñas, cookies, tokens de sesión y claves de API.
La exposición es más estrecha que la de Heartbleed, pero real. Un atacante tiene que ser un usuario autorizado de un proxy compartido y controlar un servidor FTP que el proxy pueda alcanzar por el puerto 21, lo que apunta el riesgo hacia los internos y hacia cualquier montaje en el que el proxy termine TLS. El tráfico HTTPS reenviado como túnel opaco sigue sellado, así que lo que está en juego son los flujos HTTP en claro y los terminados en TLS que aún circulan cada día por los proxys corporativos.
Una línea, veintinueve años y la IA que lo encontró
La causa raíz es casi trivial. El código llamaba a strchr sobre una cadena que podía estar vacía, y el estándar de C dice que strchr trata el byte nulo final como parte de la cadena, así que la comprobación que debía detenerse al final de la entrada siguió en silencio más allá. El patrón culpable se remonta a un commit de Squid de enero de 1997, lo que significa que el fallo se distribuyó en configuraciones por defecto, el puerto 21 está en la lista por defecto Safe_ports, durante veintinueve años a lo largo de incontables versiones, reescrituras y revisiones de seguridad. La corrección es una sola condición añadida, una comprobación de nulo antes de strchr, o apagar el FTP por completo, que Chromium abandonó hace años y del que casi ninguna red depende ya.
El detalle que debería retener la atención de un operador es quién lo encontró. Dos investigadores lo comunicaron de forma independiente, Pavel Kohout de Aisle Research en marzo de 2026 y Lam Jun Rong de Calif.io en abril, y los mantenedores fusionaron la corrección en días, con el aviso público el 23 de junio. Pero el descubrimiento original vino de un agente de IA encargado de recorrer la máquina de estados de FTP, no de otra auditoría humana. La cómoda suposición de que el código viejo y muy revisado es seguro por su edad acaba de fallar un examen muy público, y la herramienta que la rompió ahora es barata y está muy disponible.
Qué debería hacer un operador esta semana
El paso concreto es pequeño: inventaría cada instancia de Squid que ejecutas, parchéala a una versión corregida y, si no necesitas a propósito el proxy FTP, desactívalo y quita el puerto 21 de Safe_ports. Prioriza cualquier proxy que termine TLS o transporte HTTP en claro para varios usuarios, porque ahí es donde las credenciales de los compañeros pueden filtrarse entre sí. En España el INCIBE trata la exposición de credenciales en infraestructura compartida como un incidente notificable, y en toda la UE el régimen NIS2 pone la responsabilidad de un fallo conocido y sin parchear en la dirección designada, no solo en el equipo de seguridad.
El movimiento mayor es dejar de tratar la edad de una dependencia como prueba de su seguridad. Un fallo de una línea se escondió veintinueve años en software en el que miles de organizaciones confiaban precisamente por ser maduro, y un revisor de IA lo encontró en una sola pasada. Espera que más de estos fallos latentes afloren en tus componentes más viejos y de mayor confianza, y presupuesta un flujo constante de parches pequeños y poco vistosos en lugar de uno solo dramático.
Leer a continuación: Dos fallos de Cursor con 9.8 entregan la máquina del desarrollador a los atacantes | Una sola brecha de proveedor causó la mitad de las víctimas de ransomware en Europa
