Squidbleed CVE-2026-47729: How a Squid Proxy Memory Leak Can Expose HTTP Requests

Squidbleed CVE-2026-47729 is a heap over-read vulnerability in Squid Proxy’s FTP gateway code. It can allow a trusted proxy user to leak memory from unrelated proxy transactions. In practical terms, that memory may contain another user’s cleartext HTTP request, including Authorization headers, cookies, session tokens, API keys, and internal URLs.

The issue was publicly disclosed by Calif.io in June 2026. The researchers described it as a Heartbleed-style memory leak hiding in Squid since 1997. The comparison is useful because both bugs show how a small memory-handling mistake can expose sensitive data that should never be returned to the requester.

The attacker must already be allowed to send traffic through the same Squid proxy. That condition limits the bug compared with a fully unauthenticated internet attack, but it still matters in shared environments such as schools, offices, public Wi-Fi networks, universities, and corporate proxy deployments.

The safest response is to patch Squid, verify the actual vendor fix, disable FTP if it is not needed, restrict proxy access, reduce cleartext HTTP exposure, and monitor Squid logs for suspicious FTP activity.

Item	Details
Vulnerability name	Squidbleed
CVE	CVE-2026-47729
Product	Squid Proxy
Vulnerability type	Heap over-read, out-of-bounds read, memory disclosure
Affected component	FTP gateway and FTP directory listing parser
Main risk	Cleartext HTTP request leak from shared proxy memory
Possible leaked data	Cookies, Authorization headers, session tokens, API keys, internal URLs
Attacker requirement	Access to use the same Squid proxy
Highest-risk environments	Shared proxies, public Wi-Fi, offices, schools, TLS-inspecting networks
Safer traffic type	Normal HTTPS CONNECT tunnel
Main mitigation	Patch Squid, disable FTP, restrict proxy access, monitor logs

What is Squidbleed CVE-2026-47729?

Squidbleed CVE-2026-47729 is not just another routine proxy bug. It is a reminder that old, quiet code can still sit inside critical internet infrastructure and expose sensitive data years later.

The vulnerability affects Squid Proxy’s FTP gateway handling. Squid is widely used as a caching and forwarding proxy for HTTP, HTTPS, FTP, and other protocols. Organizations use it to manage web access, reduce bandwidth, filter traffic, log activity, and enforce browsing rules.

The problem is that Squid often works as shared infrastructure. Many users may send traffic through the same proxy. If the proxy mishandles memory, one user’s traffic can become part of another user’s risk.

Squidbleed allows a trusted proxy client to trigger an out-of-bounds read in Squid’s FTP parser. When the bug is triggered, Squid may return memory from unrelated transactions. That leaked memory may include another user’s cleartext HTTP request.

This is why the issue belongs inside any serious vulnerability management process. The bug is not only about one package update. It is about finding old services, understanding exposed protocol paths, and confirming that security patches actually landed.

Why This Squid Proxy Vulnerability Matters

A proxy is supposed to be invisible. Users request a website, the proxy forwards the request, and the response comes back. Most people only notice the proxy when a site is blocked or the connection is slow.

Security teams see something different. A proxy is a powerful trust point. It can see requests, enforce policy, authenticate users, inspect content, and connect internal users to external destinations.

That trust is exactly why a Squid proxy vulnerability matters.

The attacker does not need to compromise the victim’s laptop. The victim does not need to click anything. The attacker only needs permission to use the same proxy and the ability to make Squid contact a malicious or misbehaving FTP server.

In a small lab, this may sound narrow. In a real shared network, it becomes more serious. A “trusted client” can be a student, an employee, a guest Wi-Fi user, a contractor, or a compromised endpoint that still has proxy access.

This is where attack surface management becomes important. Old protocols like FTP may still be allowed because nobody removed them. A forgotten port rule can keep a vulnerable code path alive.

What is Squid Proxy?

Squid is a caching and forwarding proxy. It sits between users and the web. When a user asks for a page, Squid can fetch it, cache it, filter it, log it, or apply access rules before returning the content.

Common use cases include:

Web caching
Bandwidth optimization
Internet access control
Content filtering
Corporate browsing policy enforcement
School and university web gateways
Public Wi-Fi proxying
Transparent proxy deployments
Server acceleration in some setups

Squid is useful because it centralizes control. Instead of managing every user’s network path separately, an organization can route traffic through a proxy and apply one set of rules.

That same central role also makes Squid sensitive. If the proxy leaks memory, it may leak data from traffic that recently passed through it.

What is a Heap Over-Read?

A heap over-read happens when a program reads beyond the memory area it was supposed to read.

Think of memory as a row of locked mailboxes. A program is allowed to open one mailbox because that is where its current message is stored. A safe program stops there. A vulnerable program keeps reading the next mailbox, even though it may belong to another user or another transaction.

That is the core idea behind Squidbleed.

The bug does not need to overwrite memory. It does not need to directly take control of the server. It reads too far and can return data that should have stayed private.

In security language, this is an out-of-bounds read. In practical language, it is a memory leak.

The Code-Level Root Cause

The bug lives in Squid’s FTP directory-listing parser. FTP directory listings are old, inconsistent, and full of historical compatibility problems. Different FTP servers can format listing lines differently. Over time, parser code gets filled with special cases to support old systems.

The vulnerable logic is tied to whitespace skipping after a timestamp in an FTP listing. The simplified pattern looks like this:

while (strchr(w_space, *copyFrom)) ++copyFrom;

At first glance, this looks normal. The parser is trying to skip whitespace until it reaches the filename.

The problem appears when an attacker-controlled FTP server sends a malformed listing line that ends right after the timestamp. There is no filename. The pointer reaches the null terminator, which marks the end of the string in C.

The subtle issue is that strchr() can match the terminating null byte in the string it searches. If the parser does not check for the null terminator before calling strchr(), the loop may fail to stop at the end of the buffer. The pointer keeps moving forward, beyond the memory that belongs to the FTP listing.

After that, Squid may copy whatever memory follows and treat it like a filename. That copied memory may contain leftover data from another HTTP request handled by the proxy.

This is why Squidbleed is a heap over-read. It reads past the boundary and leaks what it finds.

How Squidbleed Can Leak HTTP Requests

The attack chain starts with something ordinary.

A user sends traffic through a shared Squid proxy. If the traffic is cleartext HTTP, Squid can see the full request. That request may include cookies, Authorization headers, Bearer tokens, API keys, or internal application paths.

Squid processes the request and stores parts of it in memory. Later, that memory buffer may be freed and reused. If the buffer is not fully cleared, pieces of the old request can remain in memory.

Now the attacker, who is also allowed to use the same proxy, makes Squid connect to an FTP server they control. The malicious FTP server sends a malformed directory listing. The listing reaches the vulnerable FTP parser. Squid walks past the end of the expected string and copies extra memory into the response.

The attacker receives leaked bytes. If those bytes contain a session cookie or Authorization header, the attacker may be able to act as the victim.

That is why Squidbleed is more than a parser bug. It can become a credential exposure problem.

Step	What Happens	Why It Matters
1	A victim uses a shared Squid proxy	Their request is processed in Squid memory
2	The victim sends cleartext HTTP or decrypted traffic	Squid can read the request content
3	Sensitive data remains in reused memory	Cookies or tokens may still be present
4	An attacker also uses the same proxy	The attacker is a trusted client, not a random outsider
5	The attacker contacts a malicious FTP server through Squid	The FTP parser is reached
6	The FTP server sends a malformed listing	The parser reaches the vulnerable edge case
7	Squid reads beyond the buffer	Unrelated memory may be copied
8	The attacker receives leaked bytes	Those bytes may contain another user’s HTTP data

What Data Can Squidbleed Expose?

Squidbleed can expose data that Squid recently held in memory. The exact result depends on timing, memory reuse, traffic type, and how many attempts the attacker makes.

Possible leaked data includes:

HTTP Authorization headers
Basic Authentication credentials
Bearer tokens
Session cookies
API keys
Internal URLs
Host headers
Form parameters
Usernames
Internal application paths
Proxy request metadata
Partial HTTP request bodies

The attacker may not receive a clean, complete request every time. Memory disclosure is often messy. A leak may contain fragments, partial headers, broken strings, or unrelated data.

But security teams know that partial data can still be dangerous. One valid session token can be enough.

If exposure is suspected, organizations should consider incident response recovery, log preservation, session invalidation, and credential rotation.

Why Cleartext HTTP Is the Main Risk

Squidbleed is most dangerous when Squid has readable traffic in memory. Cleartext HTTP is the clearest example. If a user accesses an HTTP site or an internal HTTP application through Squid, the proxy can see the request headers and content.

That means sensitive data may be present in memory in readable form. If a later over-read reaches that memory, the attacker may receive useful information.

This is why internal HTTP applications deserve special attention. Many organizations still run old dashboards, admin panels, device interfaces, or internal APIs over plain HTTP because they are “inside the network.”

Squidbleed shows why that assumption is risky. Internal traffic can still pass through shared infrastructure, and shared infrastructure can leak.

Organizations should review internal applications through web application security testing and migrate sensitive internal traffic to HTTPS wherever possible.

Does Squidbleed Affect HTTPS Traffic?

Normal HTTPS through a proxy usually uses the CONNECT method. In that setup, Squid creates a tunnel between the browser and the destination server. The content inside the tunnel remains encrypted.

Squid may see the destination host and port, but it does not see the Authorization header, cookies, or page content inside the encrypted stream.

So, normal HTTPS CONNECT traffic is generally not exposed in the same way as cleartext HTTP.

The exception is TLS inspection, often called SSL bumping or HTTPS interception. In that setup, Squid decrypts HTTPS traffic so it can inspect, filter, or log it. Once Squid decrypts the traffic, sensitive headers and cookies may exist in proxy memory in readable form.

That changes the risk. If a company uses TLS inspection, Squidbleed should be treated with higher urgency because decrypted HTTPS data may be present in memory.

Security teams can connect proxy telemetry, endpoint activity, and network alerts through extended detection response XDR during investigation.

Who is Most at Risk?

Squidbleed is most concerning in shared proxy environments where many users pass traffic through the same Squid instance.

Higher-risk environments include:

Schools
Universities
Corporate offices
Public Wi-Fi providers
Hotels
Airports
Airlines and travel networks
Libraries
Managed service provider networks
Corporate web filtering systems
Networks with TLS inspection
Networks that still allow FTP
Internal applications still using plain HTTP

Lower-risk environments include:

Single-user Squid deployments
Proxies with FTP disabled
Fully patched Squid servers
Environments where only normal HTTPS CONNECT traffic passes through
Networks with strict authentication and user segmentation
Environments where cleartext HTTP is blocked or rare

Risk depends heavily on configuration. A patched and tightly controlled Squid proxy is a different story from an old shared proxy that allows broad local network access and still permits FTP.

Who Can Exploit Squidbleed?

The attacker must already be allowed to send traffic through the same Squid proxy.

That detail matters because it keeps Squidbleed from being a simple unauthenticated internet-wide attack in normal deployments. But it should not make administrators relax too quickly.

In real networks, “trusted client” can mean many things. It can mean an employee. It can mean a student. It can mean a guest on Wi-Fi. It can mean a compromised laptop. It can mean a contractor account.

A good rule is simple: if one user group should not be able to risk another user group’s traffic, they should not share the same proxy trust boundary.

A cyber resilience assessment can help organizations test whether segmentation, proxy access rules, logging, and response processes are strong enough.

Squidbleed vs Heartbleed

Squidbleed is often compared with Heartbleed because both involve memory disclosure. But the comparison should be handled carefully.

Area	Heartbleed	Squidbleed
Product	OpenSSL	Squid Proxy
Bug location	TLS heartbeat extension	FTP gateway parser
Main impact	Memory disclosure	Memory disclosure
Attack position	Remote attacker against exposed TLS service	Trusted client using the same proxy
Data at risk	Server memory, keys, credentials, sessions	Proxy memory, HTTP requests, cookies, tokens
Traffic most relevant	TLS services	Cleartext HTTP and decrypted proxy traffic
Direct RCE	No	No
Practical lesson	Small memory bugs can leak secrets	Legacy proxy parsers can leak shared user data

The real lesson is not that every memory leak is the next Heartbleed. The lesson is that old parsing code can quietly sit inside trusted infrastructure for decades, waiting for the wrong input.

The Calif.io and Claude Mythos Angle

One of the more interesting details in the disclosure is how the bug was found. Calif.io credited Claude Mythos Preview, connected with Anthropic’s Project Glasswing work, for spotting the subtle strchr() behavior quickly during code review.

That detail matters because this is exactly the type of bug that is easy for humans to miss. The line looks ordinary. The behavior is hidden in a small edge case involving null-terminated strings, pointer movement, and old parser assumptions.

This does not mean automated tooling replaces human security engineers. It means modern code review can benefit from automated reasoning, fuzzing, and human validation working together.

The final responsibility still belongs to maintainers, reviewers, vendors, and administrators who need to patch and verify the fix.

Squidbleed is a strong example of how legacy code, old protocols, and subtle C behavior can combine into a modern security problem.

Official reference: Calif.io Squidbleed disclosure

CVSS 6.5 Explained

SUSE rates CVE-2026-47729 as moderate severity with a CVSS 3.1 base score of 6.5.

The vector is:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Here is what that means in plain English:

CVSS Metric	Value	Meaning
Attack Vector	Network	The attack can be triggered through network access to the proxy path
Attack Complexity	Low	The exploit condition is not considered highly complex once the attacker has the right position
Privileges Required	Low	The attacker needs permission to use the proxy
User Interaction	None	The victim does not need to click anything
Scope	Unchanged	The impact remains within the same security authority
Confidentiality Impact	High	Sensitive data may be exposed
Integrity Impact	None	The bug does not directly modify data
Availability Impact	None	The main described impact is not service disruption

The score is moderate because exploitation requires proxy access and the impact is mainly confidentiality. But in a shared proxy environment, confidentiality is often the most important concern.

A single leaked session token may be enough to turn a moderate CVSS score into a serious incident.

FTP Gateway vs ftp_port: The Configuration Detail Admins Should Not Miss

There is an important configuration detail that can confuse administrators.

Squid’s native ftp_port listener and Squid’s FTP gateway or FTP URL handling are not the same thing.

The official Squid documentation lists the default value of ftp_port as none. That means native FTP proxy listening may not be enabled by default.

But that does not automatically mean FTP-related attack surface is gone. Squid ACL examples can include Safe_ports port 21 for FTP. If users can make Squid access FTP resources or reach FTP servers through allowed rules, the FTP gateway path may still matter.

Administrators should check:

Is ftp_port configured?
Is port 21 allowed in Safe_ports?
Are FTP URLs allowed through the proxy?
Can users make Squid connect to external FTP servers?
Is outbound TCP/21 allowed from the Squid host?
Is FTP actually needed by the business?

If FTP is not needed, disable or block it. Modern browsing rarely depends on FTP, and removing unused legacy protocol access is one of the cleanest mitigations available.

Patch and Version Verification

The public discussion around Squidbleed included some confusion around fixed versions, especially Squid 7.6 and 7.7. This is why administrators should not rely only on the visible version number.

Linux distributions often backport security fixes. A Debian, Ubuntu, Red Hat, or SUSE package may keep an older-looking version while still including the security patch. On the other hand, a manually compiled Squid build or old container image may remain vulnerable even if the system package repository has been fixed.

The safest approach is to verify the actual fix.

Administrators should check:

Vendor advisory for CVE-2026-47729
Package changelog
Whether the FTP gateway patch is included
Whether the service was restarted after the update
Whether old Squid processes are still running
Whether container images or appliances have been rebuilt
Whether the vulnerable FTP parser path is still reachable

The fix itself is small in concept: the parser must stop at the null terminator before calling whitespace search logic such as strchr(). But deployment verification is just as important as the code fix.

How to Check If Your Squid Server May Be Exposed

Start with inventory. You cannot protect a proxy you do not know exists.

Ask these questions:

Do we run Squid anywhere?
Is it installed on Linux servers, appliances, containers, or cloud images?
Is it used as a shared forward proxy?
Which user groups can access it?
Is authentication required?
Is FTP allowed?
Is port 21 listed in Safe_ports?
Is ftp_port configured?
Does the Squid host allow outbound TCP/21?
Do users access internal HTTP applications through Squid?
Is TLS inspection or SSL bump enabled?
Has the vendor package been patched for CVE-2026-47729?
Was Squid restarted after patching?
Are old containers or old Squid processes still running?
Are logs available for FTP activity review?

If the answer to several of these questions is yes, treat the system as a priority.

For broader exposure mapping, pair this review with online threat exposure monitoring, especially if proxy infrastructure is reachable from multiple networks.

How to Patch Squidbleed

Patching should be the first technical action where a fixed package is available.

Recommended patching steps:

Identify every Squid server and container.
Record the operating system, Squid package source, and current version.
Check the vendor security advisory for CVE-2026-47729.
Update Squid through the official package manager or vendor update channel.
Restart the Squid service.
Confirm the running process uses the patched binary.
Check package changelogs for CVE-2026-47729.
Rebuild and redeploy containers if Squid is containerized.
Contact appliance vendors if Squid is embedded in a security product.
Test proxy functionality after the update.
Keep proof of patching for compliance and audit records.

This is a good place to involve security compliance teams if the proxy supports regulated environments or handles sensitive user traffic.

How to Mitigate Squidbleed

Patching is important, but mitigation should not stop there.

Disable FTP If You Do Not Need It

FTP is a legacy protocol. Most users do not need it for modern browsing. If the organization has no clear business case for FTP, turn it off or block it.

Check:

Native FTP proxy settings
FTP URL handling
Safe_ports rules
Outbound firewall rules
Legacy applications that may still use FTP

Removing unused FTP access reduces the attack surface immediately.

Restrict Proxy Access

Do not let broad networks use the proxy by default. Avoid loose ACLs that allow entire internal ranges without review.

Use:

Authentication
Least privilege access
Group-based proxy rules
Separate proxy pools for guest and corporate users
Strong logging
Clear ownership for proxy configuration

Reduce Cleartext HTTP

Plain HTTP is the easiest traffic for Squid to read, store, and accidentally leak.

Move internal applications to HTTPS. Stop sending tokens through query strings. Remove Basic Authentication over HTTP. Use short-lived tokens. Enforce HSTS where possible. Review old internal dashboards that still rely on HTTP because they are “only internal.”

Internal does not mean safe.

Review TLS Inspection

TLS inspection gives defenders visibility, but it also puts decrypted traffic inside proxy memory. That makes the proxy a sensitive system.

If SSL bumping is enabled, review:

Which categories are decrypted
Which users are inspected
Whether sensitive services are excluded
Whether logs are protected
Whether decrypted data is handled safely
Whether the proxy is patched quickly

Where possible, limit decryption to what is truly needed.

Detection Guide for Security Teams

Squidbleed exploitation may not create a dramatic crash. Detection depends on logs, network visibility, and a good understanding of normal FTP usage.

Look for:

Requests to ftp:// URLs
Outbound connections from Squid to unknown TCP/21 hosts
Repeated FTP access by the same proxy user
FTP traffic from users who do not normally use FTP
Unusual FTP gateway errors
Malformed FTP listing behavior
Strange response sizes from FTP listings
Spikes in FTP traffic after disclosure
Suspicious entries in Squid access.log
Suspicious entries in Squid cache.log

If your organization already uses endpoint security protection services, proxy logs should be correlated with endpoint activity. A compromised trusted device may be the attacker’s starting point.

For deeper investigations, digital forensic investigation can help preserve logs, reconstruct timelines, and identify whether exposed credentials were later abused.

Incident Response Guide

If you suspect Squidbleed exposure, move quickly but carefully.

Identify affected Squid servers.
Patch Squid or disable FTP immediately.
Preserve access.log and cache.log.
Review FTP activity during the exposure window.
Identify users who accessed FTP through Squid.
Identify users who sent cleartext HTTP through the same proxy.
Review whether TLS inspection was enabled.
List internal applications that may have exposed tokens or cookies.
Rotate credentials that may have passed through the proxy.
Invalidate active sessions for sensitive applications.
Rotate API keys and Bearer tokens where needed.
Review proxy ACLs and segmentation.
Monitor for suspicious login activity after the exposure window.
Document the timeline, decisions, and evidence.
Brief leadership in plain language.

If the proxy handled sensitive systems, bring in incident response recovery support early. Waiting until after logs roll over can make the investigation harder.

Credentials That May Need Rotation

Not every environment needs a full credential reset. But if logs show suspicious FTP activity and the proxy handled cleartext or decrypted traffic, consider rotating:

Basic Authentication passwords
Bearer tokens
API keys
Session cookies
Proxy credentials
Internal application tokens
Service account tokens
Temporary access tokens
Admin dashboard sessions
Secrets that appeared in HTTP query strings

Focus first on high-value systems, privileged users, admin panels, CI/CD systems, internal APIs, and applications with long-lived tokens.

CVE-2026-47729 vs CVE-2026-50012

CVE-2026-47729 and CVE-2026-50012 may appear in the same Squid security discussion, but they are not the same vulnerability.

CVE-2026-47729 is Squidbleed. It is an FTP gateway out-of-bounds read that can leak memory from unrelated transactions.

CVE-2026-50012 is a separate cache_digest heap overflow issue. It has a different root cause and should not be confused with the Squidbleed FTP parser bug.

Administrators should track both, but verify each fix separately.

Official reference: oss-security Squid CVE thread

Developer Lessons from Squidbleed

Squidbleed is a reminder that old code does not become safe just because nobody talks about it.

The vulnerable behavior came from legacy parsing logic. It survived because FTP directory listings are messy, compatibility matters, and old code paths often receive less attention than modern features.

Developers can take several lessons from this bug:

Parser code must be strict about boundaries.
Never assume an expected field exists.
Null terminator handling matters in C.
Length-aware string handling is safer than pointer walking.
Legacy protocol support should be reviewed regularly.
Fuzzing should include old parsers and rare formats.
Empty fields should have tests.
Malformed input should fail closed.
Memory reuse should be treated carefully when sensitive data is involved.
Unused features should be removed or disabled.

Security debt often hides inside compatibility code.

Why This Bug Matters for Modern Security Programs

A vulnerability like Squidbleed is not only a patching problem. It is a design problem, an inventory problem, a monitoring problem, and a trust boundary problem.

If a guest user and an administrator share the same proxy memory pool, a bug like this becomes more dangerous. If internal systems still use HTTP, the leak becomes more useful. If FTP is allowed because nobody removed an old rule, the attack path stays open. If logs are missing, the response becomes guesswork.

That is why organizations should treat Squidbleed as a chance to improve the full security program, not just one package.

Useful areas to review include:

Penetration testing for proxy abuse paths
Web application security testing for internal HTTP applications
Endpoint security protection services for compromised trusted clients
Attack surface management for exposed and forgotten infrastructure
Vulnerability management for patch tracking
Incident response recovery for suspected data exposure
Cyber resilience assessment for trust boundary review
Virtual CISO services for long-term security governance

For more security explainers and updates, visit the Hoplon Infosec blog.

Admin Action Checklist

Use this checklist as a practical remediation guide.

Action	Priority
Inventory all Squid servers	High
Check vendor advisories for CVE-2026-47729	High
Patch Squid	High
Restart Squid after patching	High
Verify the running binary is patched	High
Check `ftp_port` configuration	High
Review `Safe_ports port 21`	High
Disable FTP if unused	High
Block outbound TCP/21 from Squid if unused	High
Restrict proxy access	High
Separate guest and corporate users	Medium
Review TLS inspection	Medium
Find internal HTTP applications	Medium
Rotate exposed credentials if needed	High
Preserve logs if exploitation is suspected	High
Monitor future FTP access	Medium
Document remediation	Medium

FAQ

What is Squidbleed?

Squidbleed is a memory disclosure vulnerability in Squid Proxy, tracked as CVE-2026-47729. It can allow a trusted proxy client to leak memory from unrelated proxy transactions through the FTP gateway parser.

What is CVE-2026-47729?

CVE-2026-47729 is an out-of-bounds read vulnerability in Squid’s FTP gateway. It can expose sensitive memory when Squid processes a malformed FTP directory listing.

Is Squidbleed the same as Heartbleed?

No. Heartbleed affected OpenSSL. Squidbleed affects Squid Proxy. They are compared because both involve memory disclosure, but their affected products and attack conditions are different.

Can Squidbleed leak passwords?

Yes, if passwords, tokens, cookies, or Authorization headers are present in cleartext HTTP requests or decrypted proxy traffic handled by Squid.

Does Squidbleed leak HTTPS traffic?

Normal HTTPS CONNECT traffic is usually encrypted and not readable by Squid. TLS inspection or SSL bumping changes the risk because Squid handles decrypted traffic.

Who can exploit Squidbleed?

An attacker must already be allowed to use the same Squid proxy. This is why shared proxy environments are the main concern.

Is Squidbleed remote code execution?

No. CVE-2026-47729 is mainly an information disclosure vulnerability. It is not described as direct remote code execution.

How do I fix Squidbleed?

Patch Squid through your vendor package or official update path, restart the service, verify the running process, and disable FTP if it is not required.

Should I disable FTP in Squid?

Yes, if your organization does not need FTP. Disabling FTP or blocking port 21 reduces the attack surface.

What data can Squidbleed expose?

It may expose HTTP headers, Authorization tokens, cookies, API keys, session IDs, internal URLs, form parameters, and other partial request data.

Is Squidbleed critical?

Some vendors rate it moderate because it requires proxy access and mainly affects confidentiality. In shared proxy environments with cleartext HTTP or TLS inspection, the real-world risk can be much higher.

How can security teams detect Squidbleed attempts?

Look for unusual FTP requests through Squid, outbound TCP/21 traffic from Squid servers, repeated FTP access from one user, FTP gateway errors, and suspicious access.log or cache.log entries.

Official References

Conclusion

Squidbleed CVE-2026-47729 is a small parser bug with a serious lesson behind it. A missing boundary check in old FTP handling code can expose memory from a trusted proxy, and that memory may contain another user’s HTTP request.

The vulnerability is not a simple internet-wide takeover bug. The attacker needs access to the same proxy, and normal HTTPS CONNECT traffic is usually protected. But in shared networks, public Wi-Fi, schools, offices, and TLS-inspecting environments, the impact can become much more serious.

The right response is practical. Patch Squid. Verify the fix. Disable FTP if the business does not need it. Restrict proxy access. Move internal applications away from cleartext HTTP. Review logs. Rotate credentials if exposure is suspected.

Squidbleed is not only a Squid problem. It is a reminder that old protocols, trusted clients, and shared infrastructure can create risk long after everyone stops paying attention.

Squidbleed CVE-2026-47729 Proxy Memory Leak