Novel Exploit · CVE-2026-47729

Squidbleed

A 1997 Squid Proxy heap over-read quietly leaks other users’ cleartext HTTP requests — auth headers and all.

Matt Lucas  ·  June 22, 2026  ·  5 min read
Detected by CaverLive detection for CVE-2026-47729 in the RedEye Intel Feed →
A dark squid bleeding red ink down a cream page — an editorial depiction of the SquidBleed Squid-proxy data leak
29 yrs
Bug age (since 1997)
6.5
CVSS (moderate)
4 KB
Reused buffer leaked
Squidbleed
TL;DR
  • What: A heap over-read in Squid's FTP directory-listing parser (Squidbleed, CVE-2026-47729) lets a permitted proxy user read another user's cleartext HTTP requests.
  • Impact: Leaked buffers can carry live Authorization headers and session tokens, letting the attacker impersonate the victim; only cleartext HTTP and TLS-terminated traffic is exposed.
  • Fix / mitigation: Apply the null-terminator guard in FtpGateway.cc (in Squid 7.7, and reportedly 7.6) or your distro's backport, and disable FTP support entirely.
  • Who's at risk: Operators of shared Squid proxies at schools, offices, and on public Wi-Fi running the default FTP-enabled configuration.

A 29-year-old bug in the Squid web proxy lets one user of a shared proxy steal another user's cleartext HTTP requests, credentials and session tokens included. Researchers at Calif.io disclosed it in June and named it Squidbleed (CVE-2026-47729), after Heartbleed, which leaked memory the same way. The flaw traces to a 1997 FTP-parsing change, and it is still live in Squid's default configuration. Proof-of-concept code is public; no in-the-wild exploitation has been reported yet.

It only works against a trusted client

Squid frames this as an attack by a trusted client: someone already permitted to use the proxy, not a random host on the internet. That is exactly Squid's home turf, the shared networks at schools, offices, and public Wi-Fi, where the attacker is simply another user of the same proxy. Three conditions have to hold, and all three are on by default. The proxy must let the attacker reach an FTP server they control on port 21, and both FTP support and port 21 are enabled out of the box. And the leak only touches traffic Squid can actually read.

That last point bounds the blast radius. Normal HTTPS rides an opaque CONNECT tunnel, so Squid never sees inside it and nothing leaks. The exposed traffic is cleartext HTTP, plus any TLS-terminating deployment where Squid decrypts and inspects on the client's behalf. Where you run SSL-bump style interception, those decrypted requests are fair game.

How the leak works

The bug sits in Squid's FTP directory-listing parser. To tolerate old NetWare servers that padded listings with extra spaces, the code skips leading whitespace with a tight 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, the loop never stops, and it walks off the end of the buffer. xstrdup then copies whatever follows back to the attacker as a filename.

The detail that makes it bleed

Squid reuses freed memory buffers without zeroing them. A 4KB buffer that just held a victim's HTTP request still holds most of it. A short FTP listing line overwrites only the first few bytes, and the over-read hands back the rest. Calif's demo pulls a live Authorization header from a victim on the same proxy, enough to act as that user.

What to do

There are two fixes, and the cheaper one is better. The patch is a null-terminator check added before the vulnerable strchr calls, merged to the development branch in April and to v7 in May. If you patch, verify the guard, not the version number.

Patching the version is not patching the bug

Because distributions backport selectively and the upstream thread contradicted itself on which release carried the fix, a 'patched' version number is not proof. Check that FtpGateway.cc contains the null-terminator guard, or turn FTP off and stop guessing.

The risk is real but bounded

SUSE rates Squidbleed moderate at CVSS 6.5, and the vector explains the score. The attacker needs proxy access, which counts as low privileges, and the only impact is confidentiality. Nothing touches integrity or availability. But confidentiality is the whole game here: a leaked session token or Authorization header is enough to impersonate the victim, and on a busy shared proxy the attacker can simply keep probing until a useful buffer comes back.

An AI caught it

Calif credits Anthropic's Claude Mythos Preview, the model behind Project Glasswing, with spotting the strchr quirk almost immediately, the same class of buried parser bug AI agents have been surfacing elsewhere, including in FFmpeg. The firm hints Squid's FTP code may not be the last place it forgot to stop reading. For defenders, the real takeaway is less about one proxy than the trend: decades-old C parsers are now being read end to end by tools that do not get bored, and 1997 is no longer too far back to matter.

Questions about your exposure?

RedEye Security provides assessments for organizations that need to understand their real risk.

Talk to us