Squidbleed: A 1997 FTP Parsing Bug Is Still Leaking Cleartext HTTP in Squid Proxies
A heap over-read disclosed by Calif.io exposes other users' requests, credentials and session tokens included, to anyone permitted to send traffic through the same proxy.
Key points
- A heap over-read in Squid lets an authenticated proxy user read other users' cleartext HTTP requests.
- The root cause is a 1997 FTP-parsing change that has survived nearly three decades of refactoring.
- Researchers at Calif.io disclosed the flaw in June and named it Squidbleed.
- The vulnerable code path runs even when FTP gatewaying is disabled, so turning the feature off is not a complete fix.
- Operators should patch, rotate cleartext credentials, and check logs for anomalously large response sizes.
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. Authorization headers, session tokens and cookies are all fair game.
Researchers at Calif.io disclosed the flaw in June and named it Squidbleed. Its 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
When Squid mishandles certain crafted requests, the response can include adjacent heap 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.
Basic auth strings. Bearer tokens. Internal API keys. Anything sitting in cleartext between the client and an upstream TLS termination point is exposed.
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 wider 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 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 alone doesn't close the hole.
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 credentials from end-user traffic fall inside GDPR and UK GDPR personal-data definitions. Notification obligations kick in once a controller becomes aware of a likely risk to data subjects, not when forensic work wraps up. US operators with California traffic should weigh CCPA notification thresholds. Healthcare and financial sector deployments carry their usual sector-specific overlays.
Should you worry?
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 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: treat any plaintext HTTP credential sent through it during the exposure window as compromised and rotate it. Force HTTPS where you control the endpoint and invalidate session tokens issued over plain HTTP.
What matters most here is the attacker bar: this isn't a remote zero-click. It requires access to the proxy, which means the realistic threat is an insider or a compromised internal host, not a drive-by. That's worth keeping in proportion, even if the credential exposure is real.
