Qué filtra realmente Squidbleed
Squidbleed, registrado como CVE-2026-47729, es una sobrelectura de búfer de montículo en el analizador de listados de directorios FTP de Squid, uno de los proxies 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. El 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 dirige 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 todavía circulan cada día por los proxies 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 las configuraciones por defecto, el puerto 21 figura en la lista por defecto Safe_ports, durante veintinueve años y 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, algo que Chromium abandonó hace años y de lo 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, los mantenedores fusionaron la corrección en cuestión de días y el aviso público llegó el 23 de junio. Pero el descubrimiento original vino de un agente de IA encargado de recorrer la máquina de estados de FTP, y 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 suspender un examen muy público, y la herramienta que la ha roto ya es barata y está al alcance de cualquiera.
Qué debería hacer un operador esta semana
El paso concreto es pequeño: inventaríe cada instancia de Squid que tenga en marcha, actualícela a una versión corregida y, si no necesita a propósito el proxy FTP, desactívelo y quite el puerto 21 de Safe_ports. Priorice cualquier proxy que termine TLS o transporte HTTP en claro para varios usuarios, porque ahí es donde las credenciales de unos compañeros pueden filtrarse a otros. En el Reino Unido el National Cyber Security Centre trata la exposición de credenciales en infraestructura compartida como una clase de incidente notificable, y en toda la UE el régimen NIS2 sitúa la responsabilidad por un fallo conocido y sin parchear en la alta dirección designada por su nombre, y no solo en el equipo de seguridad.
El movimiento de fondo es dejar de tratar la edad de una dependencia como prueba de su seguridad. Un fallo de una sola línea se escondió veintinueve años en un software en el que miles de organizaciones confiaban precisamente por maduro, y un revisor de IA lo encontró en una sola pasada. Cuente con que afloren más fallos latentes como este en sus componentes más antiguos y de mayor confianza, y presupueste un flujo constante de parches pequeños y poco vistosos en lugar de uno solo espectacular.
Leer a continuación: Auditoría de IA no vio el fallo Linux que da root | Este malware borra primero tus copias de seguridad
