CVE-2026-32748

High

Published: 26 March 2026

Published

26 March 2026

Modified

26 March 2026

KEV Added

—

Patch

25 March 2026

CVSS Score 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

EPSS Score 0.0038 59.5th percentile

Risk Priority 15 60% EPSS · 20% KEV · 20% CVSS

Summary

CVE-2026-32748 is a high-severity Improper Resource Locking (CWE-413) vulnerability in Squid-Cache Squid. Its CVSS base score is 7.5 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 40.5% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified are NIST 800-53 CM-7 (Least Functionality) and SC-5 (Denial-of-service Protection).

Threat & Defense at a Glance

What attackers do: exploitation maps to Exploit Public-Facing Application (T1190) and 1 other technique. What defenders deploy: see the NIST 800-53 controls recommended below.

Threat & Defense Details

Mitigating Controls (NIST 800-53 r5)AI

SI-2 Flaw Remediation good match

prevent

Applying the vendor patch to Squid version 7.5 directly remediates the heap use-after-free bugs causing DoS crashes from ICP traffic.

CM-7 Least Functionality good match

prevent

Restricting Squid to least functionality by disabling ICP support (icp_port=0) eliminates the vulnerable protocol handling required for exploitation.

SC-5 Denial-of-service Protection good match

prevent

Denial-of-service protections directly limit the impact of remote attacks using crafted ICP traffic to crash the Squid service.

MITRE ATT&CK Enterprise TechniquesAI

T1190 Exploit Public-Facing Application Initial Access

Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.

attack.mitre.org →

T1499.004 Application or System Exploitation Impact

Adversaries may exploit software vulnerabilities that can cause an application or system to crash and deny availability to users.

attack.mitre.org →

Why these techniques?

Remote exploitation of public-facing Squid proxy via crafted ICP traffic directly enables application/system exploitation resulting in service crash (DoS).

Confidence: HIGH · MITRE ATT&CK Enterprise v18.1

NVD Description

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 `icp_port`). This problem _cannot_ be mitigated by denying ICP queries using `icp_access` rules. This bug is fixed in Squid version 7.5.

Deeper analysisAI

CVE-2026-32748 affects Squid, an open-source caching proxy for the web, in versions prior to 7.5. The vulnerability stems from premature release of resources during their expected lifetime, combined with heap use-after-free bugs (mapped to CWE-413, CWE-416, and CWE-826), which occur when handling ICP traffic. This results in a denial-of-service condition, rated at CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

A remote attacker can exploit this vulnerability by sending crafted ICP protocol traffic to a vulnerable Squid instance, enabling a reliable and repeatable denial-of-service attack that crashes the service. Exploitation requires the target Squid deployment to explicitly enable ICP support by configuring a non-zero icp_port; deployments without ICP enabled are unaffected. No authentication or user interaction is needed.

The issue is fixed in Squid version 7.5, as detailed in the official patch commit (https://github.com/squid-cache/squid/commit/703e07d25ca6fa11f52d20bf0bb879e22ab7481b) and security advisory (https://github.com/squid-cache/squid/security/advisories/GHSA-f9p7-3jqg-hhvq). Notably, mitigation via icp_access rules to deny ICP queries is ineffective. Additional details are available in the oss-security mailing list announcement (http://www.openwall.com/lists/oss-security/2026/03/25/3).