Researchers at Calif.io have disclosed Squidbleed (CVE-2026-47729), a Heartbleed-style memory leak in Squid Proxy. A heap buffer over-read in Squid's FTP directory-listing parser lets an attacker who is already an authorized client of a shared proxy siphon fragments of other users' cleartext HTTP traffic — including Authorization headers, cookies, and session tokens.

The bug traces to a code change made in January 1997 and survived three decades of releases and security audits. It is exploitable in Squid's default configuration, so most operators are exposed until they patch or turn FTP off. SUSE rates it CVSS 6.5 (confidentiality impact only).

What the Vulnerability Is

Squid's FTP gateway parses directory listings returned by upstream FTP servers. The vulnerable code skips leading whitespace with a loop like:

while (strchr(w_space, *copyFrom)) ++copyFrom;

The problem: strchr treats the string's terminating NUL byte as part of the string it searches. When an attacker's FTP server returns a listing line that ends immediately after a timestamp — with no filename following — the pointer lands on that NUL terminator, strchr returns a non-NULL pointer instead of stopping, and the loop walks past the end of the buffer into adjacent heap memory.

Because Squid reuses freed memory buffers without zeroing them, that adjacent memory routinely contains data from other in-flight requests. The over-read copies it into the response the attacker receives. The whitespace-skip loop was added in a 1997 commit written to accommodate old NetWare FTP servers.

Why It Matters

  • It's a cross-tenant confidentiality breach. Any user permitted to send traffic through the proxy can read fragments of everyone else's cleartext HTTP requests — exactly where credentials, session cookies, and API keys live.
  • HTTPS is mostly safe — but not always. Normal HTTPS rides an opaque CONNECT tunnel Squid never looks inside. The leak hits cleartext HTTP, plus any TLS-terminating / SSL-bump setup where Squid decrypts and inspects traffic.
  • Default config is enough. FTP support is compiled in and enabled out of the box, and port 21 sits in Squid's default Safe_ports ACL. No exotic settings are required.
  • The fix history is confusing. Maintainer Amos Jeffries first said Squid 7.6 contained the fix, then corrected that to 7.7; Debian's maintainer later noted the commit looks like it landed in 7.6. Verify by commit, not version number alone.

Am I Affected?

You are likely exposed if you run Squid as a forward or shared proxy for more than one user or workload, FTP support is enabled (the default), and outbound access to FTP servers on port 21 is not blocked at the network edge. Risk is elevated if you run Squid with SSL-bump / TLS interception, because decrypted HTTPS becomes leakable cleartext inside Squid's memory.

Remediation

Disable FTP — the cleanest fix

FTP gateway support is the entire attack surface, and almost nobody needs it in 2026 (Chromium dropped FTP years ago). Removing it closes the bug regardless of patch status:

  • Remove port 21 from your Safe_ports ACL so Squid refuses FTP requests, and/or
  • Block outbound port 21 at the firewall so the proxy cannot reach attacker-controlled FTP servers.

Patch — but verify the commit, not just the version

Given the 7.6-vs-7.7 confusion, confirm your Squid binary actually includes the null-terminator check before the vulnerable strchr calls. Apply the vendor build that explicitly references CVE-2026-47729.

Rotate exposed secrets if you ran an interception proxy

If you operate SSL-bump / TLS-terminating Squid and cannot rule out exploitation, treat session tokens, cookies, and API keys that transited the proxy as potentially exposed, and rotate them. Tighten client ACLs so only authenticated users can route traffic.

Quick-Win Checklist

  • Remove port 21 from Safe_ports and/or block outbound FTP at the firewall.
  • Confirm whether FTP gateway support is actually needed (almost certainly not).
  • Apply a Squid build that explicitly cites the CVE-2026-47729 fix — verify by commit.
  • If running SSL-bump/TLS interception, rotate session tokens, cookies, and API keys.
  • Tighten client ACLs so only authenticated users can use the proxy.
  • Audit access logs for unexpected outbound FTP directory-listing requests.

Sources