Introducción
Treinta años. Ese es el tiempo que tardó en descubrirse una línea de código defectuosa introducida en Squid en enero de 1997. La vulnerabilidad bautizada Squidbleed —CVE-2026-47729— afecta a todas las versiones de este servidor proxy-caché de código abierto en su configuración por defecto. Permite a un atacante provocar la fuga de fragmentos de memoria heap que contienen solicitudes HTTP en texto plano, encabezados de autorización, cookies de sesión o claves API.
Squid: un nodo crítico que a menudo pasa desapercibido
Squid está presente en innumerables infraestructuras de red, tanto en las que fue desplegado de forma deliberada como en aquellas donde llegó casi sin ser notado. Proveedores de internet, instituciones educativas, grandes corporaciones y organismos gubernamentales lo utilizan para filtrar el tráfico web, acelerar los accesos mediante caché o controlar las salidas de red. Este papel de nodo central hace que la vulnerabilidad sea especialmente crítica: una fuga de memoria a ese nivel no compromete a un único usuario, sino potencialmente a la totalidad de las solicitudes que transitan por la red corporativa.
El hecho de que el código vulnerable date de enero de 1997 amplifica la preocupación. Tres décadas de auditorías, revisiones de código y actualizaciones mayores lo dejaron intacto, sobreviviendo a generaciones de ingenieros y de configuraciones sin disparar ninguna alerta.
La mecánica de una fuga silenciosa
La vulnerabilidad reside en el analizador de listas FTP de Squid, un componente heredado diseñado originalmente para gestionar servidores NetWare de aquella época. El problema radica en una sutileza del estándar C: la función strchr, cuando busca un carácter nulo, devuelve un valor no nulo conforme al estándar C11 —un comportamiento contraintuitivo que esquivó a los auditores humanos durante treinta años.
En la práctica, si un servidor FTP malicioso no proporciona un nombre de archivo en su respuesta, un puntero interno de Squid sobrepasa el terminador nulo. El bucle de lectura no se detiene y recorre la memoria heap, devolviendo al cliente fragmentos brutos que pueden contener solicitudes de otros usuarios, credenciales o tokens de autenticación. Los búferes HTTP de 4 KB que utiliza Squid nunca se reinicializan entre solicitudes durante el reciclaje de memoria: una ventana discreta pero explotable para exfiltrar datos sin generar ninguna alerta.
Un exploit accesible en la configuración por defecto
Lo que agrava la situación es que no se requiere ninguna configuración especial. El soporte FTP está activado por defecto en Squid, y el puerto 21 está incluido en la lista de puertos autorizados (Safe_ports ACL). Un atacante solo necesita controlar un servidor FTP accesible desde el proxy objetivo —una condición alcanzable en muchos entornos corporativos donde las reglas de filtrado de salida siguen siendo permisivas.
No obstante, el alcance real está condicionado: únicamente el tráfico HTTP no cifrado queda expuesto. El tráfico HTTPS transita a través de túneles CONNECT opacos que Squid no descifra de forma nativa. Excepción relevante: los despliegues que practican la inspección TLS, donde la superficie de ataque se vuelve significativamente mayor.
Aplicar el parche sin demora
El parche está disponible en Squid 7.6, publicado el 8 de junio de 2026. La corrección se reduce a una sola verificación: comprobar la presencia del terminador nulo antes de invocar strchr. Para los equipos que no puedan migrar de inmediato, deshabilitar el soporte FTP en la configuración de Squid elimina por completo la superficie de ataque. Los navegadores modernos abandonaron el protocolo FTP hace ya varios años; en la mayoría de los entornos corporativos actuales, este protocolo ya no tiene razón de estar habilitado en el proxy.
Este incidente pone de manifiesto un punto ciego recurrente en la gestión de la seguridad de red: los componentes considerados estables por el simple hecho de funcionar son precisamente aquellos donde las vulnerabilidades persisten durante más tiempo. Los proxies, los reenviadores DNS y los equipos de filtrado merecen los mismos ciclos de revisión que los sistemas directamente expuestos a internet.