Squidbleed: A 1997 FTP Parsing Change Is Still Leaking Other Users' Cleartext HTTP Requests In Default Squid Deployments Today.
- Patrick Duggan
- 6 minutes ago
- 4 min read
Squidbleed is CVE-2026-47729. It is a heap over-read vulnerability in Squid, the widely deployed open-source web proxy, that leaks another user's cleartext HTTP request — including any credentials or session tokens in that request — to an attacker who can send a crafted request to the same proxy. The vulnerability traces to a change in Squid's FTP parsing code made in 1997. It is present in Squid's default configuration today.
The name is deliberate. The researchers at Calif.io who disclosed it named it after Heartbleed, and the parallel is structurally accurate. Heartbleed read memory from the TLS stack and returned it to a remote attacker without authentication. Squidbleed reads memory from the proxy's heap and returns it in an HTTP response. Both are memory disclosure bugs. Both leak material from other users' sessions. Both are exploitable without authentication against the exposed service. Both have been present in default configurations for longer than most security teams have had a patching policy.
The technical mechanism starts in the FTP parsing path. Squid supports FTP-over-HTTP proxying — a feature that allows HTTP clients to access FTP resources through the proxy. The 1997 change introduced a heap buffer that is allocated based on one length value and read based on a different length value, creating the over-read condition. When a crafted request triggers the mismatch, Squid reads past the end of the intended buffer and includes heap contents in its response. The heap contents are whatever the proxy most recently held in that memory region — which, in a shared proxy handling concurrent requests from multiple users, is highly likely to include fragments of other users' HTTP requests. Those fragments include Authorization headers, session cookies, API keys, and any other credential material that HTTP applications pass in request headers.
The practical exploit path is straightforward for an attacker who has access to a shared proxy — which describes most corporate web proxies, most educational network proxies, and any multi-tenant environment where Squid is deployed as a shared internet gateway. The attacker sends a crafted FTP-over-HTTP request to the proxy. The response includes heap memory from the proxy's working set. If the proxy is handling concurrent traffic, that memory includes other users' requests. The attacker iterates and collects. There is no authentication requirement for the crafted request beyond whatever the proxy itself requires for access — which in many deployments is network adjacency alone.
The default configuration exposure is the detail that sets this apart from a theoretical vulnerability. Squid enables FTP proxying by default. Most Squid deployments inherit the default configuration with minimal modification. Which means most Squid deployments are vulnerable without any administrator action beyond installation. The attacker does not need to find a misconfigured proxy. They need to find a proxy.
The 1997 timestamp deserves its own attention. A parsing behavior introduced in 1997 has been present in every subsequent version of Squid for twenty-nine years. It survived the FTP-to-HTTP transition in enterprise environments, survived the shift to TLS, survived multiple major version rewrites. It was not introduced by a recent change and it was not introduced by a dependency update. It was introduced by a developer making a length-handling decision in an FTP parser in the same year the original Tamagotchi was released, and no subsequent code review caught the mismatch between allocation size and read size for nearly three decades. This is not unusual for memory-disclosure bugs in long-lived codebases. It is unusual for one to survive long enough to have a twenty-nine-year CVE origin story.
We had a PoC for CVE-2026-47729 in our exploit harvester index as of June 22 — the day before Calif.io's disclosure went wide. The detection rule covers the crafted FTP-over-HTTP request pattern. That rule is in our STIX feed now. Consumers of our feed who were ingesting yesterday had detection coverage before the vulnerability had a name in the mainstream press.
The comparison to MongoBleed is the one worth making explicitly, because we made the same structural argument about MongoBleed in January and again last week when it resurfaced in the headlines. Both are heap memory disclosure bugs. Both leak credential material from other users' sessions. Both are exploitable without authentication against the exposed service. Both have been present in default configurations for extended periods without detection. The difference is the layer: MongoBleed is at the database tier, Squidbleed is at the proxy tier. An organization that patched MongoBleed and left Squid on its default configuration has addressed one memory disclosure bug in one tier and left the same class of bug running in a different tier. The defense is not "patch this CVE." The defense is "audit every service that handles credential material in transit or at rest for memory disclosure bugs in its default configuration," which is a substantially harder and more continuous posture than a single patch cycle.
The three actions are the same ones that apply to every memory disclosure bug in a shared service. First, update Squid to a patched build — the Calif.io disclosure includes version guidance. Second, rotate any credential or session token that may have transited a Squid proxy during the exposure window, because a heap over-read that has been present since 1997 has had an undefined exposure window and assume-breach is the honest posture. Third, evaluate whether FTP-over-HTTP proxying is actually required in your environment, because the feature that enables the exploit path is a legacy capability that most modern networks do not need — disabling it is a compensating control available before a patched build is deployed.
The five percent we will not claim is that this is the last 1997-vintage parsing bug in widely deployed proxy or gateway software. The ninety-five percent we will claim is that a vulnerability in Squid's default configuration that leaks other users' cleartext HTTP credentials, disclosed in 2026, with a root cause from 1997, is a precise illustration of why the patching mental model is not the same as the security mental model. You cannot patch something you do not know is broken. And if it has been broken since 1997, the question is not whether you need to patch it. The question is what else from 1997 is still running in default configuration somewhere in your stack, doing the same thing.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.