You may have heard about Squidbleed (aka CVE-2026-47729). It has the classic hallmarks of a headline-grabbing security issue: a catchy name, a legacy protocol (FTP), and a potential for data leakage. But before you initiate emergency procedures, let’s take a breath and look at the reality of this vulnerability.
Why you (probably) don’t need to panic #
While any vulnerability disclosure deserves attention, the actual exploitability of CVE-2026-47729 is highly situational. Here is why this likely isn't the "sky is falling" moment some might fear:
HTTPS is the usual default: Most modern web traffic is encrypted via HTTPS. When Squid handles this, it typically uses an opaque CONNECT tunnel, rendering the contents of that traffic encrypted, even in the case of a successful exploit.
The FTP requirement: The vulnerability is specifically tied to FTP (File Transfer Protocol). For an attack to work, the proxy must be directed to an attacker-controlled FTP server on 21/TCP that’s specially created to exploit the FTP LIST condition.
Deployment matters: This attack pattern described by Calif assumes a level of "open proxy" access that is rarely how Squid is deployed in production environments. Most implementations are configured to sit between internal clients and the internet, not as an open gateway for anyone to come calling. This reality limits your attacker-space to mostly insiders.
Why you should still check #
So, if it’s so situational, why is it making noise?
It’s legacy: FTP is still alive and well in state and federal environments and in many education environments, where old-style FTP is frequently used to move files. It’s not super-unusual, even today.
It’s bundled: Squid is often shipped as a proprietary or niche proxy solution. You might be running it without realizing it.
It’s an info leak: At its core, this is an information disclosure vulnerability that risks some secrets, in some circumstances, like passwords, session tokens, and API keys. If an attacker does manage to trick an internal user into using your proxy to connect to their malicious FTP server, the attack may be worthwhile.
How to find Squid Proxy on your network #
All that said, it’s pretty easy to take a quick audit of your environment for Squid proxy, and see if there are any surprises, or double-check your patch levels. You can use the following software query in runZero to identify assets running Squid.
vendor:="Squid Cache" AND product:=Squid AND (version:>0 AND version:<7.6)
The bottom line #
The bug has been patched since April 8. If you (or your Linux distribution, or your proprietary proxy vendor) are very on top of your routine Squid proxy patching (without the benefit of a flashy CVE), you would have picked up the patch normally. While it’s worth verifying where your internal instances are, this vulnerability requires a level of attacker interaction and specific network architecture that makes it less of a "drive-by" threat and more of an edge case. In other words, no need to panic about this, but it’s worth a second look at your services inventory.
