Squidbleed: The 29-Year-Old Proxy Bug That Still Had One More Trick
A 29-year-old Squid proxy bug, named “Squidbleed” and tracked as CVE-2026-47729, can leak cleartext HTTP requests from other users sharing the same proxy. The flaw sits in Squid’s FTP directory-listing parser and can expose headers, credentials or session tokens if traffic is visible to the proxy. HTTPS traffic is generally unaffected unless Squid is decrypting it. No in-the-wild exploitation was reported at publication, but proof-of-concept code is public. Disabling FTP support or applying verified patches is recommended.
Some bugs age like fine wine. Others age like milk behind a radiator. Squidbleed is firmly in the second category.
Researchers have disclosed a vulnerability in the Squid web proxy that dates back to a 1997 FTP parsing change. The issue, now tracked as CVE-2026-47729, can allow one trusted proxy user to receive fragments of another user’s cleartext HTTP request.
That could include session tokens, credentials or sensitive headers — which is not ideal, unless your business model is “accidental data leakage”.
The good news is that this is not a random internet attack. An attacker must already be allowed to use the same Squid proxy, and the leak only affects traffic Squid can actually read. Normal HTTPS traffic passing through an opaque CONNECT tunnel should not be exposed. However, plain HTTP and TLS-inspecting proxy setups are more at risk.
The bug lives in Squid’s FTP directory-listing parser. By controlling an FTP server response, an attacker can trigger a heap over-read and receive memory content that may contain another user’s recent request data.
The practical fix? Patch Squid, verify the actual fix is present in your distribution build, and strongly consider disabling FTP support entirely. Most organisations have not needed proxy FTP access since approximately the era of dial-up modems and questionable office carpets