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

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 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.

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 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 has issues in ICP message handling

Squid has Denial of Service in ICP Response handling

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 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

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.

A denial of service flaw was found in the way Squid proxy caching server internally processed NULL buffers. A remote, trusted client could use this flaw to cause squid daemon crash (dereference NULL pointer) when processing specially-crafted request.

References: [1] http://www.squid-cache.org/Advisories/SQUID-20103.txt

Upstream patch (against Squid v3.0): [2] http://www.squid-cache.org/Versions/v3/3.0/changesets/squid-3.0-9189.patch

Upstream patch (against Squid v3.1): [3] http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10090.patch

Credit: The vulnerability was discovered by Phil Oester.

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.

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.

The clientProcessRequest() function in src/clientside.c in Squid 2.6 before 2.6.STABLE12 allows remote attackers to cause a denial of service (daemon crash) via crafted TRACE requests that trigger an assertion error.

squid/src/ftp.c in Squid before 2.6.STABLE7 allows remote FTP servers to cause a denial of service (core dump) via crafted FTP directory listing responses, possibly related to the (1) ftpListingFinish and (2) ftpHtmlifyListEntry functions.

The aclMatchExternal function in Squid before 2.6.STABLE7 allows remote attackers to cause a denial of service (crash) by causing an externalacl queue overload, which triggers an infinite loop.

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

The rfc1738doescape function in ftp.c for Squid 2.5 STABLE11 and earlier allows remote FTP servers to cause a denial of service (segmentation fault) via certain "odd" responses.

Squid 2.5.STABLE10 and earlier, while performing NTLM authentication, does not properly handle certain request sequences, which allows attackers to cause a denial of service (daemon restart).

The sslConnectTimeout function in ssl.c for Squid 2.5.STABLE10 and earlier allows remote attackers to cause a denial of service (segmentation fault) via certain crafted requests.

store.c in Squid 2.5.STABLE10 and earlier allows remote attackers to cause a denial of service (crash) via certain aborted requests that trigger an assert error related to STOREPENDING.

Squid 2.5 STABLE9 and earlier, when the DNS client port is unfiltered and the environment does not prevent IP spoofing, allows remote attackers to spoof DNS lookups.

Squid 2.5.STABLE9 and earlier does not trigger a fatal error when it identifies missing or invalid ACLs in the httpaccess configuration, which could lead to less restrictive ACLs than intended by the administrator.

Squid 2.5.STABLE7 and earlier allows remote attackers to cause a denial of service (segmentation fault) by aborting the connection during a (1) PUT or (2) POST request, which causes Squid to access previously freed memory.