Researchers Publish Squid Proxy Bug "Squidbleed" (CVE-2026-47729) After 29 Years

A 29-year-old proxy bug surfaces — defender review for Squid Proxy deployments.

WASHINGTON — Researchers at Calif.io on June 22, 2026 published findings on a 29-year-old vulnerability in the Squid web proxy, nicknamed Squidbleed and tracked as CVE-2026-47729, a heap buffer over-read that can leak another user's cleartext HTTP request to anyone already permitted to send traffic through the same proxy. The bug sits in Squid's FTP directory-listing parser and traces to an FTP-parsing change committed in January 1997, surviving nearly three decades of releases, code reviews, and independent security audits before being surfaced. SUSE rates it moderate at CVSS 6.5; no in-the-wild exploitation has been reported as of disclosure, and proof-of-concept code is public.

The disclosure lands as a research-and-patch story rather than a breach, but it is notable on two counts. First, Squid is one of the most widely deployed open-source proxies, sitting on shared networks like schools, offices, and public Wi-Fi where the threat model — a malicious but already-authorized client — matches its everyday home. Second, the researchers credited Anthropic's Claude Mythos Preview with catching the parser quirk, adding Squidbleed to a 2026 run of AI-assisted finds that have surfaced long-dormant memory-safety bugs in mature code, which makes verification and patch-management the practical questions for defenders rather than panic.

What the Research Published

Calif.io disclosed CVE-2026-47729 in June 2026 and named it Squidbleed, a deliberate nod to Heartbleed, the 2014 OpenSSL flaw that leaked memory the same way. The vulnerability is a heap buffer over-read in the Squid web proxy's FTP directory-listing parser, and reporting by SecurityWeek and The Hacker News corroborated the core mechanism at disclosure. According to the researchers, an attacker who controls an FTP server can send a crafted directory listing that 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 — back to the attacker as part of the listing response.

The mechanism is a small parsing oversight with a long history. To accommodate old NetWare servers that padded listings with extra spaces, the code skips whitespace with a loop of the form while (strchr(w_space, *copyFrom)) ++copyFrom;. If a listing line ends right after the timestamp with no filename, the read pointer lands on the string's terminating null byte; strchr treats that NUL as part of the string it searches and returns a pointer rather than NULL, so the loop never stops and walks off the end of the buffer. Because Squid reuses freed memory buffers without zeroing them, a buffer that recently held a victim's HTTP request can still hold most of it, and the over-read returns the leftover bytes.

Two qualifiers bound the exposure, and defenders should hold both clearly. The leak only reaches traffic Squid can actually read: ordinary HTTPS rides an opaque CONNECT tunnel that Squid never sees inside, so the exposed traffic is cleartext HTTP plus any TLS-terminating setup where Squid decrypts and inspects. And Squid itself frames this as an attack by a trusted client — someone already permitted to use the proxy, not an arbitrary host on the internet — who also needs the proxy to reach an FTP server they control on port 21. Both FTP and that port are on in Squid's default configuration, which is why the researchers describe the bug as live by default rather than dependent on an unusual setup.

Defender Posture for Squid Proxy Deployments

The first task is inventory, because Squid's ubiquity is exactly what makes this easy to overlook. Squid frequently runs as a forward proxy on shared networks — campus and corporate gateways, guest and public Wi-Fi, lab and segmented internal networks — and is also embedded inside appliances, caching tiers, and content-filtering products where it may not be obvious that Squid is the underlying component. Defenders reviewing exposure should enumerate not just standalone Squid installs but any product that ships Squid, and then determine which of those terminate or inspect cleartext HTTP traffic, since that is the traffic Squidbleed can leak.

Because the threat model is a trusted client, the relevant access-control question is who can use each proxy and what they can reach through it. A proxy serving a shared population — students, guests, a broad employee base — is precisely the setup the researchers describe, where any one user can be the attacker against the others. Defenders can treat this as a prompt to review the same questions a mature vulnerability-management program asks of any shared service: which client populations share a proxy instance, whether outbound FTP to arbitrary internet hosts is something the network actually needs, and whether sensitive cleartext HTTP traffic should be flowing through a shared proxy at all.

The most durable mitigation is also the simplest, and it does not depend on patch timing. The researchers recommend turning FTP support off, and the practical case for it is strong: Chromium dropped FTP years ago, most networks carry almost none of it, and disabling FTP removes the Squidbleed attack surface outright regardless of which Squid build is deployed. For organizations that genuinely proxy FTP, that becomes a deliberate, documented exception rather than a default left on by inertia. Either way, the FTP decision and the patch decision are separable: a team can close the attack surface immediately while it works through version verification on its own timeline.

Patch Verification and Detection-Engineering Review

Patching this one rewards verifying the fix rather than trusting a version number, because the public record was briefly inconsistent. The remediation is a small change — a null-terminator check before the vulnerable strchr calls, so the loop guard becomes while (*copyFrom && strchr(w_space, *copyFrom)) — merged to the development branch in April and to the v7 line in May. In the Squid security thread on oss-sec, maintainer Amos Jeffries initially indicated Squid 7.6 carried the fix, then corrected that to 7.7; a Debian maintainer separately noted the referenced commit looks like it may already be present in 7.6, and the upstream thread was still being reconciled at disclosure. Squid 7.6 does separately address CVE-2026-50012, an unrelated cache_digest heap overflow, which makes it easy to assume coverage that may not apply to Squidbleed specifically.

The reliable check is to confirm the guard is present in the source rather than to map a CVE to a release tag and stop there. Defenders should verify that the null-terminator check exists in FtpGateway.cc in the build they actually run, and account for distribution backports, since distros ship their own Squid builds on their own version schemes — reporting at disclosure noted Debian packaging an older Squid 5.7, for example. Tracking Squid 7.7 (or a distribution's specific backport of the patched FtpGateway.cc logic) and inspecting the loop guard is the step that survives the version-number confusion.

On the detection side, Squidbleed offers concrete telemetry to reason about even though no exploitation has been observed. The precondition is a Squid instance making outbound FTP connections to attacker-controlled servers and receiving malformed directory listings, which is unusual traffic for most modern networks: outbound FTP from a proxy to arbitrary internet hosts is itself worth surfacing, and a sudden appearance of FTP directory-listing fetches against external servers is a reasonable thing to alert on. Detection engineers can use the disclosure to confirm whether their environment logs proxy egress at all, whether outbound FTP is visible in those logs, and whether the proxy tier — like any high-value shared service — is monitored rather than treated as passive infrastructure.

Open Questions

The AI-assisted origin is the part most worth watching carefully. Calif.io credits Anthropic's Claude Mythos Preview — the model associated with Project Glasswing — with catching the strchr quirk almost immediately, and frames Squidbleed as the kind of buried parser bug AI agents have been surfacing across mature codebases through 2026, with the researchers hinting Squid's FTP code may not be the last place a parser forgot to stop reading. That framing is reported by the disclosing researchers rather than independently audited, so it is best read as the researchers' account of how the bug was found, not as a measured claim about AI tooling's general reliability. The CVE, the parser mechanism, and the CVSS rating are independently corroborated across vendor and security-press reporting; the discovery method rests on the researchers' own account.

Several practical questions stay open. The exact patched-version picture was still being reconciled upstream at disclosure, so the safest posture is to verify the source guard rather than wait for the version thread to settle. It is unclear how many of the Squid instances in the wild — including those embedded inside appliances and caching tiers — will ever be inventoried, patched, or have FTP disabled, given how quietly the software runs in infrastructure. And with public proof-of-concept code available and the technique now documented, the relevant unknown is whether opportunistic use materializes against the shared-network deployments where the trusted-client threat model holds.

What is confirmed is enough to act on without overstating the risk. Squidbleed is a moderate-severity, confidentiality-only flaw, bounded to clients already permitted to use a proxy and to the cleartext HTTP traffic that proxy can read, with a small fix slated for Squid 7.7 and an immediate, build-independent mitigation in disabling FTP. For defenders, the prudent reading is to inventory Squid deployments, decide the FTP question deliberately, verify the source-level fix rather than a version tag, and use the disclosure as a trigger to confirm the proxy tier is monitored — the kind of routine review a well-run vulnerability-management program is built to absorb.

The CyberSignal Analysis

The reported facts above are the researchers' and vendors'; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — Decades-Old Code Is Load-Bearing Infrastructure Nobody Re-Reads

The single most sobering detail in this disclosure is the age: a parsing loop committed in January 1997 to accommodate old NetWare servers survived nearly three decades of releases, code reviews, and independent security audits before anyone noticed it never stopped reading. Our reading is that Squidbleed is less a story about Squid specifically than about the long tail of mature open-source code that quietly underpins shared network infrastructure. A forward proxy on a campus or guest network is exactly the kind of component that gets deployed once, hardened once, and then trusted indefinitely — which is how a 29-year-old memory-safety bug stays live by default.

For defenders the practical implication is that software age is not a proxy for software safety, and 'it's been battle-tested for decades' is a comfort that this class of bug directly undercuts. The components most worth re-examining are the ones that have been sitting untouched the longest in high-value, multi-tenant positions. Squid's FTP parser earned its scrutiny only because it was finally looked at again; the honest question every security team should sit with is how many similar loops are running in their own estate that no one has read since the Clinton administration.

Signal 02 — Verify the Source Guard, Not the Version Number

The patched-version picture for Squidbleed was briefly contradictory in public — a maintainer first pointed to Squid 7.6, then corrected to 7.7, while a Debian maintainer suggested the fix might already be present in 7.6 and the upstream thread was still being reconciled at disclosure. That confusion is compounded by Squid 7.6 separately fixing an unrelated heap overflow, which makes it dangerously easy to assume coverage that may not apply to Squidbleed specifically. Our assessment is that this is the part of the incident most likely to produce a false sense of safety.

The durable defender takeaway is to confirm the actual code guard — the null-terminator check before the vulnerable strchr calls in FtpGateway.cc — in the build you actually run, rather than mapping a CVE to a release tag and stopping. Distribution backports make this doubly important, because distros ship their own Squid builds on their own version schemes and a patched line may not correspond to any upstream tag. When the public record is inconsistent, source-level verification is the only check that survives the version-number confusion, and it is the discipline this disclosure most rewards.

Signal 03 — AI-Assisted Discovery Is a Double-Edged Trend, Reported Not Audited

The researchers credit Anthropic's Claude Mythos Preview with catching the strchr quirk almost immediately, and frame Squidbleed as the kind of buried parser bug AI agents have been surfacing across mature codebases through 2026. That framing matters, but it should be read with care: it is the disclosing researchers' account of how the bug was found, not an independently audited claim about AI tooling's general reliability. The CVE, the parser mechanism, and the CVSS rating are corroborated across vendor and security-press reporting; the discovery method rests on the researchers' own telling, and we treat it as such.

Read as a trend rather than a single result, AI-assisted discovery cuts both ways for defenders. The same tooling that surfaces a dormant over-read for the researchers is available, in principle, to whoever runs it against the same code — which shortens the window in which decades-old bugs stay comfortably buried. Our reading is that this is neither cause for panic nor for dismissal: it is a reason to treat inventory, source-level patch verification, and monitoring of high-value shared services as ongoing hygiene, because the rate at which long-dormant bugs get surfaced is unlikely to slow.

Sources