CVE-2026-33515: 
Squid vulnerability analysis and mitigation

CVE-2026-33515 is an out-of-bounds read vulnerability in Squid, the widely-used caching proxy, affecting all versions prior to 7.5. Due to improper input validation when handling Internet Cache Protocol (ICP) traffic, a remote unauthenticated attacker can trigger out-of-bounds memory reads by sending malformed ICP requests, causing Squid to leak small amounts of process memory in error responses. The vulnerability is tracked as SQUID-2026:3 and was disclosed on March 26, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is improper input validation (CWE-125: Out-of-bounds Read; CWE-1289: Improper Validation of Unsafe Equivalence in Input) in Squid's ICP message handling code, specifically in src/icp_v2.cc and src/icp_v3.cc. When processing ICP queries or replies, Squid failed to validate that URL fields within packets were properly NUL-terminated, did not contain embedded NUL characters, and that packet sizes were sufficient before dereferencing URL pointers — allowing reads beyond the intended buffer boundary. The fix introduced the icpGetUrl() function to centralize and enforce these checks for both ICP v2 and v3 traffic, rejecting packets with unterminated or malformed URLs and enforcing minimum packet size requirements (GitHub PR #2220, Patch Commit). Exploitation requires that the target Squid instance has ICP explicitly enabled via a non-zero icp_port configuration directive; the default configuration is not vulnerable (GitHub Advisory).

Successful exploitation allows a remote, unauthenticated attacker to receive small amounts of Squid process memory contents embedded in ICP error responses, constituting an information disclosure risk. The leaked memory could potentially contain sensitive data such as cached content fragments, credentials, or internal state depending on what resides in adjacent memory at the time of exploitation. There is no availability or significant integrity impact — the vulnerability does not enable code execution or service disruption — and its scope is limited to Squid instances with ICP explicitly enabled (GitHub Advisory, Red Hat Bugzilla).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The vulnerability has a low EPSS score of approximately 0.0015, reflecting a low near-term exploitation probability. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. The attack requires no authentication, no user interaction, and has low complexity, but is constrained to deployments with ICP explicitly enabled (GitHub Advisory).

1. Reconnaissance: Identify Squid proxy instances with ICP enabled by scanning for open UDP ports (default ICP port is 3130) using tools such as Nmap (nmap -sU -p 3130 <target>) or Shodan queries for Squid ICP services.
2. Confirm ICP availability: Send a valid ICP query to the target's icp_port and verify a response is received, confirming ICP is active.
3. Craft malformed ICP packet: Construct a malformed ICP v2 or v3 query packet with a URL field that is not NUL-terminated, contains embedded NUL characters, or has a packet length field inconsistent with the actual payload size, bypassing the (pre-patch) absence of URL validation.
4. Send invalid ICP request: Transmit the crafted UDP packet to the target's ICP port. Squid's pre-patch code would pass the invalid URL pointer directly to consumers without bounds checking.
5. Receive memory leak in error response: Squid responds with an ICP error reply (ICP_ERR) that may include out-of-bounds memory contents in the URL field, which the attacker reads from the UDP response (GitHub Advisory, GitHub PR #2220).

• Network: Unexpected or malformed UDP packets arriving on the Squid ICP port (default 3130) from external or untrusted sources; ICP error responses (ICP_ERR) sent to unknown or suspicious IP addresses.
• Logs: Squid debug log entries (debug level 12, level 3) containing messages such as "too small packet from", "unterminated URL or trailing garbage from", or "URL with an embedded NUL or trailing garbage from" — these are generated by the patched code but may indicate active probing; on unpatched systems, silent failures or anomalous ICP error responses may appear in access logs.
• Network: Repeated ICP queries from a single source IP with varying malformed payloads, indicative of automated scanning or fuzzing activity against the ICP port (GitHub PR #2220, GitHub Advisory).

The definitive fix is to upgrade Squid to version 7.5 or later, which includes the patch (commit 8138e90) addressing both ICP v2 and v3 handling (Patch Commit). For Squid 7.x deployments that cannot immediately upgrade, the patch can be applied manually — note that the SQUID-2026:1 patch should be applied first as a prerequisite. As a configuration-based workaround, disable ICP entirely by setting icp_port 0 in squid.conf; this eliminates the attack surface completely. Important: Restricting ICP access via icp_access rules alone does NOT mitigate this vulnerability, as the out-of-bounds read occurs before access control evaluation (GitHub Advisory, Red Hat Bugzilla). To check if your deployment is vulnerable, run: squid -k parse 2>&1 | grep -E "(icp|udp)_port" | tail -n1 — any non-zero port value indicates exposure.

The vulnerability was discovered and reported by Joshua Rogers with ZeroPath, with remediation developed by Alex Rousskov of The Measurement Factory (GitHub Advisory). Red Hat tracked the issue via Bugzilla and assessed it as medium severity. The disclosure generated routine coverage in vulnerability tracking platforms (VulDB, CVEFeed, ENISA EUVD) and Linux distribution security advisories for Ubuntu and Mageia. Community reaction on Bluesky and security mailing lists (oss-sec) was limited, consistent with the moderate severity and constrained exploitation conditions of the vulnerability.