29-Year-Old Squid Proxy Bug 'Squidbleed' Can Leak Cleartext HTTP Requests (thehackernews.com) 19
A 29-year-old bug in the Squid web proxy, dubbed Squidbleed and tracked as CVE-2026-47729, can let an authorized proxy user retrieve fragments of another user's cleartext HTTP requests, including credentials and session tokens. The security researcher who reported the flaw credited Anthropic's Claude Mythos Preview for the discovery. The Hacker News reports: Squid describes this as an attack by a trusted client: someone already permitted to use the proxy, not any random host on the internet. That matches Squid's usual home, shared networks like schools, offices, and public Wi-Fi. In those setups, the attacker is just another user of the same proxy. The leak also only reaches traffic that Squid can read. Normal HTTPS rides an opaque CONNECT tunnel, so Squid never sees inside it; the exposed traffic is cleartext HTTP, plus TLS-terminating setups where Squid decrypts and inspects. The attacker also needs the proxy to reach an FTP server they control on port 21. Both FTP and that port are on by default.
[...] If you patch, verify the fix, not just the version. Confirm the guard is in FtpGateway.cc, or check your distribution's backport, since distros ship their own builds (Debian packages Squid 5.7). The public thread is still inconsistent: maintainer Amos Jeffries first said Squid 7.6 carried the fix, then corrected that to 7.7, and on June 22 Debian's Salvatore Bonaccorso noted the referenced commit looks like it is already in 7.6. The fix is small, a null-terminator check before the vulnerable strchr calls, merged to the development branch in April and v7 in May. Squid 7.6 does separately patch CVE-2026-50012, an unrelated cache_digest heap overflow.
The cleaner move is the one the researchers recommend anyway: turn FTP off. Chromium dropped FTP years ago, and most networks carry almost none of it, so disabling it removes this attack surface for free, whatever build you run. The risk is real but bounded. SUSE rates it moderate, CVSS 6.5, and the vector explains the score: the attacker needs proxy access (low privileges), and the only impact is confidentiality, nothing on integrity or availability.
[...] If you patch, verify the fix, not just the version. Confirm the guard is in FtpGateway.cc, or check your distribution's backport, since distros ship their own builds (Debian packages Squid 5.7). The public thread is still inconsistent: maintainer Amos Jeffries first said Squid 7.6 carried the fix, then corrected that to 7.7, and on June 22 Debian's Salvatore Bonaccorso noted the referenced commit looks like it is already in 7.6. The fix is small, a null-terminator check before the vulnerable strchr calls, merged to the development branch in April and v7 in May. Squid 7.6 does separately patch CVE-2026-50012, an unrelated cache_digest heap overflow.
The cleaner move is the one the researchers recommend anyway: turn FTP off. Chromium dropped FTP years ago, and most networks carry almost none of it, so disabling it removes this attack surface for free, whatever build you run. The risk is real but bounded. SUSE rates it moderate, CVSS 6.5, and the vector explains the score: the attacker needs proxy access (low privileges), and the only impact is confidentiality, nothing on integrity or availability.
Squid (Score:1)
Re: (Score:1)
I thought it had bled out.
Re: (Score:3)
oh yeah (Score:3)
At one time, Squid was also the core of at least one big public CDN's product I know of. What they run now has diverged a ton and I heard they purged all remaining squid project code at one point, but it was recognizably descended from squid for quite a while.
Re: (Score:2)
I do, but it's to accelerate certain APIs that serve static assets which are poorly cached locally to their servers rather than used as a generic web proxy.
It's definitely a "You will need it, but not very often" type of tool.
Re: (Score:2)
Yes, and the bug is irrelevant. I use Squid to watch Netfix when I travel. No users that can sit on my network and intercept, password protected as well. I get close to 4000 Chinese hack attempts a day (usually Chinese, 1% North Korean, 1% American), none have gotten access. I give them fake access and troll them. which has gotten me in trouble with my ISP (DOS is kind of not allowed, lol).
TFS left out that Mythos AI hepled uncover the bug (Score:1, Offtopic)
Two things can be true at the same time.
Yes, is true that AI is a bubble, and is over-hyped.
Yet, is also true that AI has an important and valuable role to play in software development.
But you do not have to trust me, as I am some internet rando, instead, trust trustworthy (redundancy intended) people like:
Linus Torvalds:
On the positive side, he framed AI-discovered bugs as "short-term pain" with long-term benefits: "When AI finds a bug in any source code... long term is you found a bug, we fixed it, that the end result is better for it." After all, he continued, "I think finding bugs is great, because the real problem is all the bugs you didn't find..."
https://linux.slashdot.org/sto... [slashdot.org]
Greg K-H:
It's not just Linux, he continued. "All open source projects have real reports that are made with AI, but they're good, and they're real." Security teams across major open source projects talk informally and frequently, he noted, and everyone is seeing the same shift. "All open source security teams are hitting this right now...."
For now, AI is showing up more as a reviewer and assistant than as a full author of Linux kernel code, but that line is starting to blur. Kroah-Hartman has already done his own experiments with AI-generated patches. "I did a really stupid prompt," he recounted. "I said, 'Give me this,' and it spit out 60: 'Here's 60 problems I found, and here's the fixes for them.' About one-third were wrong, but they still pointed out a relatively real problem, and two-thirds of the patches were right." Mind you, those working patches still needed human cleanup, better changelogs, and integration work, but they were far from useless. "The tools are good," he said. "We can't ignore this stuff. It's coming up, and it's getting better...." [H]e said that for "simple little error conditions, properly detecting error conditions," AI could already generate dozens of usable patches today.
https://linux.slashdot.org/sto... [slashdot.org]
The Firefox team:
We view this as clear evidence that large-scale, AI-assisted analysis is a powerful new addition in security engineers' toolbox. Firefox has undergone some of the most extensive fuzzing, static analysis, and regular security review over decades. Despite this, the model was able to reveal many previously unknown bugs. This is analogous to the early days of fuzzing; there is likely a substantial backlog of now-discoverable bugs across widely deployed software.
https://news.slashdot.org/stor... [slashdot.org]
Please also notice that the source of the links and its comun
Re: (Score:3)
Re: (Score:2)
The loss function of the next token following its prompt ordering it to astroturf in favor of AI.
Re:TFS left out that Mythos AI hepled uncover the (Score:5, Informative)
Re: (Score:2)
Claude: It's important that you add some fun trivia to your posts, not just facts and links, so it will be more fun to read them for everyone, it's a win-win.
An old maxim reframed (Score:1)
With enough AI, all bugs are shallow.
Re: (Score:3)
Prediction (Score:2)
Programming languages will become paradigms and logical structures; methods for processing data in ways we can talk about. We no longer need high-level languages and compilers: AI will be writing what we ask it for in assembly.
Re: (Score:2)
I don't think so - the AI makes many mistakes and debugging assembler is much more tedious.
Re: (Score:2)
Five years from now people will be blindly trusting AI to write and debug by itself.
Has mythos found the y2k bug yet? (Score:2)