A Heartbleed-style heap buffer overread lurking in Squid Proxy since 1997 can silently leak HTTP headers, including passwords and API keys, from other users on the same proxy.
Security researchers at Calif.io have disclosed a critical memory disclosure vulnerability in Squid Proxy, dubbed Squidbleed, discovered with the assistance of Anthropic’s Claude Mythos Preview AI model.
The bug impacts all Squid versions in the default configuration and has gone undetected for nearly three decades, predating all available commit history in Squid’s GitHub repository.
29-Year-Old Squidbleed Vulnerability
Squidbleed (CVE pending) is a heap buffer overread rooted in Squid’s FTP directory listing parser. When exploited, it causes Squid to read memory beyond a heap-allocated buffer and return that stale data, potentially including another user’s HTTP request, authorization headers, or API keys, as part of an FTP directory listing response.
The flaw traces back to a commit dated January 18, 1997, which added logic to handle NetWare FTP servers that placed four spaces between a file’s modification timestamp and its filename. The fix introduced a while(strchr(w_space, *copyFrom)) loop designed to skip over extra whitespace.
However, there is a critical oversight: strchr in C treats the null terminator ( ) as part of the search string per C11 §7.24.5.2. When no filename follows the timestamp, copyFrom points to a null byte, but instead of halting, strchr returns non-NULL, causing ++copyFrom to increment past the buffer boundary and into adjacent heap memory.
The result is a confirmed heap overread of up to 4,065 bytes, validated by AddressSanitizer (ASAN).
Squid uses per-size freelists on top of malloc. When a 4KB buffer is freed, it is recycled without zeroing. If a victim’s HTTP request was previously stored in MEM_4K_BUF which is the case for most standard HTTP requests on Squid 7.x, where CLIENT_REQ_BUF_SZ is set to 4096 only the first few dozen bytes are overwritten by the short FTP listing line. The remainder of the buffer retains the victim’s stale request data.
An attacker who controls an FTP server reachable from the proxy can then trigger the overread via a malformed directory listing with no filename, causing Squid to return the victim’s recycled HTTP data, including Authorization headers and session tokens as part of the FTP response, reads Calif.io research.
Squidbleed Attack Surface
The attack surface is situational but realistic:
- FTP support must be enabled (it is on by default)
- The attacker must control an FTP server reachable on TCP port 21 from the proxy (included in Squid’s default
Safe_portsACL) - Victim traffic must be cleartext HTTP or pass through a TLS-terminating proxy setup HTTPS CONNECT tunnels are opaque and unaffected
The researchers confirmed the attack by leaking Authorization headers from a login page via a shared Squid proxy. A proof of concept is publicly available on GitHub.
The fix is a single-line null check applied before each strchr call:
c- while (strchr(w_space, *copyFrom))
+ while (*copyFrom && strchr(w_space, *copyFrom))The patch has been merged into the Squid repository. Administrators are strongly urged to disable FTP support unless explicitly required, as most modern browsers, including all Chromium-based browsers, dropped FTP support years ago, making legitimate FTP proxy traffic exceedingly rare.
The discovery was made by directing Claude Mythos Preview to investigate Squid’s FTP state machine using multi-agent analysis. The model flagged the strchr null terminator behavior almost immediately, demonstrating how LLMs trained on C standard references can surface subtle API contract violations that evade human code review.
This follows the team’s earlier disclosure of a hidden HTTP/2 vulnerability uncovered using OpenAI’s Codex Cyber, signaling a broader trend of AI-assisted open-source security auditing.
Follow us on Google News, LinkedIn, and X to Get More Instant Updates.
