Squidbleed (CVE-2026-47729): Claude Mythos Found a 29-Year-Old Heartbleed-Style Memory Leak in Every Version of Squid Proxy — And the Patch Isn’t in 7.6

Sources: Calif.io primary research blog (Lam Jun Rong) · squidbleed.xyz · GitHub PoC (califio/publications) · The Hacker News · SecurityWeek · The CyberSec Guru · Security Affairs · SC Media · CybersecurityNews | CVE: CVE-2026-47729 | CVSS: 6.5 (SUSE) — pending formal score | Discovered by: Calif.io using Claude Mythos Preview | Bug age: 29 years — introduced January 1997 | Affects: Every Squid Proxy version in default configuration | Patch: Squid 7.7 (not 7.6 — see correction above) | Immediate mitigation: Disable FTP in Squid | PoC: Public — github.com/califio/publications/tree/main/MADBugs/squidbleed

Claude Mythos was asked to spelunk through Squid’s guts. It surfaced clutching a 29-year-old bug.

On June 19, 2026, Calif.io security researcher Lam Jun Rong published a vulnerability disclosure that will be remembered for at least two distinct reasons: it reveals a Heartbleed-style memory leak that has lived inside every version of Squid Proxy since 1997, and it is the first publicly documented significant vulnerability found by Anthropic’s Claude Mythos Preview model operating as an autonomous security research agent.

The Calif.io team calls their disclosure approach MADBugs — Model-Assisted Discovery Bugs — and Squidbleed is their second AI-discovered vulnerability in two weeks. Two weeks prior, they published the HTTP/2 Bomb denial-of-service chain against nginx, Apache, IIS, Envoy, and Pingora, found by OpenAI’s Codex Cyber. This time, Calif.io directed Claude Mythos Preview at Squid’s FTP state machine. The instruction to the model was to “spawn more agents to investigate the full FTP state machine behavior better.” One of the first bugs Claude returned was CVE-2026-47729 — a heap buffer overread in Squid’s FTP directory listing parser that silently leaks raw heap memory from adjacent allocations, potentially including other users’ HTTP Authorization headers, cookies, session tokens, and API keys.

The name Squidbleed is deliberate and apt. Like Heartbleed — the 2014 OpenSSL memory disclosure that became the defining security vulnerability of the 2010s — Squidbleed causes software to read past the end of a memory buffer and hand the raw contents of that adjacent memory to whoever asked. The mechanism differs in technical detail, but the operational outcome is structurally identical: a user’s private data, placed in memory by one operation, leaks into a different user’s response through a boundary failure the software doesn’t detect.

The bug: one C quirk, 29 years of invisibility

To understand why Squidbleed existed for 29 years without being found, you need to understand the specific quirk of C that makes it possible — because it is not the kind of thing that shows up obviously in a code review, even a careful one.

The vulnerability lives in Squid’s FTP directory listing parser, specifically in a function that parses the output of an FTP server’s LIST command. FTP’s directory listing format is notoriously poorly specified — it looks vaguely like the output of Unix’s ls -l, but with no standardized machine-readable structure. Squid has been parsing this ambiguous format for decades.

The specific bug occurs in the whitespace-skipping logic that advances a pointer through the directory listing string. The code calls strchr(w_space, *copyFrom) to check whether the current character is a whitespace character, and if so, advances the pointer. The intention is to stop at the null terminator — the end of the string. But here is the C quirk that makes this dangerous:

// The vulnerable code
if (flags.skip_whitespace) {
-    while (strchr(w_space, *copyFrom))   // BUG: doesn't stop at \0
+    while (*copyFrom && strchr(w_space, *copyFrom))  // FIX: null check first
        ++copyFrom;
} else {
-    if (strchr(w_space, *copyFrom))      // BUG: same issue
+    if (*copyFrom && strchr(w_space, *copyFrom))     // FIX
        ++copyFrom;
}

The problem: per the C11 standard (§7.24.5.2), strchr(s, '\0') returns a non-NULL pointer. The null terminator is considered part of the string for the purpose of strchr. This means that when the parser reaches the end of the FTP directory listing string, *copyFrom is the null terminator character, and strchr(w_space, '\0') returns non-NULL rather than stopping. The loop does not terminate. The pointer advances past the end of the buffer, into whatever heap memory happens to be adjacent — which may contain another user’s recently-freed HTTP request data, Authorization header, cookie, or session token. That raw heap memory then gets returned to the attacker as part of the FTP directory listing response.

As Calif.io’s writeup notes: “Few developers would guess that searching for ‘\0’ succeeds, which may explain how a one-line bug survived close to 30 years of code review.” This is precisely the kind of bug that is genuinely difficult for human auditors to catch: the code looks correct because the intent of the whitespace-skipping logic is clear, the bug requires knowing a specific, non-obvious behavior of a standard C library function, and the consequence — reading adjacent heap memory — only becomes visible when you think about what happens after the string ends and what allocator behavior the heap layout produces. Three separate facts, none of which appears in the vulnerable code itself.

How Claude Mythos found it — and why humans missed it for 29 years

The CyberSec Guru’s analysis identifies exactly why Claude Mythos caught what human auditors didn’t: “The bug requires connecting three facts that no single piece of code states outright: a 1997 compatibility shim for a defunct network OS, the C standard’s specific, non-obvious definition of what strchr does with a null byte, and the internal reuse behavior of a custom allocator that isn’t documented anywhere near the parsing code that depends on its zeroing behavior. Any one of those facts in isolation looks completely unremarkable. It’s the conjunction that’s dangerous, and conjunctions like that are exactly what’s easy to miss during a normal review pass and comparatively tractable for a model that can hold all three pieces of context at once.”

Calif.io’s own writeup makes this dynamic explicit: when the researcher asked Claude Mythos to “spawn more agents to investigate the full FTP state machine behavior better,” the model did so systematically, and surfaced the strchr quirk almost immediately. Claude’s training on the complete C standard reference — including the specific behavior of strchr with the null terminator — meant it recognized the edge case as meaningful rather than treating it as an unremarkable detail. As Calif.io concludes: “Claude Mythos Preview, having trained on the entire C standard reference, treats this quirk as just another fact.”

This is the second time in the same month that Claude Mythos specifically has been linked to a significant security disclosure. The White House AI executive order DataWater covered June 4 cited Mythos’s autonomous vulnerability discovery capability as the trigger event that convinced Trump to sign the AI governance policy. Squidbleed is the second public demonstration of that capability operating in a research context — finding a vulnerability that survived 29 years of human-conducted security audits, in under an hour of autonomous investigation.

Where Squid runs — and why shared proxy environments are the highest risk

Squid Proxy is one of the most widely deployed open-source proxy caching solutions in the world. Unlike many software packages where vulnerability impact is determined by the organization running the software, Squidbleed’s risk is specifically amplified by the environments where Squid is most commonly deployed:

• Enterprise corporate networks — many organizations route employee web traffic through Squid for content filtering, caching, and bandwidth management. In this configuration, every employee in the organization is sharing the same Squid proxy instance. An attacker who is an employee — or who has compromised an endpoint inside the network — is a trusted proxy client and can exploit Squidbleed to silently capture other employees’ HTTP requests, including any cleartext authentication flows.
• Schools and universities — educational networks route student and faculty traffic through Squid for filtering and caching. The same-proxy shared environment that defines Squidbleed’s risk profile is standard in academic network architecture. Interestingly, this overlaps directly with the university targeting DataWater has covered extensively in 2026 — from ShinyHunters’ Oracle PeopleSoft campaign to UNC6508’s REDCap espionage campaign. Universities are simultaneously the most Squid-dependent and the most targeted sector.
• Public Wi-Fi and ISP deployments — ISPs and public Wi-Fi operators commonly deploy Squid for transparent proxying and caching. In these deployments, the “other users on the same proxy” are random members of the public, making Squidbleed a mechanism for one hotspot user to silently capture another’s credentials.
• Government networks — public sector organizations frequently deploy Squid as part of their web filtering and proxy infrastructure, sometimes across classified or sensitive networks.

The critical patch correction: 7.6 does NOT fix Squidbleed

This is the most operationally important detail in the disclosure and the one most likely to produce a false sense of security. Early coverage of Squidbleed — including some researcher summaries and initial news reports — stated that a patch was “merged into Squid version 8 in April 2026 and shipped in version 7.6 in June 2026.” This is incorrect for the specific branch most organizations run.

Squid maintainer Amos Jeffries posted a correction to the oss-sec mailing list: Squid 7.6 patches CVE-2026-50012 — a separate heap-based buffer overflow in cache_digest reply handling — not CVE-2026-47729 (Squidbleed). The Squidbleed fix is scheduled for Squid 7.7, which had not shipped at time of publication. Organizations that upgraded to 7.6 in response to Squidbleed coverage have closed a real vulnerability (CVE-2026-50012) but not Squidbleed itself. The distinction matters because CVE-2026-50012 requires a malicious trusted upstream server — a more constrained exploitation path — while Squidbleed requires only that the attacker be a trusted proxy client, which in most enterprise and educational deployments means any internal network user.

What is and is not affected

NOT affected — standard HTTPS traffic: Normal HTTPS web browsing is relayed by Squid as an opaque CONNECT tunnel. Squid never sees inside the encrypted traffic, so there is nothing in memory to leak. The vast majority of modern web traffic is HTTPS and is not exposed.

AFFECTED — cleartext HTTP traffic: Any cleartext HTTP requests that flow through the proxy are potentially exposable. While most internet traffic is now HTTPS, internal applications, legacy systems, and some intranet resources may still use cleartext HTTP — and in enterprise environments these often carry sensitive authentication flows.

AFFECTED — TLS-terminating proxy setups: Organizations that configure Squid for SSL inspection — where Squid decrypts HTTPS traffic for content inspection before re-encrypting it — expose all intercepted traffic to Squidbleed, including traffic that was originally HTTPS. TLS-terminating proxy deployments are common in corporate and government environments for DLP and content filtering.

Immediate mitigation — disable FTP in Squid

Disable FTP support in Squid immediately. Most organizations running Squid carry virtually zero legitimate FTP traffic — Chromium dropped FTP years ago, and modern applications do not use it. Removing it eliminates the attack surface entirely at no operational cost.

# In squid.conf — remove port 21 from Safe_ports ACL
# Find and remove or comment out this line:
# acl Safe_ports port 21       # ftp

# Also add an explicit deny:
http_access deny !Safe_ports

# Restart Squid after editing:
sudo systemctl restart squid

# Verify FTP is disabled by checking active ACLs:
squid -k parse 2>&1 | grep -i ftp

# If you cannot edit squid.conf, block port 21 outbound at your perimeter firewall
# This prevents the proxy from reaching attacker-controlled FTP servers on port 21

Additional steps:

1. Audit all internal applications using cleartext HTTP through the proxy. Any application routing cleartext HTTP through a shared Squid instance is potentially exposing its authorization headers and session tokens. Identify and migrate these to HTTPS.
2. Review TLS-terminating proxy configurations. If your Squid deployment performs SSL inspection, assess whether the traffic being inspected warrants the additional exposure risk Squidbleed creates in a shared proxy environment.
3. Monitor for the Squid 7.7 release. The Squidbleed patch is scheduled for 7.7. Subscribe to Squid’s release announcements and treat 7.7 as a priority patch the moment it ships.
4. If you upgraded to 7.6 thinking you had patched Squidbleed — you haven’t. Apply the FTP mitigation above immediately and wait for 7.7.
5. Run the public PoC against your instance in a test environment to confirm your mitigation is effective: github.com/califio/publications/tree/main/MADBugs/squidbleed

The bigger picture: AI is now finding the bugs humans spent decades missing

Squidbleed joins a rapidly growing list of significant vulnerabilities discovered in 2026 with AI assistance. Two weeks before Squidbleed, Calif.io published the HTTP/2 Bomb using OpenAI’s Codex. Three weeks before that, DataWater covered how depthfirst’s autonomous agent found 21 zero-days in FFmpeg for $1,000, including a stack buffer overflow that dated to 2003. The CVE-2026-49160 HTTP/2 DoS vulnerability patched in Microsoft’s record June Patch Tuesday was also discovered by AI-powered research tools. OpenAI today released GPT-5.5-Cyber to trusted defenders for the same class of tasks.

The pattern is consistent: AI agents are finding vulnerabilities in heavily audited, decades-old C codebases that human security researchers missed repeatedly. They are doing so not because they are cleverer than human researchers, but because they can hold larger context windows simultaneously — connecting facts across a 1997 compatibility shim, a specific C standard library behavior, and an internal allocator’s memory layout that no single piece of code ever states together — and because they are willing to “spawn more agents” to chase a state machine down every branch until something doesn’t add up.

The White House AI executive order acknowledged this dual-use reality explicitly: the same capability that finds Squidbleed defensively could be used offensively by threat actors who have access to equivalent models. Squidbleed is a proof of concept for both sides of that argument simultaneously. For defenders, it demonstrates that AI-assisted security research can close 29-year-old vulnerabilities before they are weaponized. For threat intelligence professionals watching the offensive landscape, it demonstrates that the AI capability the White House was responding to in June is already producing real, publicly-disclosed results in research contexts — and that similar capabilities in adversarial hands will likely produce the same findings in attack contexts.

Sources and further reading

• Calif.io — Squidbleed (CVE-2026-47729): Primary Technical Research by Lam Jun Rong
• squidbleed.xyz — Official Vulnerability Page with FAQ and Patch Guidance
• GitHub — Calif.io PoC and Technical Details
• The Hacker News — 29-Year-Old Squid Proxy Bug ‘Squidbleed’ Can Leak Cleartext HTTP Requests
• SecurityWeek — Decades-Old Squid Proxy Flaw ‘Squidbleed’ Can Expose User Data
• The CyberSec Guru — Squidbleed CVE-2026-47729: Inside Squid’s 29-Year-Old Bug
• Security Affairs — Squidbleed: 29-Year-Old Squid Bug Leaks User Credentials
• SC Media — Squid Proxy Vulnerability Dubbed Squidbleed Discovered

DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #32 — June 23, 2026. Previous: FortiBleed CISA Advisory Update (June 20) · FortiBleed Original Analysis (June 18) · UNC6508 China-Nexus Espionage (June 16). Browse the full threat brief archive →