A Heartbleed Echo From the Proxy Layer
Researchers at Calif.io disclosed on June 22 a vulnerability they call Squidbleed, tracked as CVE-2026-47729, in the Squid web proxy that has quietly carried enterprise and carrier traffic for nearly three decades. The name is a deliberate echo of Heartbleed, and the comparison is earned. Like that infamous OpenSSL flaw, Squidbleed lets an attacker read memory they should never see, and what lives in that memory is other people's secrets. On a shared proxy, a single trusted client can extract fragments of other users' cleartext HTTP requests, including the authorization headers and session tokens that authenticate them to internal and external services.
The disclosure is notable not only for its severity but for its age. The root cause sits in a change to FTP directory-listing parsing introduced in 1997, code that has been running in default configurations through countless versions and deployments. That longevity is a reminder that the proxy tier, often treated as boring plumbing, is as much a part of the attack surface as any application. When a component sees every request, a memory disclosure bug in it sees every secret.
How the Bug Actually Works
The mechanics are a textbook over-read. When Squid parses an FTP directory listing, its whitespace-skipping logic can run off the end of a buffer. If an attacker controlled FTP server sends a listing line that ends at the timestamp with no filename, the code's strchr call keeps reading past the intended boundary. Because Squid reuses freed memory buffers without zeroing them, that walk through adjacent memory can surface the remnants of recently processed HTTP requests that happened to occupy the same region.
Calif.io summarized the consequence bluntly, noting that Squid reuses freed memory buffers without zeroing them, so a 4KB buffer that recently held a victim's HTTP request still holds most of it. That is the whole exploit in one sentence. The attacker does not need to break encryption or escalate privileges in the conventional sense. They need only be a trusted client able to reach an FTP server on port 21, both of which are enabled by default, and then read back whatever the proxy failed to clear. The researchers credited Anthropic's Claude Mythos Preview with helping identify the parser flaw, a sign of how AI assisted analysis is increasingly surfacing deep, legacy bugs.
Why Shared Infrastructure Multiplies the Damage
The reason Squidbleed deserves attention from technology leaders is the multi-tenant nature of proxies. A Squid instance commonly serves an entire office, campus, or customer base, funneling everyone's web traffic through one process. That aggregation is exactly what makes a memory disclosure so dangerous, because the memory an attacker reads is shared across all those users. One malicious or compromised client on the proxy can passively skim credentials belonging to colleagues, systems, and automated services that route through the same instance.
This is the same painful lesson that shared infrastructure keeps teaching. Consolidation delivers efficiency, but it also concentrates risk, and a single flaw in a shared component can expose data from every tenant behind it. Organizations that run Squid in front of sensitive internal applications should assume that any session token or basic authentication header that passed through a vulnerable instance could have been exposed, and they should plan credential rotation accordingly rather than hoping their proxy was not targeted.
The Fix Is Easy, the Discovery Is Not
Remediation is refreshingly straightforward. Administrators can disable FTP handling, which Calif.io recommends, or upgrade to a patched release, Squid 7.7 or later. Disabling FTP is attractive because almost no modern web workload depends on the proxy's FTP support, so turning it off removes the vulnerable code path with minimal disruption. For most enterprises, that is a configuration change rather than a project, and it should be the immediate action.
The harder problem is knowing where Squid is even running. After nearly thirty years in the field, Squid is embedded in appliances, baked into legacy network architectures, and deployed by teams that may no longer document it carefully. The discovery exercise, finding every instance and confirming its configuration, will take many organizations longer than the patch itself. This is the recurring theme of legacy vulnerabilities, the bug is old, the fix is simple, and the asset inventory is the part nobody can shortcut.
AI Found It, and That Cuts Both Ways
We keep returning to one detail in this disclosure, which is that an AI model helped find a parser bug that survived in production code for twenty nine years. That is a genuinely positive development for defenders, because the same techniques that surfaced Squidbleed can be pointed at the vast back catalog of aging infrastructure that no human has audited line by line in decades. The defensive upside of AI assisted vulnerability research is real, and Squidbleed is a clean example of it paying off.
The uncomfortable corollary is that attackers have the same tools. If a model can rediscover a latent over-read in Squid, it can do the same across the long tail of widely deployed open source components that form the quiet backbone of the internet. We expect a wave of disclosures in this mold, old bugs in old code, found fast by new methods. The organizations that fare best will be those that have already done the boring work of knowing what they run, because in this new pace of discovery, the patch window is only as short as your inventory is accurate.
Rotate Credentials, Then Reassess the Proxy Tier
Patching Squid is necessary but not sufficient. Because Squidbleed can leak authorization headers and session tokens, any credential that traversed a vulnerable instance should be treated as potentially exposed. That means rotating the affected secrets, invalidating active sessions where feasible, and reviewing logs for unusual access patterns. Organizations that skip this step risk leaving valid stolen credentials in an attacker's hands even after the underlying bug is closed, which would turn a patched vulnerability into a lingering compromise.
More strategically, the disclosure is a prompt to reassess the entire proxy and middlebox tier, the often-forgotten components that sit in the data path and see everything. These devices are frequently deployed once and left untouched for years, accumulating exactly the kind of unaudited legacy code that Squidbleed embodies. We would put proxies, load balancers, and similar infrastructure on a regular review cadence, with clear ownership and patch accountability. The components that see all your traffic deserve the same scrutiny as the applications behind them, not less.
