-Infinity
0
Severity
7.7
AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

A request smuggling vulnerability was found in Squid. Due to improper enforcement of behavioral workflow when processing HTTP/1.1 Transfer-Encoding headers, a trusted client can perform an HTTP request smuggling attack. This can bypass security mechanisms between the attacker and Squid. When an HTTP cache operates prior to the affected Squid instance, this also allows cache poisoning, enabling the attacker to store arbitrary malicious content at any URL for delivery to other clients.

Squid versions 3.3.0.1 through 7.5 are affected. The fix is available in version 7.6.

1 / 4
Source: Red Hat
First published (updated )
Severity
7.7
AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

Squid is a caching proxy for the Web. From 3.3.0.1 to before 7.6, due to an improper enforcement of behavioral workflow bug, Squid is vulnerable to a Request Smuggling attack against HTTP/1.1 Transfer-Encoding. HTTP header parsing (src/HttpHeader.cc) accepted the bare Transfer-Encoding: identity form, which the HTTP specification prohibits because any transfer coding must be wrapped within chunked encoding. This problem allows a trusted client to perform an HTTP Request Smuggling attack when HTTP/1.1 is used, bypassing security mechanisms that may be in place between attacker and Squid. When there is an HTTP cache operating prior to the affected Squid, this Request Smuggling attack also allows the attacker to poison that web cache and store arbitrary malicious content at any URL for delivery to other clients' future requests. This issue is fixed in version 7.6.

First published (updated )
Severity
7

A request smuggling vulnerability was found in Squid. Due to improper enforcement of behavioral workflow when processing HTTP/1.1 Transfer-Encoding headers, a trusted client can perform an HTTP request smuggling attack. This can bypass security mechanisms between the attacker and Squid. When an HTTP cache operates prior to the affected Squid instance, this also allows cache poisoning, enabling the attacker to store arbitrary malicious content at any URL for delivery to other clients.

Squid versions 3.3.0.1 through 7.5 are affected. The fix is available in version 7.6.

First published (updated )
Severity
8.2
AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

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

First published (updated )
Severity
9.8
Buffer Overflow
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H

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.

First published (updated )
Severity
8.6
Use After Free
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H

Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Affected versions of squid are subject to a a Use-After-Free bug which can lead to a Denial of Service attack via collapsed forwarding. All versions of Squid from 3.5 up to and including 5.9 configured with "collapsedforwarding on" are vulnerable. Configurations with "collapsedforwarding off" or without a "collapsedforwarding" directive are not vulnerable. This bug is fixed by Squid version 6.0.1. Users are advised to upgrade. Users unable to upgrade should remove all collapsedforwarding lines from their squid.conf.

First published (updated )
Severity
9.3
Buffer Overflow
AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:H

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.

First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

A flaw was found in Squid. The limits applied for validation of HTTP response headers are applied before caching. However, Squid may grow a cached HTTP response header beyond the configured maximum size, causing a stall or crash of the worker process when a large header is retrieved from the disk cache, resulting in a denial of service.

First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Last updated 7 August 2026

1 / 3
Source: Ubuntu
First published (updated )
Severity
5.5
Input Validation, Buffer Overflow
AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H

Last updated 7 August 2026

1 / 3
Source: Ubuntu
First published (updated )
Buffer Overflow

It was discovered that Squid incorrectly handled certain HTTP Transfer- Encoding headers. An attacker could possibly use this issue to perform HTTP request smuggling attacks, bypass security mechanisms, or poison web caches. (CVE-2026-61642) It was discovered that Squid incorrectly handled certain cache digest replies, which could lead to a buffer overflow. A remote attacker could possibly use this issue to cause Squid to crash, resulting in a denial of service. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, and Ubuntu 20.04 LTS. (CVE-2026-50012) It was discovered that Squid incorrectly handled parsing certain FTP directory listings. A remote attacker could possibly use this issue to obtain sensitive information. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, and Ubuntu 20.04 LTS. (CVE-2026-47729) It was discovered that Squid incorrectly handled certain ICP traffic. A remote attacker could possibly use this issue to cause Squid to crash, resulting in a denial of service. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, and Ubuntu 20.04 LTS. (CVE-2026-32748, CVE-2026-33526) It was discovered that Squid incorrectly handled certain ICP requests. A remote attacker could possibly use this issue to obtain sensitive information. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, and Ubuntu 20.04 LTS. (CVE-2026-33515)

First published (updated )
Advisory
USN-8941-1
Severity
10
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N

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.

1 / 2
Source: NVD
First published (updated )
Severity
7
Input Validation

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.

First published (updated )
Severity
8.7
Use After Free
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Last updated 30 June 2026

1 / 3
Source: Ubuntu
First published (updated )
Severity
9.2
EPSS
1.98%
Use After Free
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Last updated 30 June 2026

1 / 3
Source: Ubuntu
First published (updated )
Severity
7
Use After Free

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.

First published (updated )
Severity
7
Use After Free

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.

First published (updated )

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

Severity
6.9
EPSS
0.96%
Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Last updated 15 October 2026

1 / 3
Source: Ubuntu
First published (updated )
Severity
5.4
AV:N/AC:H/Au:N/C:C/I:N/A:N

Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0801 to the following vulnerability:

Name: CVE-2009-0801 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0801 Assigned: 20090304 Reference: CERT-VN:VU#435052 Reference: URL: http://www.kb.cert.org/vuls/id/435052 Reference: BID:33858 Reference: URL: http://www.securityfocus.com/bid/33858

Squid, when transparent interception mode is enabled, uses the HTTP Host header to determine the remote endpoint, which allows remote attackers to bypass access controls for Flash, Java, Silverlight, and probably other technologies, and possibly communicate with restricted intranet sites, via a crafted web page that causes a client to send HTTP requests with a modified Host header.

1 / 3
Source: Red Hat
First published (updated )
Severity
5
Input Validation
AV:N/AC:L/Au:N/C:N/I:N/A:P

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.

1 / 2
First published (updated )
Severity
4.3
AV:N/AC:M/Au:N/C:N/I:N/A:P

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

First published (updated )
Severity
7

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.

First published (updated )

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

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203