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 Proxy Cache Security Update Advisory SQUID-2025:2

Advisory ID: | SQUID-2025:2, CVE-2025-62168 Date: | October 15, 2025 Summary: | Information Disclosure in Error 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.1 Fixed in version: | Squid 7.2

Problem Description:

Due to a failure to redact HTTP Authentication credentials Squid is vulnerable to an Information Disclosure attack.

Severity:

This problem allows a script to bypass Browser security protections and learn the credentials a trusted client uses to authenticate.

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

Updated Packages:

This bug is fixed by Squid version 7.2.

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

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

The following test can be used to determine if your Squid has a vulnerable configuration:

squid -k parse 2>&1 | grep "emailerrdata"

All Squid with emailerrdata off are not vulnerable.

All Squid up to and including 7.1 with emailerrdata on are vulnerable.

All Squid up to and including 7.1 without emailerrdata are vulnerable.

Workaround:

Disable debug information in administrator mailto links generated by Squid. By configuring squid.conf with:

emailerrdata off

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 at lists.squid-cache.org> mailing list is your primary support point. For subscription details see <http://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 at 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:

This vulnerability was discovered by Leonardo Giovannini of Doyensec.

Fixed by Amos Jeffries of Treehouse Networks Ltd.

Revision history:

2025-09-12 08:52:20 UTC Initial Report 2025-10-11 07:42:00 UTC Patch Released 2025-10-13 14:35:00 UTC CVE Assignment END

On 05/11/2025 13:09, Solar Designer wrote: Hi, Thank you for posting this, but I'm afraid it is confusing: On Wed, Nov 05, 2025 at 11:26:14AM +1300, Amos Jeffries wrote: > Squid Proxy Cache Security Update Advisory SQUID-2023:6 > Advisory ID: | SQUID-2023:6 (CVE-2019-18860) > Date: | November 5, 2025 OK, so it's an advisory from 2023 for a CVE from 2019 (or for an issue first disclosed in 2019), which was updated in 2025. This brings up the question of what those updates in 2025 are...

Okay, to clarify;

Revision history:

2019-10-18 20:15:14 UTC Initial Report 2019-11-03 16:22:22 UTC Initial Patches Released 2020-03-31 11:07:35 UTC Additional Report ...but the revision history starts in 2019 (before the advisory year?!) and ends in 2020. (oops, thanks I have updated the github text)

Cheers Amos

Squid Proxy Cache Security Update Advisory SQUID-2025:1

Advisory ID: | SQUID-2025:1, CVE-2025-54574 Date: | August 1, 2025 Summary: | Buffer Overflow in URN Handling Affected versions: | Squid 2.x -> 2.7.STABLE9 | Squid 3.x -> 3.5.28 | Squid 4.x -> 4.17 | Squid 5.x -> 5.9 | Squid 6.x -> 6.3 Fixed in version: | Squid 6.4

Problem Description:

Due to incorrect buffer management Squid is vulnerable to a heap buffer overflow and possible remote code execution attack when processing URN.

Severity:

This problem allows a remote server to perform a Buffer Overflow attack when delivering URN Trivial-HTTP responses. Potentially allowing delivery of up to 4KB of Squid allocated heap memory to the client.

Revealed memory may include security credentials or other confidential data.

Updated Packages:

This bug is fixed by Squid version 6.4.

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

Squid 6: 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:

Squid older than 4.14 have not been tested and should be assumed to be vulnerable.

All Squid-4.x up to and including 4.17 are vulnerable.

All Squid-5.x up to and including 5.9 are vulnerable.

All Squid-6.x up to and including 6.3 are vulnerable.

Workaround:

Disable URN access permissions.

acl URN proto URN httpaccess deny URN

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 at lists.squid-cache.org> mailing list is your primary support point. For subscription details see <http://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 at 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:

This vulnerability was discovered by StarryNight.

Fixed by The Measurement Factory.

Revision history: 2023-06-24 08:18:55 UTC Fix published 2025-07-01 18:40:24 UTC Initial Report END

Hi,

Thank you for posting this, but I'm afraid it is confusing:

On Wed, Nov 05, 2025 at 11:26:14AM +1300, Amos Jeffries wrote: Squid Proxy Cache Security Update Advisory SQUID-2023:6

Advisory ID: | SQUID-2023:6 (CVE-2019-18860) Date: | November 5, 2025 OK, so it's an advisory from 2023 for a CVE from 2019 (or for an issue first disclosed in 2019), which was updated in 2025. This brings up the question of what those updates in 2025 are... Revision history:

2019-10-18 20:15:14 UTC Initial Report 2019-11-03 16:22:22 UTC Initial Patches Released 2020-03-31 11:07:35 UTC Additional Report ...but the revision history starts in 2019 (before the advisory year?!) and ends in 2020.

I also found this advisory at:

https://github.com/squid-cache/squid/security/advisories

where it's the only one "published" (or updated?) very recently: SQUID-2023:6 Cross Site Scripting in cachemgr.cgi GHSA-xxrg-5p7x-r66h published 1 hour ago by yadij I also see a couple of SQUID-2025 advisories, one from July 31 and the other from October 17, 2025. Both have Critical CVSS severities.

I don't recall you bringing them to here? Perhaps do that now? SQUID-2025:2 Information Disclosure in Error handling GHSA-c8cc-phh7-xmxr published 3 weeks ago by yadij Critical

SQUID-2025:1 Buffer Overflow in URN Handling GHSA-w4gv-vw3f-29g3 published on Jul 31 by yadij Critical I think it's unreasonable to go further back now, but posting these two recent ones should be beneficial.

Thanks,

Alexander

Squid Proxy Cache Security Update Advisory SQUID-2023:6

Advisory ID: | SQUID-2023:6 (CVE-2019-18860) Date: | November 5, 2025 Summary: | Cross Site Scripting in cachemgr.cgi Affected versions: | Squid 2.x -> 2.7.STABLE9 | Squid 3.x -> 3.5.28 | Squid 4.x -> 4.17 | Squid 5.x -> 5.9 | Squid 6.x -> 6.14

Problem Description:

Due to an Improper Neutralization of Input During Web Page Generation bug Squid cachemgr.cgi tool is vulnerable to a Cross-Site Scripting attack.

Severity:

This problem allows a remote attacker to perform a Cross-Site scripting attack against clients or administrators with access to the cachemgr.cgi reporting.

This attack is limited to cachemgr.cgi.

Updated Packages:

The cachemgr.cgi tool has been removed (EOL) by Squid version 7

Patches addressing this problem for the stable releases can be found in our patch archives:

Squid 6 and older: <https://github.com/squid-cache/squid/commit/d94dbed6c700faeded8c4175f2a8d0f71c15755b>

Squid 4.8 and older also require: <https://github.com/squid-cache/squid/commit/5a90b4ce64c346ba7f317a278ba601091d9de076>

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:

All unpatched cachemgr.cgi are vulnerable.

Workaround:

Fetch manager reports directly from Squid. For example; http://localhost:3128/squid-internal-mgr/menu

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 <http://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 <http://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:

This vulnerability was discovered by Aaron Costello

Additional vectors discovered by Stefan Cornelius of RedHat.

Initial fix by Aaron Costello

Revision history:

2019-10-18 20:15:14 UTC Initial Report 2019-11-03 16:22:22 UTC Initial Patches Released 2020-03-31 11:07:35 UTC Additional Report 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.

Squid through 7.1 mishandles ASN.1 encoding of long SNMP OIDs. This occurs in asnbuildobjid in lib/snmplib/asn1.c.

Squid is a caching proxy for the Web. In versions 6.3 and below, Squid is vulnerable to a heap buffer overflow and possible remote code execution attack when processing URN due to incorrect buffer management. This has been fixed in version 6.4. To work around this issue, disable URN access permissions.

Squid is a caching proxy for the Web. In versions 6.3 and below, Squid is vulnerable to a heap buffer overflow and possible remote code execution attack when processing URN due to incorrect buffer management. This has been fixed in version 6.4. To work around this issue, disable URN access permissions.

Squid is an open source caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to Input Validation, Premature Release of Resource During Expected Lifetime, and Missing Release of Resource after Effective Lifetime bugs, Squid is vulnerable to Denial of Service attacks by a trusted server against all clients using the proxy. This bug is fixed in the default build configuration of Squid version 6.10.

Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to an Out-of-bounds Write error when assigning ESI variables, Squid is susceptible to a Memory Corruption error. This error can lead to a Denial of Service attack.

References: https://github.com/squid-cache/squid/security/advisories/GHSA-wgvf-q977-9xjg https://megamansec.github.io/Squid-Security-Audit/esi-underflow.html

Upstream patch: https://github.com/squid-cache/squid/commit/f411fe7d75197852f0e5ee85027a06d58dd8df4c.patch

Squid is a caching proxy for the Web. Due to an expired pointer reference bug, Squid prior to version 6.6 is vulnerable to a Denial of Service attack against Cache Manager error responses. This problem allows a trusted client to perform Denial of Service when generating error pages for Client Manager reports. Squid older than 5.0.5 have not been tested and should be assumed to be vulnerable. All Squid-5.x up to and including 5.9 are vulnerable. All Squid-6.x up to and including 6.5 are vulnerable. This bug is fixed by Squid version 6.6. In addition, patches addressing this problem for the stable releases can be found in Squid's patch archives. As a workaround, prevent access to Cache Manager using Squid's main access control: httpaccess deny manager.

http://www.squid-cache.org/Versions/v5/SQUID-202311.patch http://www.squid-cache.org/Versions/v6/SQUID-202311.patch https://github.com/squid-cache/squid/commit/290ae202883ac28a48867079c2fb34c40efd382b https://github.com/squid-cache/squid/commit/e8118a7381213f5cfcdeb4cec1d2d854bfd261c8 https://github.com/squid-cache/squid/security/advisories/GHSA-j49p-553x-48rx https://megamansec.github.io/Squid-Security-Audit/stream-assert.html

Hi Amos, oss-security,

I've added GHSA-543m-w2m2-g255 and CVE-2021-46784 for 'Cache Poisoning by Large Stored Response Headers (With Bonus XSS)' and 'Assertion in Gopher Response Handling' respectively: GHSA-543m-w2m2-g255 and CVE-2021-46784

However, for "Gopher Assertion Crash", GHSA-f5cp-6rh3-284w does not apply. "Gopher Assertion Crash" concerns an assertion "assertion failed: store.cc:832: "storestatus == STOREPENDING"" while GHSA-f5cp-6rh3-284w concerns an assertion: "assertion failed: String.cc:172: "canGrowBy(len)""

To the best of my knowledge the former (without a current GHSA or CVE) is unfixed.

Cheers, Josh

On Fri, Oct 13, 2023 at 3:54 AM Amos Jeffries <squid3 () treenet co nz> wrote: Some reference updates.

On 11/10/23 20:55, Joshua Rogers wrote: The issues are listed below. Due to the sheer size of issues discovered, technical details are not included in this email. However, breakdowns of the code and proof-of-concepts can be found on GitHub: https://megamansec.github.io/Squid-Security-Audit/

Cache Poisoning by Large Stored Response Headers (With Bonus XSS) ... GHSA-543m-w2m2-g255 Gopher Assertion Crash ... GHSA-f5cp-6rh3-284w Assertion in Gopher Response Handling ... CVE-2021-46784 / GHSA-f5cp-6rh3-284w

AYJ

Some reference updates.

On 11/10/23 20:55, Joshua Rogers wrote: The issues are listed below. Due to the sheer size of issues discovered, technical details are not included in this email. However, breakdowns of the code and proof-of-concepts can be found on GitHub: https://megamansec.github.io/Squid-Security-Audit/

Cache Poisoning by Large Stored Response Headers (With Bonus XSS) ... GHSA-543m-w2m2-g255 Gopher Assertion Crash ... GHSA-f5cp-6rh3-284w Assertion in Gopher Response Handling ... CVE-2021-46784 / GHSA-f5cp-6rh3-284w

AYJ