Squidbleed un fallo de heap en Squid que expone credenciales en texto claro en proxies compartidos CVE-2026-47729

Un fallo de sobrelectura de heap en el proxy Squid —apodado Squidbleed (CVE-2026-47729)— puede filtrar a un atacante información en texto claro de las peticiones HTTP de otros usuarios del mismo proxy, incluyendo cabeceras Authorization o tokens de sesión. A diferencia de vulnerabilidades que permiten el acceso desde cualquier host en Internet, aquí el atacante ya debe estar autorizado a usar el proxy: es la clásica amenaza de un cliente de confianza malicioso en redes compartidas como universidades, oficinas o Wi‑Fi públicas.

El origen del bug es una sutileza en el parseo de listados FTP heredado de los años 90: un bucle que salta espacios depende de la función strchr sin comprobar si ha llegado al carácter NUL final de la cadena. Si un servidor FTP controlado por el atacante envía una línea truncada que acaba justo tras la marca temporal y no incluye nombre de fichero, el código camina fuera del búfer y copia bytes adyacentes liberados, que en la práctica contienen partes de otras solicitudes HTTP que Squid dejó en memoria. Como Squid no limpia los búferes antes de reutilizarlos, el resultado puede ser la exposición de credenciales en claro.

Es importante entender el alcance: solo están en riesgo las peticiones HTTP en texto claro (o tráfico que Squid descifre intencionalmente). El túnel CONNECT usado por HTTPS estándar mantiene la sesión opaca para Squid, por lo que el contenido cifrado no se ve afectado. Sin embargo, muchas redes todavía permiten FTP y Puerto 21 suele estar activo por defecto en Squid, lo que facilita el vector de explotación si un atacante interno ofrece un servidor FTP malformado.

La corrección upstream consiste en añadir una comprobación explícita del terminador NUL antes de llamar a strchr en FtpGateway.cc; el parche llegó a ramas de desarrollo y a la serie v7 en primavera, aunque los hilos públicos de mantenimiento mostraron cierta inconsistencia sobre qué versiones contienen realmente el arreglo. Por eso no basta con actualizar por versión: hay que verificar el parche aplicado en su binario o en el paquete de la distribución.

Acciones recomendadas de urgencia para administradores de red y equipos de seguridad: aplique parches publicados por su proveedor y confirme que la corrección afecta a FtpGateway.cc (o al commit equivalente si su distribución backportea cambios). Si no puede parchear de inmediato, desactive el manejo de FTP en Squid; es la mitigación más limpia y la que recomiendan los investigadores, dado que muchos entornos ya no usan FTP activamente. Además, considere bloquear el tráfico saliente hacia el puerto 21 en la puerta de enlace de la red para reducir el riesgo.

Tras parchear o desactivar FTP, verifique su entorno: rote credenciales y tokens expuestos si sospecha compromiso, revise registros del proxy en busca de conexiones FTP internas inusuales y busque logs que indiquen respuestas cortas de servidores FTP o tráfico hacia servidores FTP controlados por hosts internos. Si su despliegue usa interceptación TLS (terminación TLS en Squid), tenga en cuenta que ese tráfico queda a riesgo y debe controlarse con prioridad.

Para equipos que dependen de paquetes de terceros, compruebe el estado en su distribución: algunos mantenedores publican parches backportados y notas en los trackers de seguridad. Puede consultar el registro público del CVE en fuentes oficiales y la página del proyecto Squid para seguimiento de lanzamientos y advisories; ejemplos útiles son la ficha NVD del CVE y el sitio del proyecto Squid: https://nvd.nist.gov/vuln/detail/CVE-2026-47729 y https://www.squid-cache.org/. Para distribuciones Debian/Ubuntu, el tracker de seguridad suele mostrar el estado de los paquetes y backports: https://security-tracker.debian.org/tracker/CVE-2026-47729.

Esta incidencia también ilustra dos tendencias útiles para defensores: primero, las cadenas de código histórico y parsers escritos para protocolos antiguos siguen siendo fuentes prolíficas de fallos de memoria; segundo, herramientas de análisis asistidas por modelos y agentes automatizados están ayudando a detectar patrones sutiles —en este caso, investigadores citan que un modelo de IA ayudó a identificar la peculiaridad de strchr—, lo que convierte a estas herramientas en complementos valiosos para auditorías de seguridad en código legado.

En resumen, el riesgo es real pero acotado: requiere acceso al proxy y la capacidad de dirigir al proxy hacia un servidor FTP malformado. Aun así, la recomendación práctica es clara y de bajo coste: deshabilite FTP en Squid si no lo necesita y confirme que su instalación incorpora la comprobación del terminador NUL en FtpGateway.cc. Donde haya duda sobre la corrección, trate el incidente como si hubiese habido exposición y rote credenciales críticas.