Introduction
Thirty years. That's how long it took for a single flawed line of code — introduced into Squid in January 1997 — to finally be caught. The vulnerability, dubbed Squidbleed (CVE-2026-47729), affects every version of this open-source proxy-cache server in its default configuration. It allows an attacker to leak raw heap memory fragments containing cleartext HTTP requests, authorization headers, session cookies, and API keys.
Squid: A Critical Node That's Easy to Forget
Squid is deeply embedded in network infrastructures — sometimes by deliberate choice, sometimes by accumulated inertia. ISPs, schools, enterprises, and government organizations rely on it to filter web traffic, speed up access through caching, and control outbound network flows. That central role is precisely what makes this vulnerability so severe: a memory leak at this layer doesn't affect a single user — it potentially exposes every request transiting a network.
The fact that the vulnerable code dates back to January 1997 only deepens the concern. Three decades of audits, code reviews, and major version upgrades left it untouched, passing through generations of engineers and configuration changes without ever triggering an alert.
The Mechanics of a Silent Leak
The vulnerability lives in Squid's FTP list parser — a legacy component originally built to handle NetWare servers of the era. The root cause is a subtle quirk of the C standard: the strchr function, when searching for a null character, returns a non-null value per the C11 specification — a counterintuitive behavior that slipped past human auditors for thirty years.
In practice, if a malicious FTP server returns a response with no filename, an internal Squid pointer advances past the null terminator. The read loop no longer stops — it walks through heap memory and sends raw fragments back to the client. Those fragments can contain other users' requests, credentials, or authentication tokens. The 4 KB HTTP buffers Squid uses are never zeroed between requests during memory recycling: a quiet but exploitable window for data exfiltration, with no alerts fired.
An Exploit That Works Out of the Box
What makes this worse: no non-standard configuration is required. FTP support is enabled by default in Squid, and port 21 is included in the allowed ports list (Safe_ports ACL). An attacker only needs to control an FTP server reachable from the target proxy — a realistic condition in many enterprise environments where outbound filtering rules remain permissive.
The actual scope is bounded, however: only unencrypted HTTP traffic is exposed. HTTPS traffic flows through opaque CONNECT tunnels that Squid does not natively decrypt. The notable exception is deployments performing TLS inspection, where the attack surface becomes significantly larger.
Patch Now — Don't Wait
The fix is available in Squid 7.6, released June 8, 2026. It amounts to a single check: verifying the presence of the null terminator before calling strchr. For teams that cannot migrate immediately, disabling FTP support in Squid's configuration eliminates the attack surface entirely. Modern browsers dropped FTP support years ago; in most enterprise environments today, there is no reason for the protocol to remain enabled on the proxy.
This incident highlights a recurring blind spot in network security management: components deemed stable because they work are precisely where vulnerabilities tend to persist the longest. Proxies, DNS relays, and filtering appliances deserve the same review cycles as systems directly exposed to the internet.