Critical Squidbleed Vulnerability in Squid Proxy Patched After 29 Years

Key Takeaways

• A critical heap buffer overread vulnerability, dubbed Squidbleed, has been discovered in Squid Proxy.
• The flaw, present for 29 years, can leak sensitive HTTP header data like passwords and API keys from other users on the same proxy.
• All default Squid versions are affected, but the exploit requires specific conditions, including enabled FTP support and cleartext HTTP traffic.
• A patch is now available, and administrators are advised to update immediately or disable FTP support.

A significant memory disclosure vulnerability, present in the widely used Squid Proxy software for nearly three decades, has finally been identified and patched. Dubbed “Squidbleed” by researchers at Calif.io, this heap buffer overread flaw, reminiscent of the infamous Heartbleed bug, could silently expose sensitive HTTP headers, including authentication credentials and API keys, from users sharing a vulnerable proxy.

The researchers, who utilized Anthropic’s Claude Mythos Preview AI model in their discovery process, note that the bug impacts all default configurations of Squid Proxy and has remained undetected since its introduction in 1997, predating much of Squid’s available commit history.

29-Year-Old Squidbleed Vulnerability Explained

The Squidbleed vulnerability (CVE pending) is specifically a heap buffer overread occurring within Squid’s FTP directory listing parser. When triggered, the proxy reads beyond the intended boundaries of a heap-allocated buffer, returning stale memory contents. This leaked data can contain fragments of another user’s HTTP request, including sensitive authorization headers or API keys, which are then inadvertently delivered as part of an FTP directory listing response.

The root cause dates back to a code commit on January 18, 1997. This commit introduced logic to correctly parse FTP directory listings from NetWare FTP servers, which often inserted four spaces between a file’s modification timestamp and its filename. A while(strchr(w_space, *copyFrom)) loop was implemented to skip this extra whitespace.

However, a critical oversight existed in the interaction with the strchr function in C. According to Calif.io research, the C11 standard specifies that strchr treats the null terminator () as part of the search string. Consequently, if no filename followed the timestamp, copyFrom would point to a null byte. Instead of terminating, strchr would return a non-NULL value, causing ++copyFrom to increment past the buffer boundary and into adjacent heap memory.

This flaw leads to a confirmed heap overread of up to 4,065 bytes, a finding validated using AddressSanitizer (ASAN). Squid’s memory management, which uses per-size freelists on top of malloc, contributes to the severity. When a 4KB buffer is freed, it is recycled without zeroing its contents. If a previous HTTP request from a victim user was stored in such a buffer (common for standard HTTP requests where CLIENT_REQ_BUF_SZ is 4096 bytes on Squid 7.x), only the initial bytes are overwritten by a short FTP listing. The remainder of the buffer retains the victim’s stale request data.

An attacker controlling an FTP server accessible from the proxy can exploit this by serving a malformed directory listing lacking a filename. This action prompts Squid to overread, returning recycled HTTP data, including sensitive Authorization headers and session tokens, as part of the FTP response.

Squidbleed Attack Surface

The feasibility of a Squidbleed attack depends on several specific, yet realistic, conditions:

• FTP support must be enabled on the Squid proxy, which is its default configuration.
• The attacker must control an FTP server reachable on TCP port 21 from the proxy. This port is typically included in Squid’s default Safe_ports ACL.
• The victim’s traffic must be cleartext HTTP or pass through a TLS-terminating proxy setup. HTTPS CONNECT tunnels are opaque and therefore unaffected.

The research team successfully demonstrated the attack by leaking Authorization headers from a login page via a shared Squid proxy. A proof-of-concept exploit is publicly available on GitHub.

The fix for Squidbleed is a straightforward, single-line null check applied before each strchr call. The patch has already been integrated into the Squid repository. The researchers also highlighted that the discovery was aided by directing Claude Mythos Preview to analyze Squid’s FTP state machine using multi-agent analysis. This demonstrates the potential of large language models (LLMs) trained on C standard references to identify subtle API contract violations that might be missed during human code review, following a trend of AI-assisted open-source security auditing.

What You Should Do

• Update Squid Proxy: Immediately apply the latest patch to your Squid Proxy installations to mitigate the Squidbleed vulnerability.
• Disable FTP Support: Unless absolutely essential, disable FTP support within your Squid Proxy configuration. Given that most modern browsers no longer support FTP, legitimate FTP proxy traffic is increasingly rare.
• Review Proxy Configurations: Regularly audit your proxy configurations to ensure that only necessary protocols and ports are enabled.
• Monitor for Anomalies: Implement robust logging and monitoring to detect unusual traffic patterns or unexpected data in FTP responses, which could indicate attempted exploitation.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.