SURIQ
If you run a Squid proxy, a hostile FTP server can make it hand back scraps of other people's traffic, including the passwords and API tokens they sent through it. That is Squidbleed (CVE-2026-47729), a memory-disclosure flaw in the same family as Heartbleed, and it is live in Squid's default configuration. Two things changed over the weekend. A working exploit that automatically decodes stolen logins appeared on GitHub on June 21, and it became clear that the Squid 7.6 release many admins installed this month does not actually close the hole.
That second detail is the trap. The Squid team shipped 7.6 on June 8 and patched a separate buffer-overflow bug (CVE-2026-50012) in it. Squidbleed's fix was held back to the next release. As Squid maintainer Amos Jeffries clarified on the oss-security list, the fix for CVE-2026-47729 lands in Squid 7.7, not 7.6. So an admin who saw "Squid patches critical proxy bugs" headlines, upgraded to 7.6, and moved on is carrying a false sense of safety.
What Squidbleed actually leaks
The bug lives in Squid's FTP gateway, the code that lets the proxy fetch ftp:// URLs on a user's behalf and render a directory listing. When Squid parses a malformed FTP listing in a NetWare-style format, a missing check sends it reading past the end of a buffer. The root cause is a classic C footgun: the code calls strchr to scan for whitespace without first confirming it has not reached the end of the string. Per the C standard, strchr(w_space, '\0') returns a valid pointer rather than nothing, because the terminating null byte counts as part of the string. That one assumption walks the parser into adjacent heap memory.
What sits in that adjacent memory is the problem. Squid reuses 4 KB buffers across unrelated transactions, so the bytes Squid reads back can hold leftover data from other users' requests, including HTTP Authorization headers. The discoverer, Lam Jun Rong of Calif.io, reported it on April 17, and the bug has been present in Squid since 1997. SUSE rates it CVSS 6.5, moderate. That score undersells it. A moderate rating assumes you have to work for the payoff, but the public exploit turns raw leaked bytes into parsed credentials with no effort.
Why a default install is exposed
You do not need an exotic configuration to be vulnerable. FTP support is compiled in and enabled by default, and TCP port 21 sits in Squid's default Safe_ports access-control list. So a default Squid will follow an ftp:// link a user clicks, connect out to whatever host that link points at, and parse whatever listing comes back. An attacker who controls that FTP server, or who can lure a proxied user toward one, controls the input that triggers the overread.
The published proof of concept does exactly this. It stands up a fake FTP server that sends truncated NetWare-style listings, drives the target proxy to connect to it repeatedly, sprays the heap, and reads back the leaked memory. Its README claims real-time decoding of Basic Auth and Bearer tokens out of the leaked bytes. This is the difference between a paper risk and an operational one: as of this weekend, the credential extraction is automated.
One thing narrows the blast radius. Most modern traffic is HTTPS, which a forward proxy relays as an opaque CONNECT tunnel it never decrypts, so those bytes are not sitting in Squid's parseable buffers. The credentials at real risk are in cleartext HTTP, or in deployments where Squid terminates TLS itself and sees the plaintext. If your Squid is a pure CONNECT-tunnel forward proxy, your exposure is lower. If it terminates TLS or carries cleartext HTTP with auth headers, treat this as urgent.
What to do before 7.7 lands
The clean fix is the Squid 7.7 release, where the parser gets a null-terminator check before the strchr call. The source patches were merged into the supported branches across April and May, so distribution backports are arriving; check your vendor's advisory for the exact fixed package rather than trusting a version number alone, and do not assume a jump to 7.6 covered you.
You do not have to wait for a rebuild to cut the risk today, because the entire attack hinges on Squid making an outbound FTP connection and parsing the response. Disable FTP handling, or remove port 21 from your Safe_ports ACL and deny the ftp protocol in your access rules, and the trigger goes away. For a forward proxy whose users do not actually browse FTP sites, that costs nothing.
What to hunt for
The behavioral signal is your proxy initiating FTP control connections to arbitrary internet hosts. A forward proxy reaching out to a stranger's server on port 21 is unusual in 2026, and a burst of repeated FTP connections to one host is exactly what the heap-spray loop in the exploit produces. Alert on outbound port-21 connections originating from your Squid hosts to destinations outside any FTP you actually use. Pair that with a review of who can reach the proxy: if untrusted clients can feed it ftp:// URLs and the proxy can reach the open internet, you have the full preconditions in place.
Squidbleed is a reminder that "patched" is a claim to verify, not accept. Two bug fixes landed a release apart under nearly the same headline, and the more dangerous of the two is the one that did not make the first cut. Read the advisory, confirm the version that actually carries your fix, and shut off the FTP path in the meantime.