CVE-2026-47729 Squidbleed, The Squid Proxy Memory Leak That Still Matters

CVE-2026-47729 is a Squid Proxy memory disclosure vulnerability in the FTP gateway. The bug, now widely called Squidbleed, is an out-of-bounds read that can let a trusted proxy client recover memory from unrelated Squid transactions when the proxy processes a malformed or attacker-controlled FTP directory listing. The official Squid GitHub advisory describes it as “Memory disclosure in FTP gateway,” lists Squid versions earlier than 7.6 as affected, and gives CVSS v3.1 score 6.5 with high confidentiality impact, low privileges required, no user interaction, and network attack vector. (GitHub)

That wording matters. This is not an unauthenticated internet-wide remote code execution bug. It is also not harmless. The dangerous scenario is a shared proxy environment where one authorized client can make Squid talk to an attacker-controlled or misbehaving FTP server and receive fragments of memory that may have recently held another user’s cleartext HTTP request. Calif’s technical write-up demonstrated the leak against an Authorization header in a shared proxy setting, while also noting that ordinary HTTPS CONNECT traffic is usually opaque to Squid unless the deployment terminates or inspects TLS. (blog.calif.io)

The practical defender question is therefore not “Is this the next Heartbleed?” The better question is: “Do any of our Squid proxies still allow FTP gateway traffic from shared clients, and could those proxies have handled cleartext secrets, proxy credentials, internal HTTP requests, or TLS-inspected traffic recently?” If the answer is yes or unknown, CVE-2026-47729 deserves fast triage.

What CVE-2026-47729 is

The short version is simple: Squid’s FTP directory-listing parser can read past the end of an input buffer after parsing certain FTP listing lines that end after a timestamp and do not contain a filename. The vulnerable logic involves a C string parsing edge case around strchr. The official patch adds a NUL check before strchr is called, preventing the parser from treating the string terminator as another searchable character and advancing beyond the intended buffer. (GitHub)

The less simple version is where the risk becomes interesting. Squid can act as an FTP gateway. When a client requests an ftp:// URL through the proxy, Squid connects to the FTP server, asks for a directory listing, parses the FTP LIST response, and renders an HTML directory listing for the client. FTP directory listings are not a clean, standardized, machine-readable format. Many servers emit output that resembles ls -l, but historic server variants used different spacing and date formats. Calif’s analysis traces the relevant behavior to old NetWare FTP compatibility logic designed to skip extra whitespace before filenames. (blog.calif.io)

In the vulnerable case, the parser computes a pointer named copyFrom after the timestamp token. If a listing line ends there, copyFrom points at the terminating NUL byte. In C, strchr(string, '\0') returns a pointer to the terminating NUL byte because the terminator is considered part of the string. The vulnerable loop therefore does not stop the way many developers would intuitively expect. It can increment beyond the end of the intended string buffer, and later copying can return adjacent heap memory as if it were part of a filename. Calif’s ASAN trace showed a heap overread after the parser walked past the buffer boundary. (blog.calif.io)

The official Squid patch is only two changed conditions in src/clients/FtpGateway.cc, but the security consequence is much larger than the diff size suggests. The key change is to check that *copyFrom is nonzero before asking whether it is in the whitespace set. (GitHub)

/* Vulnerable pattern */
while (strchr(w_space, *copyFrom))
    ++copyFrom;

/* Fixed pattern */
while (*copyFrom && strchr(w_space, *copyFrom))
    ++copyFrom;

That is the heart of CVE-2026-47729. A single missing NUL guard in legacy parsing code can turn an odd FTP listing into a proxy memory disclosure.

Fast facts for defenders

Artículo	Entendimiento actual
CVE	CVE-2026-47729
Common name	Squidbleed
Producto	Squid web proxy cache
Componente afectado	FTP gateway, FTP directory-listing parser
Clase de vulnerabilidad	Out-of-bounds read, memory disclosure
Weaknesses in official advisory	CWE-125, CWE-200, CWE-1286
Official upstream fixed version	Squid 7.6
Official affected upstream range	Squid older than 3.5.28 not tested and assumed vulnerable; all 4.x, 5.x, 6.x, and 7.x through 7.5 vulnerable
Attacker position	Trusted client allowed to use the Squid proxy
Required remote dependency	A misbehaving or attacker-controlled FTP server reachable from Squid
Main risk	Disclosure of memory from unrelated Squid transactions, including possible cleartext HTTP headers or credentials
Ordinary HTTPS CONNECT impact	Usually limited because Squid does not see decrypted request contents in a normal CONNECT tunnel
Higher-risk deployments	Shared proxies, public access proxies, enterprise or school proxies, SSL bump or TLS-terminating proxy configurations, internal cleartext HTTP environments
Official workaround	Deny FTP gateway traffic, or allow only trusted FTP destinations, with deny rules placed before custom http_access allow rules
NVD state checked during writing	NVD page returned “CVE ID Not Found,” while GitHub/Squid and vendor advisories already carried details
CISA KEV status checked through OpenCVE enrichment	Not listed as KEV in OpenCVE’s current enrichment

The most important correction is the fixed version. Some secondary coverage briefly repeated uncertainty around 7.7, but the official GitHub advisory says patched version 7.6, and the oss-security follow-up thread explicitly notes that the advisory lists versions earlier than 7.6 as affected and that >= 7.6 is correct. (GitHub) (seclists.org)

The source record is messy, so use the right authority

CVE-2026-47729 is a good example of why vulnerability triage should not rely on a single feed. The official Squid GitHub advisory is currently the best primary source for affected versions, patched version, workaround, CVSS vector, and disclosure credits. It lists the advisory as GHSA-8c37-pxjq-qwrg, published June 23, 2026, with package squid, affected versions < 7.6, and patched version 7.6. (GitHub)

The oss-security mailing list gave an earlier public summary on June 12, 2026. That post described CVE-2026-47729 as an improper validation bug leading to out-of-bounds read in the FTP gateway, allowing a trusted client to read from random unrelated transactions while accessing a misbehaving FTP server through Squid’s gateway feature. It also linked the patch commit. (seclists.org)

NVD lagged or differed during the checked window. The NVD page for CVE-2026-47729 returned “CVE ID Not Found” and explained that a CVE may be assigned but unavailable in NVD if it remains reserved or has not yet been processed there. (nvd.nist.gov) That does not mean the Squid advisory is fake. It means defenders should treat the Squid advisory and distribution advisories as the operational sources of truth while continuing to watch NVD for later enrichment.

Distribution status is also not uniform. Debian’s tracker showed trixie-security fixed at 6.13-2+deb13u2, forky fixed at 7.6-1y sid fixed at 7.6-2, while several older Debian entries still appeared vulnerable at the time checked. (security-tracker.debian.org) Ubuntu listed fixed packages for 22.04 LTS, 24.04 LTS, 25.10, and 26.04 LTS, with 5.9-0ubuntu0.22.04.7, 6.14-0ubuntu0.24.04.4, 6.14-0ubuntu0.25.10.4y 7.2-2ubuntu2.2 respectively. (Ubuntu) Amazon Linux listed CVSS v3 score 3.1 with pending fixes for Amazon Linux 2 Core and Amazon Linux 2023. (explore.alas.aws.amazon.com)

That variation is normal. Linux distributions often backport security fixes without changing the package to the latest upstream major version. A Debian or Ubuntu package can be fixed even if squid -v prints a version number below 7.6. Conversely, a locally built or appliance-bundled Squid may remain vulnerable even when the base operating system has a vendor fix available.

Why Squidbleed is not just another version check

Banner-based vulnerability management is weak for this issue. CVE-2026-47729 sits at the intersection of version, configuration, network reachability, and traffic sensitivity.

A Squid host is more exposed when all of the following are true:

Condición	Why it changes risk
The proxy allows multiple users or systems to share the same Squid process	Memory from unrelated transactions becomes more interesting to an attacker
Clients are authenticated but broadly trusted	“Trusted client required” does not mean “low risk” if many users, devices, contractors, labs, or students can use the proxy
FTP gateway traffic is allowed	The vulnerable code path is reached through FTP gateway processing
Squid can reach arbitrary TCP/21 destinations	An attacker can host or control the FTP server needed to shape the response
Cleartext HTTP crosses the proxy	Headers, cookies, Basic auth, bearer tokens, or internal service requests may be visible to Squid
SSL bump or TLS termination is enabled	Squid may see decrypted HTTP traffic that ordinary CONNECT tunneling would otherwise hide
Secrets pass through internal services over HTTP	Internal APIs and admin panels are often where “temporary” cleartext becomes permanent risk
Logging and egress monitoring are weak	Suspicious FTP gateway activity may go unnoticed

The opposite is also true. A single-user Squid instance with FTP blocked, no TLS interception, no cleartext secrets, and vendor-fixed packages is a much lower-risk target. The vulnerability still needs patching, but it is not the same operational emergency as a shared enterprise proxy that terminates TLS and allows outbound FTP.

The parser bug in plain English

Squid’s FTP gateway needs to turn a raw FTP directory listing into something a web client can view. A normal listing might look like this:

-rw-r--r--    1 1000     1000           40 May 20 04:17 hello.txt
-rw-r--r--    1 1000     1000           21 May 20 04:17 readme.txt

The parser identifies fields such as file type, permissions, owner, size, date, time, and filename. Historic FTP server behavior complicates that job. NetWare FTP servers used extra spaces between the timestamp and filename, so Squid carried compatibility code that skips whitespace after the timestamp. Calif’s write-up points to a 1997-era change for recognizing NetWare servers and skipping whitespace before filenames. (blog.calif.io)

The problematic input is a listing that ends after the timestamp:

d [R----F--] supervisor            512       Jan 16 18:53

There is no filename. The parser’s pointer lands on the NUL byte at the end of the string. Many developers mentally model “search for whitespace in this set” as “return false at end of string.” That is not what strchr does when the searched character is '\0'. Searching for NUL in a C string succeeds at the terminator. The vulnerable loop increments the pointer and keeps walking beyond the intended input. (blog.calif.io)

The patch is not a redesign of FTP parsing. It is a boundary check:

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

The patch commit says the fix restricts parsing to the input buffer when a TypeA or TypeB listing date is not followed by a filename, and it also notes that strchr always returns a non-nil pointer when given a NUL character. (GitHub) That comment is unusually valuable because it explains both the bug and the class of future bugs maintainers should look for.

Why stale memory can become someone else’s secret

An out-of-bounds read does not automatically mean useful leakage. Attackers need the bytes beyond the intended buffer to contain something worth stealing. Squidbleed becomes dangerous because of memory reuse.

Calif’s analysis describes Squid maintaining per-size freelists on top of malloc. When a buffer is freed, it can be pushed to a freelist and reused later without being zeroed. The FTP listing parser’s line buffer is allocated from MEM_4K_BUF; if a 4KB buffer previously contained a victim’s HTTP request and a short FTP line overwrites only the beginning, much of the old request can remain in memory. When the parser walks past the NUL terminator and copies from beyond the intended FTP listing, it can return stale contents from that recycled buffer. (blog.calif.io)

This is the part that makes the “Heartbleed-style” label understandable. Heartbleed, CVE-2014-0160, allowed memory disclosure from vulnerable OpenSSL systems via a malformed heartbeat request and could expose sensitive memory such as private keys, passwords, or other secrets. (nvd.nist.gov) Squidbleed is not the same bug and does not have the same attack surface, but both cases show why a read-only memory safety flaw can still become an authentication and confidentiality incident.

For Squidbleed, the most plausible secrets are not private TLS keys in a normal forward proxy. They are request-level artifacts:

Possible leaked data	When it is realistic
Authorization: Basic ... cabeceras	Internal apps, legacy services, scripts, or administrative tools still using HTTP Basic over cleartext HTTP
Authorization: Bearer ... cabeceras	API clients sending tokens through a proxy over cleartext HTTP or through a TLS-terminating proxy
Session cookies	Internal web apps, lab systems, or misconfigured apps using HTTP rather than HTTPS
Proxy authentication material	Depends on deployment and request flow, but proxy credentials deserve review if cleartext proxy auth is used
Internal hostnames and paths	Even without credentials, leaked URLs can expose internal structure and endpoints
CSRF tokens or one-time links	Possible when users interact with internal apps over cleartext HTTP
API keys in URLs	Bad practice, but still common in legacy integrations and internal tools

The confidentiality impact is why the official GitHub advisory’s CVSS vector sets confidentiality impact to high while integrity and availability are none. (GitHub) Ubuntu’s notice also states that a remote attacker could cause a crash or possibly obtain sensitive information, but the practical risk is most urgent where sensitive cleartext traffic crosses the proxy. (Rápido7)

The real attack chain

A realistic CVE-2026-47729 attack chain looks like this:

1. The attacker has access to use the Squid proxy. This could mean a valid proxy account, access from a trusted network, or membership in a group allowed by Squid ACLs.
2. The attacker controls an FTP server or can influence a reachable FTP server to emit malformed directory listings.
3. The attacker sends ftp:// requests through Squid to that server.
4. The FTP server returns a listing line that triggers the parser edge case.
5. Squid’s FTP gateway parser reads past the end of the listing buffer.
6. Squid returns an HTML directory listing to the attacker, where the filename field may contain stale memory from unrelated Squid transactions.
7. The attacker repeats or sprays requests to increase the chance of recovering useful fragments.
8. If secrets are recovered, the attacker reuses them against internal apps, APIs, or user sessions.

The official advisory’s attacker model is narrow but important: a trusted client can read from random unrelated transactions when accessing a misbehaving FTP server through the gateway feature. (GitHub) Red Hat enrichment, surfaced through OpenCVE, states the attacker must have a valid account on the Squid proxy and must control an FTP server reachable from the proxy on port 21. (app.opencve.io)

That is not internet-wide unauthenticated exploitation. But many real proxy environments treat “authenticated proxy user” as a low bar. A university lab, shared office network, contractor VPN, guest network, or public transport Wi-Fi proxy may have many clients who are “trusted” only in the narrow ACL sense. In those environments, the phrase “trusted client” should not lull defenders into slow patching.

What HTTPS changes, and what it does not

The most common overstatement about Squidbleed is that it can steal all web traffic from every Squid user. That is not accurate.

In a normal forward-proxy configuration, HTTPS usually uses the CONNECT method. Squid sees the destination host and tunnel metadata, but it does not see the decrypted HTTP request headers or body. Calif’s write-up explicitly notes that most traffic is HTTPS and that Squid relays it as an opaque CONNECT tunnel, limiting exposure to cleartext HTTP and TLS-terminating setups. (blog.calif.io) Red Hat’s statement in OpenCVE likewise says HTTPS traffic handled via CONNECT tunnels is opaque to the proxy because the underlying request data is encrypted, while impact is limited to cleartext HTTP or TLS-terminating configurations where Squid decrypts and inspects traffic. (app.opencve.io)

That does not mean “ignore it because everyone uses HTTPS.” Many organizations still have pockets of cleartext HTTP:

Internal admin panels. Old appliances. Package mirrors. Build systems. Health checks. Monitoring endpoints. Developer tools. Metadata-style endpoints. Legacy APIs. Lab systems. Captive portal flows. Test environments that accidentally carry real credentials. Proxies that perform SSL bump for inspection. Corporate networks where TLS interception is deliberately enabled.

The best risk question is not “Do users browse HTTPS sites?” It is “Can sensitive request material ever land in Squid-managed buffers?” If yes, memory disclosure becomes credential exposure.

Affected versions and fixed packages

The official upstream advisory gives the most direct version guidance for source builds:

Source or platform	Vulnerable or fixed status checked
Upstream Squid older than 3.5.28	Not tested, should be assumed vulnerable
Squid 4.x	Vulnerable
Squid 5.x	Vulnerable
Squid 6.x	Vulnerable
Squid 7.x through 7.5	Vulnerable
Squid 7.6	Fijo
Debian trixie security	Fijado en 6.13-2+deb13u2
Debian forky	Fijado en 7.6-1
Debian sid	Fijado en 7.6-2
Ubuntu 22.04 LTS	Fijado en 5.9-0ubuntu0.22.04.7
Ubuntu 24.04 LTS	Fijado en 6.14-0ubuntu0.24.04.4
Ubuntu 25.10	Fijado en 6.14-0ubuntu0.25.10.4
Ubuntu 26.04 LTS	Fijado en 7.2-2ubuntu2.2
Amazon Linux 2 Core	Pending fix at time checked
Amazon Linux 2023	Pending fix at time checked

The upstream ranges and patched version come from the Squid GitHub advisory. (GitHub) Debian and Ubuntu package rows come from their security trackers. (security-tracker.debian.org) (Ubuntu) Amazon Linux rows come from the Amazon Linux Security Center page. (explore.alas.aws.amazon.com)

For production triage, do not reduce this to “7.6 good, everything else bad.” That is useful for source builds, but not enough for packaged systems. A patched Ubuntu 22.04 package will not report upstream Squid 7.6, yet Ubuntu lists it as fixed. A vendor appliance may report a custom version and require a vendor advisory. A container image may include an older package even when the host OS has been updated.

Use the vendor package state wherever possible.

Safe verification, without turning production into a leak test

CVE-2026-47729 is tempting to verify with public proof-of-concept code. Do not run memory-leak PoCs against a production shared proxy unless the environment is explicitly authorized, isolated, and populated only with synthetic data. A successful test may recover another user’s secrets. That turns validation into an incident.

A safe verification workflow should answer five questions:

1. Is Squid present?
2. Is the installed package fixed according to the vendor?
3. Is FTP gateway traffic allowed by configuration?
4. Can the Squid host reach FTP servers on TCP/21?
5. Has the proxy recently handled sensitive cleartext or TLS-inspected traffic?

Empiece por descubrir los activos:

# Find running Squid processes
ps aux | grep -i '[s]quid'

# Find listening proxy ports, commonly 3128, 8080, or custom ports
sudo ss -ltnp | grep -i squid

# Locate common configuration paths
sudo find /etc -maxdepth 3 -iname 'squid.conf' -o -iname 'squid*.conf'

Check version and package state:

# Upstream version and build options
squid -v

# Debian or Ubuntu package state
dpkg -l | awk '/^ii[[:space:]]+squid/ {print $2, $3}'

# RHEL, Fedora, Amazon Linux, or compatible systems
rpm -q squid

# Container image inspection, from the running container
docker exec <container> squid -v
docker exec <container> sh -c "cat /etc/os-release && (dpkg -l squid 2>/dev/null || rpm -q squid 2>/dev/null)"

Inspect FTP-related access rules. The exact ACL structure varies by environment, but the goal is to know whether ftp:// requests can pass through the proxy and whether deny rules appear before broad allow rules.

CONF=/etc/squid/squid.conf

# Show FTP, port, and access-control related lines
sudo grep -nE '^[[:space:]]*(acl|http_access|http_port|https_port|ssl_bump|cache_peer|visible_hostname)' "$CONF" \
  | sed -n '1,220p'

# Look for explicit FTP protocol ACLs
sudo grep -niE 'proto[[:space:]]+FTP|ftp://|Safe_ports|port[[:space:]]+21' "$CONF"

Check whether Squid is making or has made FTP gateway requests:

# Default access.log URL field is commonly the seventh field in Squid native log format
sudo awk '$7 ~ /^ftp:\/\// {print}' /var/log/squid/access.log | tail -50

# Count FTP gateway activity by client and destination URL
sudo awk '$7 ~ /^ftp:\/\// {count[$3" "$7]++} END {for (k in count) print count[k], k}' \
  /var/log/squid/access.log | sort -nr | head -50

Look for outbound FTP reachability from the proxy host. This should be done carefully and against approved test destinations only.

# Show recent connections to TCP/21 if available
sudo ss -tnp | awk '$4 ~ /:21$/ || $5 ~ /:21$/ {print}'

# Review firewall rules for outbound FTP permissions
sudo nft list ruleset | grep -iE 'dport 21|ftp' || true
sudo iptables -S | grep -iE 'dport 21|ftp' || true

If you need exploitability proof, build a lab that mirrors the production Squid version and configuration but contains only synthetic traffic. Put a controlled “victim” HTTP request with a fake token through the proxy, trigger the FTP parser behavior against an attacker-controlled FTP server, and confirm whether only the fake token can be recovered. Do not use real user traffic, real credentials, production proxy logs, or a production shared proxy for this test.

For teams running repeated CVE validation across many assets, the work should be treated as an evidence workflow rather than a one-off script. The useful output is not “scanner says vulnerable.” It is a chain of evidence: asset identity, package source, configuration proof, FTP reachability, sensitive-traffic exposure, mitigation applied, and retest result. Penligent’s public site describes an AI-powered penetration testing workflow focused on finding, verifying, executing authorized tests, and producing reports, while its article on using AI for pentesting emphasizes scope, evidence, control, CVE validation discipline, and false-positive handling. (Penligente) (Penligente)

How to decide priority

A moderate CVSS score can hide urgent local context. CVE-2026-47729 has a 6.5 score in the official GitHub advisory, but the score assumes low privileges because the attacker needs to be a trusted client. (GitHub) In a tightly controlled proxy with a handful of administrators, that requirement is meaningful. In a shared proxy with thousands of users, it is less reassuring.

Use a local risk decision table:

Medio ambiente	Suggested priority	Reason
Shared enterprise proxy with FTP allowed and SSL bump enabled	Emergency or high	Attacker may recover decrypted request material from other users
School, lab, hotel, transport, or guest network proxy with FTP allowed	Alta	Many “trusted” clients share one proxy boundary
Internal proxy with cleartext HTTP to admin apps or APIs	Alta	Tokens and Basic auth headers may be exposed
Proxy with outbound TCP/21 blocked and no FTP gateway use	Medio	Patch still required, but vulnerable path may be unreachable
Single-user Squid instance with no cleartext secrets and FTP denied	Baja	Limited cross-user impact, but update remains necessary
Appliance or container with unknown vendor state	Medium to high until proven otherwise	Version and backport status may be unclear

This vulnerability is especially important for networks where Squid is treated as plumbing and rarely revisited. Old proxy rules often survive because nobody wants to break legacy traffic. Squidbleed is a reason to ask whether FTP gateway support is still needed at all.

Immediate mitigation

The best fix is to apply a vendor-provided update. If you build Squid from source, move to a fixed upstream version or apply the official patch for your branch. If you use Debian, Ubuntu, Red Hat, Amazon Linux, a firewall appliance, a container image, or a managed distribution, use the vendor advisory rather than cherry-picking blindly.

If you cannot patch immediately, disable FTP gateway access. The official Squid advisory recommends placing FTP deny rules above any custom http_access allow lines in squid.conf. (GitHub) A conservative deny-all workaround looks like this:

# Place before broad http_access allow rules
acl FTP proto FTP
http_access deny FTP

If the organization has a real business requirement for FTP through Squid, allowlist specific trusted destinations and deny everything else. The official advisory gives an allowlist pattern using an FTP ACL and a trusted server URL regex. (GitHub) A stricter example may look like this:

# Place before broad http_access allow rules
acl FTP proto FTP
acl ftp_allowlist url_regex ^ftp://trusted\.server\.example\.com
http_access deny FTP !ftp_allowlist

Red Hat’s enrichment, shown through OpenCVE, gives a similar mitigation: block FTP traffic when it is not required, or allow only specific trusted destination domains when FTP must remain available. (app.opencve.io)

After changing Squid configuration, reload or restart safely:

# Validate configuration syntax first
sudo squid -k parse

# Reload configuration without a full restart where supported
sudo squid -k reconfigure

# Or use systemd where appropriate
sudo systemctl reload squid || sudo systemctl restart squid

Then verify that FTP gateway requests are denied:

# Use an approved internal test URL only
curl -x http://127.0.0.1:3128 ftp://trusted-test.example.invalid/ -I

The exact response depends on your Squid error pages and ACLs, but the request should not be forwarded to arbitrary FTP destinations after the deny rule is in place.

Network-layer controls are also useful. Even if Squid configuration is accidentally weakened later, an egress firewall can prevent the proxy host from reaching arbitrary FTP servers.

# Example nftables pattern, adapt to local policy and service account
# This is illustrative. Test in staging before applying to production.
sudo nft add rule inet filter output tcp dport 21 reject

Do not rely only on a firewall if business logic still allows FTP in Squid. Defense in depth is strongest when Squid ACLs and network egress policy agree.

Detection and investigation

Detection for CVE-2026-47729 should focus on FTP gateway activity, abnormal use by authorized proxy clients, and possible exposure of secrets that crossed the proxy. There may not be a clean “exploit signature” in every environment. A successful leak can look like a client requesting an FTP directory listing.

Useful signals include:

Señal	Por qué es importante	Common false positives	Acción
ftp:// URLs in Squid access logs	Indicates the vulnerable code path may be reachable	Legacy software repositories, old automation, user mistakes	Identify client, destination, frequency, and business owner
Repeated FTP requests from one client	May indicate probing or spraying for useful memory reuse	Broken automation or retry loops	Correlate with destination domains and proxy auth identity
Squid host outbound TCP/21	Confirms FTP reachability beyond configuration theory	Approved legacy FTP transfers	Restrict to allowlist or block
Unknown FTP domains resolved by Squid host	May indicate attacker-controlled infrastructure	Legitimate vendor FTP servers	Enrich with domain age, ownership, and client identity
Squid crashes during FTP activity	Possible malformed input or unrelated bug	Operational instability, old Squid bugs	Preserve logs, core dumps, and package state
Cleartext HTTP requests with credentials	Defines what could have leaked	Internal legacy apps	Rotate secrets and migrate to HTTPS
SSL bump enabled	Squid may have decrypted sensitive traffic	Intended enterprise inspection	Scope which users and destinations could be exposed

Start with the access log:

LOG=/var/log/squid/access.log

# Recent FTP gateway requests
sudo awk '$7 ~ /^ftp:\/\// {print}' "$LOG" | tail -100

# Top clients using FTP gateway
sudo awk '$7 ~ /^ftp:\/\// {count[$3]++} END {for (c in count) print count[c], c}' "$LOG" \
  | sort -nr | head -20

# Top FTP destinations
sudo awk '$7 ~ /^ftp:\/\// {print $7}' "$LOG" \
  | sed -E 's#^(ftp://[^/]+)/?.*#\1#' \
  | sort | uniq -c | sort -nr | head -20

If your Squid deployment uses authentication, correlate client IPs with proxy usernames. If logs are forwarded to a SIEM, build a query for url starts_with "ftp://" donde process.name = squid o service = proxy.

For network telemetry, look for the Squid host initiating FTP control connections:

# If Zeek logs are available
zcat -f /opt/zeek/logs/*/conn.log* 2>/dev/null \
  | awk '$3 ~ /<squid_proxy_ip>/ && $6 == 21 {print}' | tail -50

# If firewall logs include destination port
grep -E 'squid|proxy' /var/log/syslog | grep -E 'DPT=21|dport 21' | tail -50

If there is evidence that untrusted users accessed attacker-controlled FTP servers through a vulnerable shared proxy, treat it as a potential credential exposure event. The right response may include rotating Basic auth passwords, bearer tokens, API keys, session cookies, and internal service credentials that crossed the proxy over cleartext HTTP or through TLS interception during the exposure window.

Remediation checklist

Use this checklist to move from “we know about Squidbleed” to “we have reduced and verified risk.”

Paso	Evidence to collect
Inventory all Squid instances	Hostname, IP, owner, environment, package source, container image, appliance version
Check package status	Vendor advisory match, package version, update timestamp
Confirm FTP gateway exposure	squid.conf ACLs, http_access order, Safe_ports, outbound TCP/21 policy
Check shared-client risk	Proxy auth scope, network ACLs, number of users or systems allowed
Check sensitive traffic	Cleartext HTTP, internal apps, TLS bump, proxy auth, API clients
Apply update	Package manager logs, change ticket, new package version
Apply workaround if needed	acl FTP proto FTP and deny or allowlist rules before broad allow rules
Block egress FTP where possible	Firewall rule, cloud security group, network ACL, proxy host policy
Retest safely	FTP requests denied or fixed package confirmed, no production memory-leak PoC
Rotate exposed secrets if needed	Token inventory, affected app owners, revocation logs
Preserve evidence	Before/after config, logs, patch proof, retest result, residual risk

The official advisory says prepackaged Squid users should refer to their package vendor for availability of updated packages. (GitHub) That advice is not boilerplate. It prevents a common mistake: compiling upstream Squid manually on a managed distribution, accidentally replacing vendor hardening or operational integration, and creating a maintenance problem.

Related CVEs that change how defenders should think

CVE-2026-47729 should not be handled as an isolated bug in an obscure FTP corner. It belongs to a larger pattern: proxy features that rarely receive attention can still process attacker-controlled input and share memory, trust, cache, or authentication boundaries.

CVE	Why it is relevant	Clase práctica
CVE-2026-50012	Disclosed in the same Squid security batch, this cache digest issue is a heap-based buffer overflow triggered by malicious cache digest replies when the feature is compiled in or used. (seclists.org)	Review rarely used Squid features together, not one CVE at a time
CVE-2019-12528	An earlier Squid FTP gateway information disclosure issue allowed a crafted FTP server to disclose sensitive heap memory before Squid 4.10. (nvd.nist.gov)	FTP gateway has historical information-disclosure risk and should be disabled if unnecessary
CVE-2014-0160	Heartbleed showed that memory over-read bugs can expose secrets even without code execution. (nvd.nist.gov)	Confidentiality-only memory bugs can still become account takeover or key exposure incidents

CVE-2026-50012 is especially important because it was announced alongside CVE-2026-47729 on oss-security. The same post described CVE-2026-50012 as an improper input validation bug leading to heap-based buffer overflow in cache digests, triggered by malicious replies to cache_digest request messages. (seclists.org) Even if your immediate concern is Squidbleed, patching should cover the whole advisory set for your distribution.

CVE-2019-12528 matters because it involved Squid’s FTP gateway and sensitive heap memory disclosure years before Squidbleed. NVD’s description states that Squid before 4.10 allowed a crafted FTP server to trigger disclosure of sensitive heap memory, including information associated with other users’ sessions or non-Squid processes. (nvd.nist.gov) That history strengthens the case for removing FTP gateway exposure rather than repeatedly accepting it as harmless legacy support.

Heartbleed matters as a mental model, but not as a severity copy-paste. Heartbleed could be exploited remotely against vulnerable OpenSSL endpoints and had a huge internet-facing footprint. Squidbleed requires a trusted proxy client and FTP gateway reachability. The shared lesson is that read-past-buffer bugs can leak authentication material. The operational severity depends on where that memory lives and what secrets pass through it.

Common mistakes during CVE-2026-47729 response

The first mistake is treating CVE-2026-47729 as a pure version problem. Version matters, but configuration and traffic matter too. A vulnerable build with FTP denied and outbound TCP/21 blocked is not the same as a vulnerable shared proxy that lets hundreds of users reach arbitrary FTP servers.

The second mistake is dismissing the bug because FTP is old. FTP may be old, but old protocols often survive in the exact places security teams do not inspect frequently: vendor update scripts, embedded devices, lab networks, legacy mirrors, and internal automation.

The third mistake is assuming HTTPS eliminates risk. HTTPS CONNECT limits what Squid can read in ordinary forward-proxy mode. It does not protect cleartext HTTP, TLS-inspected traffic, internal HTTP apps, or credentials already exposed to the proxy.

The fourth mistake is running a public PoC against production. A proof-of-concept that works by leaking memory can leak real user data. Safe validation belongs in a lab or tightly scoped environment with synthetic traffic.

The fifth mistake is patching Squid without investigating whether secrets may have been exposed. If logs show suspicious FTP gateway activity during the vulnerable window, credential rotation may be required. The right scope depends on what kinds of traffic crossed the proxy.

The sixth mistake is adding a deny rule below a broad allow rule. Squid ACL order matters. The official workaround says to place FTP deny settings above custom http_access allow lines. (GitHub)

A practical response plan for security teams

A good response plan is short enough to execute and detailed enough to audit.

First, inventory every Squid instance, including containers, appliances, development proxies, CI/CD network proxies, package mirror proxies, and old hosts not covered by central vulnerability management. Squid often appears as infrastructure plumbing rather than as a product team-owned service.

Second, classify each instance by shared-client exposure. A proxy used by many clients is more sensitive than a local one-user proxy. A proxy reachable from a guest network is more sensitive than one reachable only by a small operations subnet.

Third, check vendor package state. Use Debian, Ubuntu, Red Hat, Amazon Linux, appliance, or container vendor advisories. Avoid assuming upstream version numbers are enough.

Fourth, disable FTP gateway access unless there is a documented business need. If FTP is required, allow only approved destinations and block all other FTP. Put the deny logic before broad allow rules.

Fifth, block outbound TCP/21 from the Squid host where possible. This reduces the blast radius of future FTP parser bugs too.

Sixth, review logs for FTP gateway use during the exposure window. Identify clients, destinations, timestamps, and whether activity looks like normal business use or probing.

Seventh, assess secret exposure. Look for cleartext HTTP, TLS interception, Basic auth, bearer tokens, API keys, and internal applications that may have crossed the proxy.

Eighth, rotate secrets when suspicious activity and sensitive traffic overlap. Do not rotate every credential in the company by default, but do not ignore clear exposure evidence.

Ninth, document the evidence. A useful remediation record includes package status, configuration state, FTP log review, egress control, retest output, and any credential actions.

Useful source notes for deeper reading

The official Squid GitHub advisory is the primary source for affected versions, patched version, workaround, CVSS vector, credits, and revision history. (GitHub)

The oss-security announcement and follow-up thread are useful for understanding disclosure timing and the brief confusion around whether the fix should be treated as 7.6 or 7.7. (seclists.org) (seclists.org)

Calif’s technical analysis is the clearest public explanation of the strchr edge case, the NetWare FTP parsing history, the 4KB buffer reuse behavior, and the practical leak demonstration. (blog.calif.io)

Debian and Ubuntu trackers are necessary for package-level remediation on those distributions because their fixed versions may be backported and not match upstream Squid 7.6. (security-tracker.debian.org) (Ubuntu)

PREGUNTAS FRECUENTES

Is CVE-2026-47729 remotely exploitable?

• Yes, but not in the same sense as an unauthenticated internet-facing RCE.
• The attacker must be allowed to use the Squid proxy as a trusted client.
• The attacker also needs Squid to reach a misbehaving or attacker-controlled FTP server through the FTP gateway.
• Shared proxy environments make the “trusted client” requirement less comforting because many users may be trusted by ACL but not trusted with each other’s memory.

Does Squidbleed expose HTTPS traffic?

• Ordinary HTTPS CONNECT traffic is usually opaque to Squid, so decrypted headers and cookies are not normally available to the proxy.
• Cleartext HTTP traffic is more exposed because Squid can process the request contents.
• TLS termination, SSL bump, or other interception configurations can increase impact because Squid may see decrypted traffic.
• Internal HTTP apps, API clients, and legacy services are often the highest-risk sources of useful leaked secrets.

Which Squid versions are affected?

• The official Squid advisory says Squid older than 3.5.28 has not been tested and should be assumed vulnerable.
• It lists all Squid 4.x, 5.x, and 6.x as vulnerable.
• It lists Squid 7.x through 7.5 as vulnerable.
• It lists Squid 7.6 as the patched upstream version.
• For Linux distributions, use vendor package advisories because fixes may be backported into older-looking package versions.

Is Squid 7.6 or 7.7 the fixed version?

• The official GitHub advisory lists patched version 7.6.
• A later oss-security thread discussed confusion around 7.6 versus 7.7, and the follow-up notes that the advisory lists versions before 7.6 as affected.
• For source builds, treat Squid 7.6 or later as the upstream fixed line unless the Squid project updates its advisory.
• For packaged systems, follow the distribution’s fixed package version rather than only the upstream number.

How can I safely check whether my Squid proxy is at risk?

• Identify all Squid instances and their package sources.
• Check whether each package is fixed according to the operating system or appliance vendor.
• Review squid.conf to see whether FTP gateway requests are allowed.
• Search access logs for ftp:// URLs and repeated FTP gateway activity.
• Check whether the Squid host can make outbound TCP/21 connections.
• Avoid running memory-leak PoCs on production shared proxies.

What should I do if I cannot patch immediately?

• Deny FTP gateway traffic in squid.conf.
• Place the deny rule before broad http_access allow rules.
• If FTP is required, allowlist only specific trusted FTP destinations.
• Block outbound TCP/21 from the Squid host where operationally feasible.
• Monitor logs for attempted FTP gateway use.
• Plan a vendor-supported package update as soon as possible.

Is CVE-2026-47729 being actively exploited?

• OpenCVE’s current enrichment lists KEV as “No” and says no EPSS score is available.
• Public reporting checked during writing did not establish confirmed in-the-wild exploitation.
• Public PoC material and technical detail increase the need for timely remediation even without confirmed exploitation.
• Organizations with shared proxies, FTP enabled, or TLS-inspecting Squid deployments should not wait for KEV status before acting.

Closing judgment

CVE-2026-47729 is serious because it crosses trust boundaries inside a proxy, not because every Squid instance is equally exposed. The bug requires an authorized proxy client and FTP gateway reachability, but those conditions are common enough in legacy networks to matter. The highest-risk cases are shared proxies that allow outbound FTP and have recently processed cleartext HTTP, internal credentials, or TLS-inspected traffic.

The best response is direct: update Squid through the vendor-supported path, disable FTP gateway traffic if it is not required, restrict outbound FTP, review logs for suspicious ftp:// activity, and rotate secrets if sensitive cleartext traffic may have overlapped with exploit attempts. Squidbleed is also a reminder that old protocol support is not passive. If a parser still accepts attacker-shaped input, it is part of the attack surface.