Squid is a caching proxy for the Web. Prior to 7.6, due to an improper input validation bug in cache digest reply handling (peerDigestSwapInMask in src/peerdigest.cc), Squid is vulnerable to a heap-based buffer overflow: a cache digest's on-the-wire size may be larger than the masksize declared within the digest, so a trusted peer sending a maliciously crafted reply to a cachedigest request message can trigger the overflow. This attack is limited to Squid instances compiled with the --enable-cache-digests option and configured with cachepeer entries. This issue is fixed in version 7.6.

Squid is a caching proxy for the Web. Prior to 7.6, due to an improper validation of syntactic correctness of input in the FTP gateway (src/clients/FtpGateway.cc), Squid is vulnerable to an out-of-bounds read: when a listing entry date in the TypeA or TypeB directory-listing formats is not followed by a filename, parsing was not restricted to the input buffer, so a trusted client accessing a misbehaving FTP server through Squid's gateway feature could read memory from random unrelated transactions. This issue is fixed in version 7.6.

Squid is a caching proxy for the Web. Prior to version 7.5, due to heap Use-After-Free, Squid is vulnerable to Denial of Service when handling ICP traffic. This problem allows a remote attacker to perform a reliable and repeatable Denial of Service attack against the Squid service using ICP protocol. This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero icpport). This problem cannot be mitigated by denying ICP queries using icpaccess rules. Version 7.5 contains a patch.

Squid has Denial of Service in ICP Response handling

Am 24.06.2026 um 11:38 schrieb Christian Fischer: Hello,

On 6/22/26 8:35 AM, Salvatore Bonaccorso wrote: Hi Amos,

On Mon, Jun 15, 2026 at 11:26:10PM +1200, Amos Jeffries wrote: On 12/06/2026 20:21, Amos Jeffries wrote: Hi all,

Squid 7.6 release contains fixes for and releases the embargo on CVE-2026-47729 and CVE-2026-50012.

actually be in Squid 7.7. CVE-2026-47729

Due to a Improper Validation of Syntactic Correctness of Input bug, Squid is vulnerable to a Out-of-bounds Read attack against the FTP gateway.

This problem allows a trusted client to perform an Out-of-Bounds Read from random unrelated transactions when accessing a misbehaving FTP server through Squid's gateway feature.

<https://github.com/squid-cache/squid/ commit/865a131c7d557e68c965043d98c2eccae26deef8.patch> I'm slightly confused about this. The referenced fix is in 7.6. Can you point us to the correct fix in 7.7 for CVE-2026-47729?

At least matches as well the followup from Alan. Official advisories for both CVEs seems to be available now:

I think >= 7.6 would be correct.

Hi Amos,

On Mon, Jun 15, 2026 at 11:26:10PM +1200, Amos Jeffries wrote: On 12/06/2026 20:21, Amos Jeffries wrote: Hi all,

Squid 7.6 release contains fixes for and releases the embargo on CVE-2026-47729 and CVE-2026-50012. Apologies, this first one (CVE-2026-47729) embargo is over, but the fix will actually be in Squid 7.7. CVE-2026-47729

Due to a Improper Validation of Syntactic Correctness of Input bug, Squid is vulnerable to a Out-of-bounds Read attack against the FTP gateway.

This problem allows a trusted client to perform an Out-of-Bounds Read from random unrelated transactions when accessing a misbehaving FTP server through Squid's gateway feature.

<https://github.com/squid-cache/squid/ commit/865a131c7d557e68c965043d98c2eccae26deef8.patch> I'm slightly confused about this. The referenced fix is in 7.6. Can you point us to the correct fix in 7.7 for CVE-2026-47729?

At least https://github.com/squid-cache/squid/commit/865a131c7d557e68c965043d98c2eccae26deef8 matches as well the followup from Alan.

Regards, Salvatore

On 6/15/26 04:26, Amos Jeffries wrote: On 12/06/2026 20:21, Amos Jeffries wrote: Hi all,

A blog was posted about it today: https://blog.calif.io/p/squidbleed-cve-2026-47729

It says the root cause was a misunderstanding of what the C standard requires: strchr(wspace, '\0') returns non-NULL per C11 §7.24.5.2 (terminating NUL -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

A denial of service flaw was found in the way squid handles certain client initiated requests. A client who can connect to the squid server could leverage this flaw to cause the squid child process to terminate. This would prevent anyone from using the squid server until the process automatically restarts.

Opera 6.0.3, when using Squid 2.4 for HTTPS proxying, does not properly handle when accepting a non-global certificate authority (CA) certificate from a site and establishing a subsequent HTTPS connection, which allows remote attackers to cause a denial of service (crash).

Squid is a caching proxy for the Web. Prior to version 7.5, due to premature release of resource during expected lifetime and heap Use-After-Free bugs, Squid is vulnerable to Denial of Service when handling ICP traffic. This problem allows a remote attacker to perform a reliable and repeatable Denial of Service attack against the Squid service using ICP protocol. This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero icpport). This problem cannot be mitigated by denying ICP queries using icpaccess rules. This bug is fixed in Squid version 7.5.

Squid is a caching proxy for the Web. Prior to version 7.5, due to heap Use-After-Free, Squid is vulnerable to Denial of Service when handling ICP traffic. This problem allows a remote attacker to perform a reliable and repeatable Denial of Service attack against the Squid service using ICP protocol. This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero icpport). This problem cannot be mitigated by denying ICP queries using icpaccess rules. Version 7.5 contains a patch.

Squid is a caching proxy for the Web. In Squid versions prior to 7.2, a failure to redact HTTP authentication credentials in error handling allows information disclosure. The vulnerability allows a script to bypass browser security protections and learn the credentials a trusted client uses to authenticate. This potentially allows a remote client to identify security tokens or credentials used internally by a web application using Squid for backend load balancing. These attacks do not require Squid to be configured with HTTP authentication. The vulnerability is fixed in version 7.2. As a workaround, disable debug information in administrator mailto links generated by Squid by configuring squid.conf with emailerrdata off.

Squid is a caching proxy for the Web. In Squid versions prior to 7.2, a failure to redact HTTP authentication credentials in error handling allows information disclosure. The vulnerability allows a script to bypass browser security protections and learn the credentials a trusted client uses to authenticate. This potentially allows a remote client to identify security tokens or credentials used internally by a web application using Squid for backend load balancing. These attacks do not require Squid to be configured with HTTP authentication. The vulnerability is fixed in version 7.2. As a workaround, disable debug information in administrator mailto links generated by Squid by configuring squid.conf with emailerrdata off.

Squid has issues in ICP message handling

Hi Amos,

Thank you for bringing these 3 issues/advisories to oss-security.

On Wed, Mar 25, 2026 at 05:20:11PM +1300, Amos Jeffries wrote: Due to a heap Use-After-Free bug Squid is vulnerable to Denial of Service when handling ICP traffic. Since use-after-free bugs commonly allow for impact not limited to DoS, but often also code execution and/or information leak, it would help if you provide justification why you claim this is just a DoS - or add wording that it may be more than just a DoS. Ditto for SQUID-2026:2 (CVE-2026-32748).

Thanks,

Alexander

Squid Proxy Cache Security Update Advisory SQUID-2026:3

Advisory ID: | SQUID-2026:3 (CVE-2026-33515) Date: | March 25, 2026 Summary: | Out of Bounds Read in ICP message handling Affected versions: | Squid 3.x -> 3.5.28 | Squid 4.x -> 4.17 | Squid 5.x -> 5.9 | Squid 6.x -> 6.14 | Squid 7.x -> 7.4 Fixed in version: | Squid 7.5

Problem Description:

Due to improper input validation bugs, Squid is vulnerable to out of bounds reads when handling ICP traffic.

Severity:

This problem allows a remote attacker to receive small amounts of memory potentially containing sensitive information when responding with errors to invalid ICP requests.

This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero icpport).

This problem cannot be mitigated by denying ICP queries using icpaccess rules.

Updated Packages

These bugs were fixed in Squid version 7.5.

In addition, patches addressing this problem for the stable releases can be found in our patch archives:

Squid 7: <https://github.com/squid-cache/squid/commit/8138e909d2058d4401e0ad49b583afaec912b165>

Note: we are aware this patch may not apply cleanly. Ensure that the patch for SQUID-2026:1 is applied first.

If you are using a prepackaged version of Squid then please refer to the package vendor for availability information on updated packages.

Determining if your version is vulnerable

Run the following command to identify whether your Squid has been configured with ICP enabled:

squid -k parse 2>&1 | grep -E "(icp|udp)port" | tail -n1

All Squid configured with port 0 are not vulnerable.

All Squid-3.0 up to and including 7.4 configured with a non-zero port should be assumed to be vulnerable.

All Squid-3.2 up to and including 7.4 configured without any port value can be assumed to be not vulnerable.

Workaround

Either,

Do not enable ICP support,

Or,

explicitly disable ICP using "icpport 0".

Warning: These problems cannot be mitigated by denying ICP queries using icpaccess rules.

Contact details for the Squid project:

For installation / upgrade support on binary packaged versions of Squid: Your first point of contact should be your binary package vendor.

If you install and build Squid from the original Squid sources then the <squid-users () lists squid-cache org> mailing list is your primary support point. For subscription details see <https://www.squid-cache.org/Support/mailing-lists.html>.

For reporting of non-security bugs in the latest STABLE release the squid bugzilla database should be used <https://bugs.squid-cache.org/>.

For reporting of security sensitive bugs send an email to the <squid-bugs () lists squid-cache org> mailing list. It's a closed list (though anyone can post) and security related bug reports are treated in confidence until the impact has been established.

Credits

Discovered and Fixed by:

Joshua Rogers with ZeroPath Alex Rousskov, The Measurement Factory

Revision history:

2025-09-07 20:22:00 EDT Report of the first set of vulnerabilities 2026-01-26 08:48:00 EDT Report of additional vulnerabilities 2026-02-12 20:28:43 UTC official fixes in master branch END

Squid Proxy Cache Security Update Advisory SQUID-2026:2

Advisory ID: | SQUID-2026:2 (CVE-2026-32748) Date: | March 25, 2026 Summary: | Denial of Service in ICP Request handling Affected versions: | Squid 3.x -> 3.5.28 | Squid 4.x -> 4.17 | Squid 5.x -> 5.9 | Squid 6.x -> 6.14 | Squid 7.x -> 7.4 Fixed in version: | Squid 7.5

Problem Description:

Due to premature release of resource during expected lifetime and heap Use-After-Free bugs, Squid is vulnerable to Denial of Service when handling ICP traffic.

Severity:

This problem allows a remote attacker to perform a reliable and repeatable Denial of Service attack against the Squid service using ICP protocol.

This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero icpport).

This problem cannot be mitigated by denying ICP queries using icpaccess rules.

Updated Packages

This bug is fixed in Squid version 7.5.

In addition, patches addressing this problem for the stable releases can be found in our patch archives:

Squid 7: <https://github.com/squid-cache/squid/commit/703e07d25ca6fa11f52d20bf0bb879e22ab7481b>

If you are using a prepackaged version of Squid then please refer to the package vendor for availability information on updated packages.

Determining if your version is vulnerable

Run the following command to identify whether your Squid has been configured with ICP enabled:

squid -k parse 2>&1 | grep -E "(icp|udp)port" | tail -n1

All Squid configured with port 0 are not vulnerable.

All Squid-3.0 up to and including 7.4 configured with a non-zero port should be assumed to be vulnerable.

All Squid-3.2 up to and including 7.4 configured without any port value can be assumed to be not vulnerable.

Workaround

Either,

Do not enable ICP support,

Or,

explicitly disable ICP using "icpport 0".

Warning: These problems cannot be mitigated by denying ICP queries using icpaccess rules.

Contact details for the Squid project:

For installation / upgrade support on binary packaged versions of Squid: Your first point of contact should be your binary package vendor.

If you install and build Squid from the original Squid sources then the <squid-users () lists squid-cache org> mailing list is your primary support point. For subscription details see <https://www.squid-cache.org/Support/mailing-lists.html>.

For reporting of non-security bugs in the latest STABLE release the squid bugzilla database should be used <https://bugs.squid-cache.org/>.

For reporting of security sensitive bugs send an email to the <squid-bugs () lists squid-cache org> mailing list. It's a closed list (though anyone can post) and security related bug reports are treated in confidence until the impact has been established.

Credits

Discovered and Fixed by Alex Rousskov, The Measurement Factory

Revision history:

2026-02-08 21:20:00 EDT Report of vulnerability 2026-02-18 21:13:26 UTC official fixes in master branch

END

Squid Proxy Cache Security Update Advisory SQUID-2026:1

Advisory ID: | SQUID-2026:1 (CVE-2026-33526) Date: | March 25, 2026 Summary: | Denial of Service in ICP Request handling Affected versions: | Squid 3.x -> 3.5.28 | Squid 4.x -> 4.17 | Squid 5.x -> 5.9 | Squid 6.x -> 6.14 | Squid 7.x -> 7.4 Fixed in version: | Squid 7.5

Problem Description:

Due to a heap Use-After-Free bug Squid is vulnerable to Denial of Service when handling ICP traffic.

Severity:

This problem allows a remote attacker to perform a reliable and repeatable Denial of Service attack against the Squid service using ICP protocol.

This attack is limited to Squid deployments that explicitly enable ICP support (i.e. configure non-zero icpport).

This problem cannot be mitigated by denying ICP queries using icpaccess rules.

Updated Packages

These bugs were fixed in Squid version 7.5.

In addition, patches addressing this problem for the stable releases can be found in our patch archives:

Squid 7: <https://github.com/squid-cache/squid/commit/8a7d42f9d44befb8fcbbb619505587c8de6a1e91>

If you are using a prepackaged version of Squid then please refer to the package vendor for availability information on updated packages.

Determining if your version is vulnerable

Run the following command to identify whether your Squid has been configured with ICP enabled:

squid -k parse 2>&1 | grep -E "(icp|udp)port" | tail -n1

All Squid configured with port 0 are not vulnerable.

All Squid-3.0 up to and including 7.4 configured with a non-zero port should be assumed to be vulnerable.

All Squid-3.2 up to and including 7.4 configured without any port value can be assumed to be not vulnerable.

Workaround

Either,

Do not enable ICP support,

Or,

explicitly disable ICP using "icpport 0".

Warning: These problems cannot be mitigated by denying ICP queries using icpaccess rules.

Contact details for the Squid project:

For installation / upgrade support on binary packaged versions of Squid: Your first point of contact should be your binary package vendor.

If you install and build Squid from the original Squid sources then the <squid-users () lists squid-cache org> mailing list is your primary support point. For subscription details see <https://www.squid-cache.org/Support/mailing-lists.html>.

For reporting of non-security bugs in the latest STABLE release the squid bugzilla database should be used <https://bugs.squid-cache.org/>.

For reporting of security sensitive bugs send an email to the <squid-bugs () lists squid-cache org> mailing list. It's a closed list (though anyone can post) and security related bug reports are treated in confidence until the impact has been established.

Credits

Discovered by:

Joshua Rogers with ZeroPath Asim Viladi Oglu Manizada

Fixed by:

Joshua Rogers with ZeroPath

Revision history:

2025-09-07 20:22:00 EDT Report of the first set of vulnerabilities 2026-01-26 08:48:00 EDT Report of additional vulnerabilities 2026-02-10 19:58:49 UTC official fixes in master branch

END

Vulnerability in Squid before 2.4.STABLE6 related to proxy authentication credentials may allow remote web sites to obtain the user's proxy login and password.

Buffer overflows in Squid before 2.4.STABLE6 allow remote attackers to cause a denial of service (crash) and possibly execute arbitrary code (1) via the MSNT auth helper (msntauth) when using denyusers or allowusers files, (2) via the gopher client, or (3) via the FTP server directory listing parser when HTML output is generated.

FTP proxy in Squid before 2.4.STABLE6 does not compare the IP addresses of control and data connections with the FTP server, which allows remote attackers to bypass firewall rules or spoof FTP server responses.

Heap-based buffer overflow in Squid before 2.4 STABLE4, and Squid 2.5 and 2.6 until March 12, 2002 distributions, allows remote attackers to cause a denial of service, and possibly execute arbitrary code, via compressed DNS responses.

Memory leak in SNMP in Squid 2.4 STABLE3 and earlier allows remote attackers to cause a denial of service.

Squid 2.4 STABLE3 and earlier does not properly disable HTCP, even when "htcpport 0" is specified in squid.conf, which could allow remote attackers to bypass intended access restrictions.

Squid 2.4 STABLE3 and earlier allows remote attackers to cause a denial of service (core dump) and possibly execute arbitrary code with an ftp:// URL with a larger number of special characters, which exceed the buffer when Squid URL-escapes the characters.

The clientAbortBody function in clientside.c in Squid Web Proxy Cache before 2.6 STABLE6 allows remote attackers to cause a denial of service (segmentation fault) via unspecified vectors that trigger a null dereference. NOTE: in a followup advisory, a researcher claimed that the issue was a buffer overflow that was not fixed in STABLE6. However, the vendor's bug report clearly shows that the researcher later retracted this claim, because the tested product was actually STABLE5.

The asnparseheader function (asn1.c) in the SNMP module for Squid Web Proxy Cache before 2.4.STABLE7 allows remote attackers to cause a denial of service (server restart) via certain SNMP packets with negative length fields that trigger a memory allocation error.

The (1) ntlmfetchstring and (2) ntlmgetstring functions in Squid 2.5.6 and earlier, with NTLM authentication enabled, allow remote attackers to cause a denial of service (application crash) via an NTLMSSP packet that causes a negative value to be passed to memcpy.

The "%xx" URL decoding function in Squid 2.5STABLE4 and earlier allows remote attackers to bypass urlregex ACLs via a URL with a NULL ("%00") character, which causes Squid to use only a portion of the requested URL when comparing it against the access control lists.

Unspecified vulnerability in Squid on SUSE Linux 9.0 allows remote attackers to cause a denial of service (crash) via HTTPs (SSL).