CVE-2026-33526: Squid Caching Proxy DoS Vulnerability

CVE-2026-33526 Overview

Squid, a widely deployed caching proxy for the Web, contains a critical Use-After-Free vulnerability in its ICP (Internet Cache Protocol) traffic handling. Prior to version 7.5, a heap Use-After-Free condition allows remote attackers to perform reliable and repeatable Denial of Service attacks against the Squid service. This vulnerability specifically affects Squid deployments that explicitly enable ICP support by configuring a non-zero icp_port value.

Critical Impact

Remote attackers can completely disrupt Squid proxy services through crafted ICP traffic, causing service unavailability for all dependent systems and users. This attack cannot be mitigated using icp_access rules.

Affected Products

• Squid versions prior to 7.5
• Squid deployments with ICP support enabled (non-zero icp_port configuration)
• Network environments relying on ICP for cache coordination

Discovery Timeline

• 2026-03-26 - CVE-2026-33526 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33526

Vulnerability Analysis

This Use-After-Free vulnerability (CWE-416) exists in Squid's ICP protocol handling code. The flaw occurs during the processing of ICP requests, specifically when handling malformed URIs. The vulnerability stems from a double-escape condition in the icpGetRequest function within src/icp_v2.cc, where a URI containing whitespace characters is escaped twice before being sent in an ICP error response. This double-escape operation triggers a heap Use-After-Free condition, as the memory from the first escape operation is freed before being accessed again.

The attack is network-accessible and requires no authentication, making it highly exploitable. However, the impact is limited to availability—attackers cannot achieve code execution or data exfiltration through this vector. The vulnerability requires that the target Squid instance has ICP explicitly enabled through configuration.

Root Cause

The root cause lies in the icpGetRequest function where malformed URIs containing whitespace are processed. The original code called rfc1738_escape(url) to escape the URL, then passed the result to icpCreateAndSend which called rfc1738_escape() again on the same URL. This resulted in a double-escape scenario where memory was accessed after being freed, triggering the Use-After-Free condition. The vulnerable code path is only reachable when ICP is enabled with a non-zero icp_port configuration.

Attack Vector

An attacker can exploit this vulnerability by sending specially crafted ICP requests containing malformed URIs with whitespace characters to a Squid proxy with ICP enabled. The attack is:

• Network-accessible: Can be triggered remotely over the network
• Unauthenticated: Requires no credentials or prior access
• Reliable: Can be repeated consistently to maintain denial of service
• Unmitigable via ACLs: Cannot be blocked using icp_access configuration rules

The security patch removes the redundant rfc1738_escape() call:

 icpGetRequest(char *url, int reqnum, int fd, Ip::Address &from)
 {
     if (strpbrk(url, w_space)) {
-        url = rfc1738_escape(url);
         icpCreateAndSend(ICP_ERR, 0, rfc1738_escape(url), reqnum, 0, fd, from, nullptr);
         return nullptr;
     }

Source: GitHub Commit Update

Detection Methods for CVE-2026-33526

Indicators of Compromise

• Unexpected Squid service crashes or restarts, particularly when ICP traffic is present
• Abnormal memory usage patterns or heap corruption errors in Squid logs
• High volume of ICP traffic from unknown or external sources
• Repeated service unavailability coinciding with ICP request activity

Detection Strategies

• Monitor Squid process stability and implement alerting for unexpected service terminations
• Analyze ICP traffic patterns for anomalies, particularly requests containing malformed URIs with whitespace
• Deploy network intrusion detection rules to identify suspicious ICP packets targeting UDP port configured in icp_port
• Review Squid logs for segmentation faults or memory-related error messages

Monitoring Recommendations

• Enable verbose logging for ICP-related activities in Squid configuration
• Implement process monitoring to detect and alert on Squid service crashes
• Monitor network traffic on ICP ports for unusual patterns or volume spikes
• Set up automated service recovery with crash notification to maintain availability while investigating

How to Mitigate CVE-2026-33526

Immediate Actions Required

• Upgrade Squid to version 7.5 or later immediately
• If upgrade is not immediately possible, disable ICP support by setting icp_port to 0 in squid.conf
• Audit firewall rules to restrict ICP traffic to trusted cache peers only
• Implement network-level filtering to block external ICP traffic

Patch Information

The vulnerability is patched in Squid version 7.5. The fix removes the redundant rfc1738_escape() call that caused the double-escape condition. Organizations should upgrade to version 7.5 or apply the specific commit 8a7d42f9d44befb8fcbbb619505587c8de6a1e91 to their Squid installation. For more details, refer to the GitHub Security Advisory and the Openwall OSS Security Post.

Workarounds

• Disable ICP entirely by setting icp_port 0 in the Squid configuration file—this completely removes the attack surface
• Implement firewall rules to block ICP traffic (typically UDP) from untrusted networks
• If ICP is required, restrict network access to ICP ports using perimeter firewalls, allowing only trusted cache peer addresses
• Consider alternative cache coordination mechanisms that do not rely on ICP protocol

# Configuration example - Disable ICP in squid.conf
# Add or modify the following line to disable ICP support
icp_port 0

# Alternatively, use firewall rules to restrict ICP access (example using iptables)
# Block all incoming ICP traffic except from trusted peers
iptables -A INPUT -p udp --dport 3130 -s trusted_peer_ip -j ACCEPT
iptables -A INPUT -p udp --dport 3130 -j DROP