CVE-2026-32748: Squid has Denial of Service in ICP Response handling
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.
Security readout for executives and security teams
Plain-English summary
Squid proxy servers before 7.5 can be crashed remotely when they handle ICP traffic. The risk is serious because no login or user action is required, but exposure is limited to deployments that explicitly enable ICP with a non-zero icp_port. The supplied sources do not show active exploitation or KEV listing.
Executive priority
Prioritize remediation for Squid proxies with ICP enabled, especially where reachable from untrusted networks. Business impact is service disruption, not data theft according to the supplied CVSS vector. Treat as high priority where proxy availability supports business-critical traffic.
Technical view
The flaw involves premature resource release and heap use-after-free conditions in ICP response handling, mapped to CWE-413, CWE-416, and CWE-826. CVSS 4.0 is 8.7 with network attack vector, low complexity, no privileges, and high availability impact. The vendor states icp_access denial rules do not mitigate it.
Likely exposure
Internet- or partner-reachable Squid instances are exposed only if running a version before 7.5 and configured with icp_port set to a non-zero value. Standard Squid deployments without ICP enabled are not described as affected by the source bundle.
Exploitation context
The advisory says a remote attacker can perform a reliable, repeatable denial-of-service attack against Squid using ICP protocol traffic. The bundle does not cite public exploit activity, CISA KEV inclusion, or exploitation in the wild.
Researcher notes
Focus triage on ICP-enabled Squid before 7.5. The important operational nuance is that access-control denial for ICP queries is explicitly not a mitigation. Evidence in the bundle supports denial of service only; do not infer code execution or confidentiality impact.
Mitigation direction
Upgrade Squid to version 7.5 or later where the bug is fixed.
Apply relevant vendor packages from Red Hat advisories where applicable.
Disable ICP by setting icp_port to zero if ICP is not required.
Do not rely on icp_access denial rules as mitigation.
Check Squid and OS vendor guidance for deployment-specific remediation.
Validation and detection
Inventory Squid versions and identify instances running before 7.5.
Review Squid configuration for non-zero icp_port settings.
Confirm whether ICP is reachable from untrusted networks.
Verify applied vendor errata or package versions after remediation.
Monitor Squid availability logs for unexplained crashes or restarts.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-413: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-413 · source CWE mapping
Improper Resource Locking
Improper Resource Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Use After Free represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Premature Release of Resource During Expected Lifetime
Premature Release of Resource During Expected Lifetime represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.