Last updated 13 January 2025

The htcpHandleTstRequest function in htcp.c in Squid 2.x before 2.6.STABLE24 and 2.7 before 2.7.STABLE8, and htcp.cc in 3.0 before 3.0.STABLE24, allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via crafted packets to the HTCP port.

lib/rfc1035.c in Squid 2.x, 3.0 through 3.0.STABLE22, and 3.1 through 3.1.0.15 allows remote attackers to cause a denial of service (assertion failure) via a crafted DNS packet that only contains a header.

Last updated 25 August 2025

Last updated 25 August 2025

Last updated 25 August 2025

http.cc in Squid 3.x before 3.5.15 and 4.x before 4.0.7 proceeds with the storage of certain data after a response-parsing failure, which allows remote HTTP servers to cause a denial of service (assertion failure and daemon exit) via a malformed response.

Last updated 25 August 2025

An issue was discovered in Squid before 5.0.2. A remote attacker can replay a sniffed Digest Authentication nonce to gain access to resources that are otherwise forbidden. This occurs because the attacker can overflow the nonce reference counter (a short integer). Remote code execution may occur if the pooled token credentials are freed (instead of replayed as valid credentials).

An issue was discovered in Squid 2.x, 3.x, and 4.x through 4.8. Due to incorrect data management, it is vulnerable to information disclosure when processing HTTP Digest Authentication. Nonce tokens contain the raw byte value of a pointer that sits within heap memory allocation. This information reduces ASLR protections and may aid attackers isolating memory areas to target for remote code execution attacks.

An issue was discovered in Squid 3.x and 4.x through 4.8. Due to incorrect input validation, there is a heap-based buffer overflow that can result in Denial of Service to all clients using the proxy. Severity is high due to this vulnerability occurring before normal security checks; any remote client that can reach the proxy port can trivially perform the attack via a crafted URI scheme.

An issue was discovered in Squid 3.x and 4.x through 4.8. It allows attackers to smuggle HTTP requests through frontend software to a Squid instance that splits the HTTP Request pipeline differently. The resulting Response messages corrupt caches (between a client and Squid) with attacker-controlled content at arbitrary URLs. Effects are isolated to software between the attacker client and Squid. There are no effects on Squid itself, nor on any upstream servers. The issue is related to a request header containing whitespace between a header name and a colon.

An issue was discovered in Squid 3.x and 4.x through 4.8 when the appenddomain setting is used (because the appended characters do not properly interact with hostname length restrictions). Due to incorrect message processing, it can inappropriately redirect traffic to origins it should not be delivered to.

An issue was discovered in Squid before 4.9. URN response handling in Squid suffers from a heap-based buffer overflow. When receiving data from a remote server in response to an URN request, Squid fails to ensure that the response can fit within the buffer. This leads to attacker controlled data overflowing in the heap.

An issue was discovered in Squid 2.x through 2.7.STABLE9, 3.x through 3.5.28, and 4.x through 4.7. When Squid is configured to use Basic Authentication, the Proxy-Authorization header is parsed via uudecode. uudecode determines how many bytes will be decoded by iterating over the input and checking its table. The length is then used to start decoding the string. There are no checks to ensure that the length it calculates isn't greater than the input buffer. This leads to adjacent memory being decoded as well. An attacker would not be able to retrieve the decoded data unless the Squid maintainer had configured the display of usernames on error pages.

An issue was discovered in Squid through 4.7. When handling the tag esi:when when ESI is enabled, Squid calls ESIExpression::Evaluate. This function uses a fixed stack buffer to hold the expression while it's being evaluated. When processing the expression, it could either evaluate the top of the stack, or add a new member to the stack. When adding a new member, there is no check to ensure that the stack won't overflow.

An issue was discovered in Squid through 4.7. When Squid is parsing ESI, it keeps the ESI elements in ESIContext. ESIContext contains a buffer for holding a stack of ESIElements. When a new ESIElement is parsed, it is added via addStackElement. addStackElement has a check for the number of elements in this buffer, but it's off by 1, leading to a Heap Overflow of 1 element. The overflow is within the same structure so it can't affect adjacent memory blocks, and thus just leads to a crash while processing.

An issue was discovered in Squid before 4.9. When handling a URN request, a corresponding HTTP request is made. This HTTP request doesn't go through the access checks that incoming HTTP requests go through. This causes all access checks to be bypassed and allows access to restricted HTTP servers, e.g., an attacker can connect to HTTP servers that only listen on localhost.

Due to incorrect pointer handling, Squid versions 3.x (prior to 3.5.27) and 4.x (prior to 4.0.23) are vulnerable to a denial of service attack when processing ESI responses. This problem allows a remote server delivering certain ESI response syntax to trigger a denial of service for all clients accessing the Squid service.

Upstream Advisory: http://www.squid-cache.org/Advisories/SQUID-20181.txt

Upstream Patches: http://www.squid-cache.org/Versions/v3/3.5/changesets/SQUID-20181.patch http://www.squid-cache.org/Versions/v4/changesets/SQUID-20181.patch

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.

In Squid 3.x through 3.5.28, 4.x through 4.17, and 5.x before 5.6, due to improper buffer management, a Denial of Service can occur when processing long Gopher server responses.