squid DSA-6606-1: Patch 3 CVEs on Debian 13

pajus 2026-11-04 13 min read

Debian published squid DSA-6606-1 on 2026-11-03. It fixes CVE-2026-61642, CVE-2026-62846 and CVE-2026-104786 in Debian 13 (trixie), and the fixed package is 6.13-2+deb13u4. The advisory's description is two sentences long and does not tell you whether your proxy configuration is exposed. This checklist covers that, plus how to prove the running process is the patched one.

What happened in squid DSA-6606-1

The DSA describes the issues as request smuggling, buffer overflows and FTP command injection "under certain conditions". The conditions differ per CVE, and the public detail differs too:

CVE	Upstream ID	Type	CVSS	Upstream fix
CVE-2026-61642	SQUID-2026:6	Request smuggling via bare `Transfer-Encoding: identity`	7.7 High (CVSS 3.1, Squid advisory and CVE record)	7.6
CVE-2026-104786	SQUID-2026:7	Stack buffer overflow in HTTP authentication	5.4 Moderate (CVSS 3.1, Squid advisory)	7.7
CVE-2026-62846	SQUID-2026:9	FTP command injection in FTP gateway (SQUID-2026:9)	None found. Ubuntu rates its own priority as medium	7.7

The CVE record for CVE-2026-61642 was published on 2026-10-13. The Debian changelog for the fixed package is dated 2026-10-30, and the upload was accepted into stable-security on 2026-11-03.

The upload contains more than the DSA lists. The changelog also fixes SQUID-2026:8, a low-severity (CVSS 3.4) stack overflow in ICAP authentication with no CVE ID, and adds a follow-up patch for the ICAP X-Client-Username encoder.

CVE-2026-62846 needs some explaining, because its paper trail is scattered. Upstream posted SQUID-2026:9 to squid-announce on 2026-09-12; the advisory itself is dated 2026-07-05. It says a trusted client can inject commands when accessing an ftp:// URL and reach files, directories and FTP server features that Squid's policy forbids. Affected versions include 5.x through 5.9, 6.x through 6.14 and 7.x through 7.6, and the fix is in 7.7. The post carries no CVE ID, so the link to CVE-2026-62846 comes from the Debian tracker and the patch commit: Debian's patch file is named after upstream commit 523ed3b0, the same commit the advisory links, which makes Squid refuse to send FTP commands containing embedded CR or LF characters. Debian's tracker and Ubuntu's notes (from 2026-10-22) still say the SQUID-2026:9 information is not public, but the announcement shows otherwise.

Who is affected

Versions below are from the Debian security tracker. The Squid advisories list all 6.x releases through 6.14 as vulnerable to CVE-2026-61642 and CVE-2026-104786, so Debian 13's 6.13 is in scope.

Release	Package version	Status
bookworm	5.7-2+deb12u5	Vulnerable
bookworm (security)	5.7-2+deb12u6	Vulnerable
trixie	6.13-2+deb13u3	Vulnerable
trixie (security)	6.13-2+deb13u4	Fixed
forky	7.7-1	Fixed
sid	7.8-1	Fixed

Debian backported the fixes to 6.13, so the upstream version number will not change. A scanner comparing "6.13" against "fixed in 7.6" may still flag a patched host. Judge by the full Debian package version.

How to check your systems

Package and version

Debian has two flavours: squid (GnuTLS) and squid-openssl. Both are at 6.13-2+deb13u4 in trixie-security. Run the following as root, here and in later sections, because ss -p needs privileges to show process names:

dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'squid*'
apt-cache policy squid

Listening ports and proxy modes

ss -tlnp | grep squid
squid -k parse 2>&1 | grep -E 'Processing: *(http_port|https_port|ftp_port|cache_peer|icap_service)'

squid -k parse checks the configuration without signalling the running daemon. Its output includes files pulled in from /etc/squid/conf.d/, so it beats grepping squid.conf alone.

On each http_port line, the mode tells you what kind of proxy you run: no mode flag is a forward proxy, accel is a reverse proxy, and intercept or tproxy is transparent. An address such as 127.0.0.1:3128 binds only to that address. A bare http_port 3128 is not limited to one address, so access control then depends on your ACLs and firewall.

Which CVE matters for which setup

This mapping is my reading of the advisories and the fix commits, not an upstream statement. The CVE-2026-62846 column follows the scope of SQUID-2026:9: the FTP gateway and ftp:// URLs requested by a trusted client.

Setup	CVE-2026-61642	CVE-2026-104786	CVE-2026-62846
Forward proxy	Yes. Requires a client allowed to use the proxy. Worst when a filter or cache sits between clients and Squid	Only with a matching `cache_peer` login, for example chaining to a parent proxy	Yes, if a trusted client can get an `ftp://` request through `http_access`
Reverse proxy (`accel`)	Yes. Top priority if another HTTP cache sits in front, since upstream names cache poisoning as an impact	Only with a matching `cache_peer` login, such as an `originserver` peer	Only if a trusted client can get an `ftp://` request through `http_access`. Check your rules
Transparent (`intercept`, `tproxy`)	Assume yes. The fix is in the shared header parser	Do not assume safety. Authentication is off on these ports, but `login=PASS` can forward client details or external ACL tags	Same test: in scope if a trusted client can get an `ftp://` request through `http_access`

Upstream's advisory gives this test for CVE-2026-104786, and it prints the cache_peer lines it considers in scope:

squid -k parse 2>&1 | grep -E "cache_peer.*login=(\*:|PASS)" || echo "not vulnerable"

The pattern misses the undocumented login=PROXYPASS, which in the 6.13 code can reach the same base64 encoding with external ACL credentials and gets a length check in the fix commit. So check for that value as well, even if the test above prints "not vulnerable". The pattern also matches login=PASSTHRU, which returns before any encoding, so that line is a false positive.

squid -k parse 2>&1 | grep 'login=PROXYPASS'

SQUID-2026:8 requires an ICAP service plus a misbehaving external ACL helper, so it only applies if you use icap_service together with such a helper.

FTP gateway and FTP relay

Squid has two FTP paths. The native relay is ftp_port, which is off unless configured. The gateway handles ftp:// URLs sent through a normal proxy port and has no such switch: the recommended Safe_ports list includes port 21, so FTP passes unless you block it.

The advisory only names the gateway. The fix sits in the shared Ftp::Client::writeCommand, so I would also treat a configured ftp_port as possibly affected, but that is my inference from the commit, not an upstream statement.

squid -k parse 2>&1 | grep -E 'Processing: *(ftp_port|acl .* proto )'
zgrep -hE ' ftp://' /var/log/squid/access.log* | tail -n 20

Debian's logrotate runs daily and keeps only 2 rotated copies, so this search covers only about 3 days by default. An empty result is weak evidence unless you extended retention: a weekly or monthly FTP job may simply not have run in that window.

Is the proxy open to the internet?

Only test a proxy you own or are authorised to test. Run this from a host outside your network, which is the only view that counts. Replace the example address and adjust the port:

proxy=203.0.113.10
curl -sS -o /dev/null -w '%{http_code}\n' -x "http://${proxy}:3128" http://example.com/
curl -sS -o /dev/null -w '%{http_connect}\n' -x "http://${proxy}:3128" https://example.com/

A 200 from either command means that source address can use your proxy, and you should fix that now. A 403 means Squid answered but its ACLs refused, which is acceptable but still leaves the port reachable. A 407 means Squid is reachable and asks for credentials, so anonymous use is refused but the port is still exposed. A connection error or timeout usually means the firewall dropped it. On the proxy, the refusal shows as TCP_DENIED:

grep -h 'TCP_DENIED' /var/log/squid/*.log | tail -n 5

Then review the rules in order:

squid -k parse 2>&1 | grep -E 'Processing: *(acl|http_access) '

Look for these problems:

http_access allow all, or a src ACL covering far more than your clients.
A rule list that does not end in http_access deny all. When no line matches, Squid applies the opposite of the last line, so a list ending in a narrow deny allows everything else.
A missing http_access deny to_localhost or http_access deny to_linklocal once external clients are allowed. The Squid docs call these important for protecting local web apps and cloud metadata addresses.

Debian's /etc/squid/conf.d/debian.conf states that new installs only allow localhost, with http_access allow localnet commented out. Upgraded or hand-edited hosts may differ. If the port should not be public, enforce that in the firewall as well, as in this nftables default-drop setup for Debian 13.

Patch squid on Debian 13 and verify the binary

Warning: the upgrade itself normally restarts the service and interrupts active proxy connections, so schedule it if users depend on this proxy. debian/rules uses plain dh at debhelper compat 13 with no dh_installsystemd override, and that tool restarts services on upgrade by default. I inferred this from the packaging and did not read the built package's maintainer script. Check the configuration before upgrading, and continue only if the parse is clean:

squid -k parse

apt-get update
apt-get install --only-upgrade squid squid-openssl
squid -k parse && systemctl restart squid

With --only-upgrade, apt skips whichever flavour is not installed. The explicit restart interrupts connections once more, but it makes sure the process was started from the new binary whatever the package scripts did, and the /proc check below confirms it. Do not use systemctl reload squid here: the unit's ExecReload only sends SIGHUP to the running process, which does not start the new binary.

On Debian, /usr/sbin/squid is an update-alternatives link to squid-gnutls or squid-openssl, with OpenSSL at the higher priority. So first find out which binary is real and which package owns it:

readlink -f /usr/sbin/squid
dpkg -S "$(readlink -f /usr/sbin/squid)"
dpkg-query -W -f='${Package} ${Version}\n' squid squid-openssl

Next, check what is actually running. squid -v prints version and build details, but the upstream version stays 6.13 after the backport, so use /proc instead:

pid=$(systemctl show -p MainPID --value squid)
readlink "/proc/${pid}/exe"
cg=$(systemctl show -p ControlGroup --value squid)
while read -r p; do readlink "/proc/${p}/exe"; done < "/sys/fs/cgroup${cg}/cgroup.procs" | sort | uniq -c
systemctl show -p ActiveEnterTimestamp --value squid
grep -E ' (upgrade|status installed) squid' /var/log/dpkg.log

The loop covers the main process, its workers and any helpers in the service's control group. If the old file was replaced while a process kept running, the kernel appends a suffix to the link target, and that is the result you do not want:

/usr/sbin/squid-gnutls (deleted)

Any (deleted) entry means restart again and find out what survived. The service start time should also be later than the upgrade time in dpkg.log. For a second opinion, checkrestart from debian-goodies lists processes still using deleted files. This is the same restart problem as in the OpenSSL DSA-6531-1 update.

You can also send the header that is now prohibited through a proxy you own. The upstream commit drops support for the bare form and removes the code that silently deleted the header, so it now reaches the unsupported-encoding path. In the upstream code, that path sets the unsupported-TE flag and Squid answers 501 Not Implemented. The WARNING line from the same path reaches cache.log at default settings only if relaxed_header_parser is off or debug_options raises section 55 to level 2, so its absence proves nothing. The 501 is inferred from the upstream code and not tested on the Debian build, so treat a normal 200 as a reason to investigate, not as proof either way:

curl -sS -o /dev/null -w '%{http_code}\n' -x http://127.0.0.1:3128 -H 'Transfer-Encoding: identity' http://example.com/

After the fix, FTP commands with embedded CR or LF characters are refused. Upstream says these transactions usually return HTTP 502 ERR_FTP_FAILURE and are logged as TCP_MISS_ABORTED, so look there if a legacy FTP client breaks after patching.

Mitigations if you cannot patch yet

This applies mainly to bookworm, which the tracker still shows as vulnerable. Upstream lists no workaround for CVE-2026-61642, so limit who can reach the proxy.

For CVE-2026-62846, upstream's SQUID-2026:9 workaround disables the FTP gateway. Add these lines before any http_access allow lines, including http_access allow localhost if local clients use the proxy, and remove the acl Safe_ports port 21 line from squid.conf. Removing any ftp_port lines you do not need is my addition, not part of the advisory:

acl FTP proto FTP
http_access deny FTP

For CVE-2026-104786, upstream suggests using a different authentication method on the cache_peer, such as a src-type ACL, or blocking long usernames. The advisory's example defines long_username but then references long_username_check, which looks like a typo. This version uses one name; test it first, because it only makes sense where proxy authentication is in use. Place it above the http_access allow lines for authenticated users; it needs a configured auth_param scheme:

acl long_username proxy_auth_regex ^.{100,}$
http_access deny long_username

Run squid -k parse after any change. A reload is enough for config changes, unlike the binary update.

What to watch next

Track the Debian security tracker entries for CVE-2026-61642, CVE-2026-62846 and CVE-2026-104786, especially the bookworm status if you still run it.
Use the squid-announce post as the reference for SQUID-2026:9. The first page of the GitHub advisories list did not show it when I checked on 2026-11-04.
NVD's API returned no record for CVE-2026-62846 or CVE-2026-104786 when I checked on 2026-11-04, so a scanner fed from NVD may lag behind Debian.

Takeaways

Confirm 6.13-2+deb13u4 with dpkg-query, not squid -v.
Restart rather than reload, then confirm no /proc/PID/exe link shows (deleted).
Run the upstream cache_peer grep and note any accel, intercept, tproxy and ftp_port lines.
Block ftp:// if nobody needs it, but do not rely on Debian's default log retention alone to prove that.
Test from outside the network that the proxy returns neither a 200 nor an open port to strangers, and end the rules with http_access deny all.