Squidbleed: A 1997 FTP Parsing Bug Is Still Leaking Cleartext HTTP in Squid Proxies

A heap over-read in the Squid web proxy is handing other users' cleartext HTTP requests to anyone already allowed to push traffic through the same instance. That includes whatever Authorization headers, cookies and session tokens those requests happen to carry.

Researchers at Calif.io disclosed the flaw in June and named it Squidbleed. The root cause is older than most production proxies: a 1997 change to Squid's FTP parsing code that has quietly survived nearly three decades of refactoring.

It is still live in the default configuration.

What's actually leaking

The bug is a classic out-of-bounds read on the heap. When Squid mishandles certain crafted requests, the response can include adjacent memory — and that memory frequently contains in-flight HTTP requests from other clients sharing the proxy. Think shared corporate egress, multi-tenant filtering appliances, ISP-side caching layers, CDN backends.

Anything sitting in cleartext between the client and an upstream TLS termination point is fair game. Basic auth strings. Bearer tokens. Cookies. Internal API keys.

The attacker prerequisite is low. They need permission to send requests through the proxy. In a shared corporate deployment, that's every employee. In a misconfigured public-facing proxy, it's the internet.

Scope and disclosure

Squid ships with most major Linux distributions and underpins a long list of commercial filtering products. Operators running default configs should assume exposure until they patch.

Calif.io's writeup attributes the underlying defect to a parsing routine added in 1997 to handle FTP-over-HTTP gateway requests. The vulnerable code path executes even when FTP gatewaying is not in use, which is why disabling the feature is not a complete mitigation on its own.

Check the Squid project advisories for the patched release and CVE assignment matching your distribution's package.

Regulatory exposure

For operators in the EU and UK, leaked session tokens and credentials from end-user traffic land squarely inside GDPR and UK GDPR personal-data definitions. The ICO's 72-hour notification clock starts when the controller becomes aware of a likely risk to data subjects, not when forensic work concludes. US operators with California traffic should weigh CCPA notification thresholds. Healthcare and financial sector deployments carry the usual sector-specific overlays.

What affected users and operators should do

If you run Squid: upgrade to the patched release, audit access controls on who can send requests through the proxy, and review logs for anomalously large response sizes or unusual error patterns over the past several months. Rotate any credentials that transited the proxy in cleartext during the exposure window.

If you are a downstream user of a corporate or ISP proxy: assume any plaintext HTTP credential you sent through it during the exposure window is compromised, and rotate accordingly. Force HTTPS where you control the endpoint. Session tokens issued over plain HTTP should be invalidated.