CVE-2026-32748: 
Squid vulnerability analysis and mitigation

CVE-2026-32748 is a Denial of Service vulnerability in Squid, the widely-used caching proxy, caused by premature resource release and heap Use-After-Free bugs in ICP (Internet Cache Protocol) request handling. It affects all Squid versions from 3.x through 7.4 (specifically Squid 3.0–3.5.28, 4.x–4.17, 5.x–5.9, 6.x–6.14, and 7.x–7.4) that have ICP explicitly enabled via a non-zero icp_port. The vulnerability was reported on February 8, 2026, fixed in the master branch on February 18, 2026, and publicly disclosed on March 25, 2026. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Openwall).

The root cause involves three related weaknesses: CWE-826 (Premature Release of Resource During Expected Lifetime), CWE-416 (Use After Free), and CWE-413 (Improper Resource Locking). Specifically, ACLFilledChecklist correctly locks and unlocks HttpRequest objects, so when given an unlocked request object, an on-stack checklist destroys it upon icpAccessAllowed() return — after which Squid continues to use the now-destroyed request object. The fix, committed as 703e07d, changes icpGetRequest() to return an HttpRequestPointer (a reference-counted smart pointer) instead of a raw pointer, ensuring the HttpRequest object's lifetime is properly managed throughout ICP v2 and v3 query processing. The bug was introduced around 2003–2007 and affects ICP v3 query handling specifically (GitHub Advisory, GitHub Commit).

Successful exploitation allows a remote, unauthenticated attacker to perform a reliable and repeatable Denial of Service attack against the Squid caching proxy service. The attack crashes the Squid process by triggering a heap Use-After-Free condition, disrupting web caching infrastructure and any services that depend on Squid for proxied web access. There is no confidentiality or integrity impact — the vulnerability is limited to availability, with a high impact on the vulnerable system and a low secondary impact on dependent systems (GitHub Advisory, Openwall).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The attack requires no authentication, no user interaction, and has low complexity, but is limited to Squid deployments with ICP explicitly enabled (non-zero icp_port), which reduces the overall attack surface. The EPSS score is approximately 0.0128 (1.28%), reflecting a low but non-negligible probability of exploitation. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify Squid proxy instances with ICP enabled by scanning for open UDP ports (default ICP port is 3130) using tools like Nmap (nmap -sU -p 3130 <target>) or Shodan queries for Squid ICP services.
2. Confirm ICP is active: Send a valid ICP query to the target's icp_port and observe a response, confirming the service is listening and ICP is enabled with a non-zero port.
3. Craft malicious ICP v3 query: Construct a specially crafted ICP v3 request packet targeting the vulnerable doV3Query code path, which triggers the icpGetRequest() function and the subsequent Use-After-Free condition when the HttpRequest object is prematurely destroyed.
4. Send the crafted packet: Transmit the malicious ICP packet to the target's ICP UDP port. The Squid process will attempt to use the freed HttpRequest object, causing a crash.
5. Repeat for sustained DoS: Because the crash is reliable and repeatable, the attacker can continuously send crafted ICP packets to keep the Squid service unavailable (GitHub Advisory, Openwall).

• Network: Unexpected or high-volume UDP traffic to the Squid ICP port (default 3130) from external or untrusted IP addresses; ICP v3 query packets from sources not in the expected peer cache list.
• Logs: Squid cache logs (cache.log) showing repeated crashes or restarts; segmentation fault or heap corruption error messages in system logs (/var/log/syslog, journalctl) associated with the Squid process; debug messages referencing icpGetRequest, doV3Query, or ACLFilledChecklist.
• Process: Unexpected termination and restart of the squid process; monitoring alerts for Squid service unavailability or repeated process crashes in a short time window.

The definitive fix is to upgrade Squid to version 7.5 or later, which resolves the Use-After-Free by using reference-counted smart pointers for HttpRequest lifetime management (GitHub Advisory). For organizations that cannot immediately upgrade, the recommended workaround is to disable ICP support by setting icp_port 0 in the Squid configuration — this eliminates the attack surface entirely. Important: Using icp_access deny rules alone does NOT mitigate this vulnerability. Red Hat has issued multiple errata for RHEL 7–10 (RHSA-2026:6301, RHSA-2026:8119, RHSA-2026:8317, RHSA-2026:8880, and others); Amazon Linux 2 and 2023, Ubuntu, Rocky Linux, AlmaLinux, Mageia, and Fedora have also released updated packages (Red Hat Bugzilla).

The vulnerability was discovered and fixed by Alex Rousskov of The Measurement Factory, and publicly disclosed by Amos Jeffries via the oss-security mailing list on March 25, 2026 (Openwall). Red Hat promptly issued security advisories across multiple RHEL versions within days of disclosure, reflecting the broad deployment of Squid in enterprise Linux environments (Red Hat Bugzilla). Community reaction on platforms like Bluesky noted the vulnerability shortly after disclosure, and multiple Linux distribution security teams (Ubuntu, Rocky Linux, AlmaLinux, Fedora, Mageia, Amazon Linux) released updated packages within weeks.