CVE-2024-45802: Squid-cache Squid DoS Vulnerability

CVE-2024-45802 Overview

CVE-2024-45802 affects Squid, an open source caching proxy supporting HTTP, HTTPS, FTP, and other protocols. The vulnerability stems from three related defects: improper input validation, premature release of a resource during its expected lifetime, and missing release of a resource after its effective lifetime. A trusted upstream server can exploit these conditions to trigger a denial of service against every client routed through the proxy. The Squid project addressed the issue in the default build configuration of version 6.10. Squid is widely deployed as a forward and reverse proxy in enterprise, telecommunications, and content delivery environments, making the availability impact significant for downstream services.

Critical Impact

A malicious or compromised upstream server can disrupt proxy availability for all clients, causing widespread service interruption across networks that depend on Squid for web access or caching.

Affected Products

• Squid versions prior to 6.10 (default build configuration)
• Debian LTS distributions shipping affected Squid packages
• NetApp products bundling vulnerable Squid components

Discovery Timeline

• 2024-10-28 - CVE-2024-45802 published to the National Vulnerability Database
• 2025-11-03 - Last updated in NVD database

Technical Details for CVE-2024-45802

Vulnerability Analysis

The flaw is a network-reachable denial of service requiring no authentication or user interaction. An attacker controlling or compromising a server that Squid contacts on behalf of clients can send crafted responses that exercise the defective input validation and resource-handling paths. Because Squid sits in the request path for all proxied traffic, an outage propagates to every dependent client. The Common Weakness Enumeration classifies the primary defect as [CWE-20] Improper Input Validation, combined with resource lifecycle errors that cause the proxy process to consume or release resources incorrectly.

Root Cause

Three distinct defects combine to produce the DoS condition. First, Squid fails to validate specific server-supplied input before processing it. Second, the code prematurely releases a resource that is still expected to be live, producing dangling state. Third, in other code paths, a resource is never released after its effective lifetime ends, producing a leak. Together these defects allow a server response to either crash the worker, exhaust resources, or destabilize internal state.

Attack Vector

The attacker needs control of an upstream HTTP, HTTPS, or FTP server that a Squid client requests. When a client routes a request through the vulnerable proxy to that server, the server returns a crafted response that triggers the defective code path. The attack does not require credentials, prior access to the proxy host, or any client-side interaction. Repeated or sustained malicious responses produce a persistent service outage. Refer to the Squid GitHub Security Advisory GHSA-f975-v7qw-q7hj for vendor technical details.

Detection Methods for CVE-2024-45802

Indicators of Compromise

• Unexpected Squid worker crashes, restarts, or assertion failed entries in cache.log
• Sudden growth in Squid memory or file-descriptor usage without matching client load
• Repeated upstream responses from the same origin preceding proxy instability
• Client-side connection failures or HTTP 502/504 errors clustered in time

Detection Strategies

• Compare the installed Squid version against 6.10 using package inventory tooling and flag hosts below the fixed release
• Monitor Squid process metrics (RSS, open file descriptors, CPU) for anomalous spikes correlated with upstream traffic from specific origins
• Alert on repeated restarts of the squid service within short windows using systemd or process supervisor logs

Monitoring Recommendations

• Ingest access.log and cache.log into a centralized logging or SIEM platform and build dashboards for error rates, worker restarts, and upstream response anomalies
• Track outbound destinations from Squid and correlate crashes with the originating upstream server to identify the malicious endpoint
• Set availability monitoring on the proxy listener and upstream-facing interfaces to detect partial failures before clients report outages

How to Mitigate CVE-2024-45802

Immediate Actions Required

• Upgrade Squid to version 6.10 or later using the default build configuration
• Apply distribution patches such as the Debian LTS update on affected Debian systems
• Review the NetApp Security Advisory for product-specific fix availability
• Restart the squid service after upgrading and verify the version with squid -v

Patch Information

The Squid maintainers fixed the vulnerability in the default build configuration of Squid 6.10. Operators compiling Squid from source should rebuild against the patched release and confirm no overridden build flags re-enable the affected code paths. Distribution maintainers, including Debian and NetApp, have published advisories with backported fixes for supported package streams.

Workarounds

• Restrict the set of upstream destinations Squid can contact using acl and http_access rules to reduce exposure to untrusted servers
• Place Squid behind egress filtering that blocks connections to unknown or low-reputation origins until patching is complete
• Configure process supervision to restart Squid automatically on crash as a stopgap, accepting that this only limits, not eliminates, the outage

# Verify installed Squid version after upgrade
squid -v | head -n 1

# Debian/Ubuntu upgrade example
sudo apt-get update && sudo apt-get install --only-upgrade squid
sudo systemctl restart squid
sudo systemctl status squid