Researchers at Calif.io have disclosed a heap over-read vulnerability in Squid — the widely deployed open-source web proxy caching software — that can expose another user's cleartext HTTP request contents, including authentication headers and session tokens, to anyone sharing the same proxy instance. Dubbed "Squidbleed" and tracked as CVE-2026-47729, the flaw traces its origin to a single FTP-parsing code change made in 1997, meaning it has existed in default Squid configurations for nearly 29 years.
The Root Cause: A 1997 FTP Parser Bug
The vulnerability lives in Squid's FTP directory-listing parser. The specific trigger is deceptively simple:
- An attacker-controlled FTP server sends a directory listing line that terminates after the timestamp field with no filename present
- Squid's parser advances a pointer to the null terminator at the end of that line
- A subsequent call to
strchr()on the null terminator returns a pointer instead of NULL — a subtle but critical behavioral difference - A whitespace-skipping loop that depends on this return value never terminates, causing the pointer to walk beyond the buffer boundary into adjacent heap memory
The result is a classic heap over-read. Because Squid reuses freed 4KB memory buffers without zeroing them, those buffers retain the contents of recently freed HTTP request data from other connections sharing the proxy. The out-of-bounds read bleeds this stale data — including Authorization headers, session tokens, and cookies — back to the attacker.
The parallels to Heartbleed (CVE-2014-0160) are intentional; the Squidbleed nickname reflects the same class of vulnerability: a heap over-read that exposes sensitive data from adjacent memory belonging to other users.
Attack Requirements
Squidbleed is not an internet-wide exploitation risk. The attack scenario requires several conditions to be met simultaneously:
| Requirement | Detail |
|---|---|
| Proxy access | Attacker must be a permitted user of the same Squid instance |
| FTP server control | Attacker must operate an FTP server reachable on port 21 |
| Victim traffic | Victim must be sending cleartext HTTP traffic through the proxy |
| Shared instance | Both attacker and victim must be using the same proxy |
HTTPS connections are not vulnerable — they traverse Squid as opaque tunnels and their contents are never parsed.
This threat model is most relevant in corporate and enterprise proxy environments where many users share a centralized Squid instance. A semi-trusted insider or a compromised user account with proxy access would meet the conditions for exploitation.
What Can Be Leaked
When the conditions are met, the over-read exposes the raw contents of recently-freed HTTP request buffers — which can include:
- HTTP Authorization headers (Basic auth credentials in cleartext)
- Session tokens and cookies
- Request URLs and parameters
- Any other cleartext HTTP header or body data
In environments where legacy internal systems still use Basic authentication over HTTP, the exposure can be severe — credentials transmitted in cleartext by one user could be recovered by another sharing the same proxy.
CVE Details
| Field | Value |
|---|---|
| CVE | CVE-2026-47729 |
| Nickname | Squidbleed |
| CVSS Score | 6.5 (Moderate) — SUSE |
| Impact | Confidentiality only |
| Integrity / Availability | No impact |
| Affected versions | All versions prior to Squid 7.7 |
Remediation
Two paths are available:
1. Upgrade to Squid 7.7
The fix is a null-terminator check inserted before the vulnerable strchr() calls in the FTP directory listing parser. Administrators running affected versions should upgrade to Squid 7.7, which contains the patch.
2. Disable FTP Proxying (Preferred)
Calif.io recommends disabling FTP proxying entirely as the better long-term remediation. Chromium dropped native FTP support years ago, and modern networks carry virtually no FTP traffic. Eliminating the FTP proxy feature removes the attack surface with negligible operational impact for the vast majority of organizations.
Context: Legacy Code Longevity in Critical Infrastructure
Squidbleed is another data point in a growing pattern: security-critical bugs introduced by subtle edge cases in legacy parsing code that survive for decades because the vulnerable code path is rarely exercised in normal operation. The 1997 FTP change was correct enough to not trigger any observed failures across nearly three decades of production use — only a specifically crafted edge case with a trailing-null FTP listing would expose it.
Organizations running Squid in enterprise proxy configurations should treat this as a prompt to audit their FTP proxy settings, upgrade to a patched version, and review whether any users with proxy access could reasonably be considered adversarial — a threat model that becomes more important in environments with contractor access, BYOD policies, or geographically distributed user bases.