A heap over-read in the Squid web proxy can leak another user's cleartext HTTP request, including any credentials or session tokens it carries, to anyone already allowed to send traffic through the same proxy.
The bug traces to a 1997 FTP-parsing change and is still live in Squid's default configuration. Researchers at Calif.io disclosed it in June and named it Squidbleed (CVE-2026-47729), after Heartbleed, which leaked memory the same way.
Squid describes this as an attack by a trusted client: someone already permitted to use the proxy, not any random host on the internet. That matches Squid's usual home, shared networks like schools, offices, and public Wi-Fi. In those setups, the attacker is just another user of the same proxy.
The leak also only reaches traffic that Squid can read. Normal HTTPS rides an opaque CONNECT tunnel, so Squid never sees inside it; the exposed traffic is cleartext HTTP, plus TLS-terminating setups where Squid decrypts and inspects.
The attacker also needs the proxy to reach an FTP server they control on port 21. Both FTP and that port are on by default.
How the leak works
The bug sits in Squid's FTP directory-listing parser. To handle old NetWare servers that padded listings with extra spaces, the code skips whitespace with a loop: while (strchr(w_space, *copyFrom)) ++copyFrom;.
If the attacker's FTP server sends a listing line that ends right after the timestamp, with no filename, copyFrom lands on the string's null terminator. strchr treats that terminating NUL as part of the string it searches, so it returns a pointer instead of NULL, and the loop never stops. It walks off the end of the buffer, and xstrdup copies whatever follows back to the attacker as a filename.
The leaked bytes are the useful part. Squid reuses freed memory buffers without zeroing them, so a 4KB buffer that recently held a victim's HTTP request still holds most of it. A short FTP line overwrites only the first few bytes; the over-read returns the rest.
Calif's demo pulls an Authorization header from a victim sharing the same proxy, enough to act as that user. Proof-of-concept code is public, and no in-the-wild exploitation has been reported as of writing.
What to do
If you patch, verify the fix, not just the version. Confirm the guard is in FtpGateway.cc, or check your distribution's backport, since distros ship their own builds (Debian packages Squid 5.7).
The public thread is still inconsistent: maintainer Amos Jeffries first said Squid 7.6 carried the fix, then corrected that to 7.7, and on June 22 Debian's Salvatore Bonaccorso noted the referenced commit looks like it is already in 7.6.
The fix is small, a null-terminator check before the vulnerable strchr calls, merged to the development branch in April and v7 in May. Squid 7.6 does separately patch CVE-2026-50012, an unrelated cache_digest heap overflow.
The cleaner move is the one the researchers recommend anyway: turn FTP off. Chromium dropped FTP years ago, and most networks carry almost none of it, so disabling it removes this attack surface for free, whatever build you run.
The risk is real but bounded. SUSE rates it moderate, CVSS 6.5, and the vector explains the score: the attacker needs proxy access (low privileges), and the only impact is confidentiality, nothing on integrity or availability.
Calif credits Anthropic's Claude Mythos Preview, the model behind Project Glasswing, with catching the strchr quirk almost at once, the same kind of buried parser bug AI agents have been surfacing elsewhere, including in FFmpeg. Calif hints Squid's FTP code may not be the last place it forgot to stop reading.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
English (US) ·