Vulnerability

Squidbleed: 29-Year-Old Squid Proxy Vulnerability Leaks Passwords and API Keys from Other Users

dark6 23 June 2026
Read Time:3 Minute, 53 Second

Security researchers at Calif.io have disclosed a critical memory disclosure vulnerability in Squid Proxy, dubbed Squidbleed, that has gone undetected for nearly 29 years. Discovered with the assistance of Anthropic’s Claude Mythos Preview AI model, the flaw allows an attacker who controls an FTP server reachable from the proxy to cause Squid to leak stale HTTP headers from other users — including passwords and API keys — via a malformed directory listing response.

A Bug Older Than Modern Web Security

The vulnerability traces back to a commit dated January 18, 1997, which predates all available commit history in Squid’s GitHub repository. It was introduced as a fix for NetWare FTP servers that placed four extra spaces between a file’s modification timestamp and its filename. The fix added a while(strchr(w_space, *copyFrom)) loop designed to skip over that extra whitespace.

However, the loop contains a critical oversight. In C, the strchr function treats the null terminator () as part of the search string per the C11 standard (§7.24.5.2). When no filename follows the timestamp in a directory listing entry, copyFrom points to a null byte. Rather than 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).

Why Memory Leaks into HTTP Headers

The technical conditions that make this vulnerability exploitable in practice are specific but realistic. 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 a MEM_4K_BUF buffer — 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 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. The researchers confirmed the attack by successfully leaking Authorization headers from a login page via a shared Squid proxy.

Attack Surface

The conditions required for exploitation are situational but not unlikely in real-world environments:

  • FTP support must be enabled — it is enabled by default in Squid.
  • The attacker must control an FTP server reachable on TCP port 21 from the proxy, which is included in Squid’s default Safe_ports ACL.
  • Victim traffic must be cleartext HTTP or pass through a TLS-terminating proxy configuration. HTTPS CONNECT tunnels are opaque and are not affected.

A proof-of-concept exploit has been published publicly on GitHub by the Calif.io team.

The Role of AI in Finding the Bug

The discovery of Squidbleed was made by directing Claude Mythos Preview to investigate Squid’s FTP state machine using multi-agent analysis. The AI model flagged the strchr null terminator behavior almost immediately, demonstrating how large language models trained on C standard references can surface subtle API contract violations that routinely evade human code review — even over decades of active development and security auditing.

This discovery follows the Calif.io 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 with real-world consequences.

The Fix and Recommended Mitigations

The fix for Squidbleed is elegantly simple — a single null check added before each strchr call:

- while (strchr(w_space, *copyFrom))
+ while (*copyFrom && strchr(w_space, *copyFrom))

The patch has been merged into the Squid repository. Until a patched release is deployed in production, administrators should take the following steps:

  • Disable FTP support in Squid unless explicitly required. Most modern browsers — including all Chromium-based browsers — dropped FTP support years ago, making legitimate FTP proxy traffic exceedingly rare in enterprise environments.
  • Update Squid to the latest patched version as soon as it is available for your distribution.
  • Audit your proxy’s ACL rules to ensure Safe_ports does not unnecessarily permit outbound connections to FTP servers on TCP port 21.
  • Review proxy logs for anomalous FTP directory listing requests, particularly from external or unfamiliar FTP servers.

Squidbleed is a compelling reminder that decades-old codebases — particularly those handling complex protocol parsing — can harbor memory-safety vulnerabilities that never attracted attention because the affected code path appeared obscure or rarely executed. With AI-assisted security research becoming increasingly capable, the rate of such discoveries is likely to accelerate.

Leave a Reply

💬 [[ unisciti alla discussione! ]]


Se vuoi commentare su Squidbleed: 29-Year-Old Squid Proxy Vulnerability Leaks Passwords and API Keys from Other Users, utilizza la discussione sul Forum.
Condividi esempi, IOCs o tecniche di detection efficaci nel nostro 👉 forum community