CVE-2024-25111

What it actually does

Squid versions starting with 3.5.27 and before 6.8 contain an uncontrolled recursion flaw in the HTTP chunked transfer decoder. A remote, unauthenticated client can send a specially crafted chunked-encoded HTTP message through or to the proxy that drives the decoder into excessive recursive processing, exhausting stack or process resources and causing the Squid worker/process to crash or become unavailable. The impact is availability only: it does not directly provide code execution, data theft, or privilege escalation, but it can disrupt proxying, caching, and dependent outbound or inbound web traffic. The issue is network-exploitable, low-complexity, requires no credentials or user interaction, and affects deployments that accept attacker-controlled HTTP traffic using chunked transfer encoding.

Why it matters to the business

Successful exploitation can interrupt web proxy service, blocking users, applications, or downstream services that rely on Squid for internet access, reverse proxying, caching, filtering, or egress control. In organizations where Squid is part of a critical traffic path, a crash can cause broad browsing failures, application outages, monitoring noise, and failover/load-balancer instability. Although it is not listed in CISA KEV and no mature public exploit is indicated in the supplied data, the high CVSS score and elevated EPSS probability mean exposed or internet-reachable Squid instances should be prioritized because exploitation requires only a crafted HTTP request and can be repeated to sustain denial of service.

How an attack unfolds

An attacker first identifies a Squid proxy or service path that will parse HTTP requests or responses using chunked transfer encoding. The attacker then sends a malformed or deeply structured chunked-encoded HTTP message designed to trigger uncontrolled recursion in Squid's chunk decoder. Because the flaw is reachable before authentication in affected configurations that process such traffic, the attacker does not need valid credentials or user interaction. When the vulnerable parser processes the crafted message, recursion consumes process resources or stack depth until Squid crashes, aborts, or stops handling traffic. The attacker can repeat the request, potentially from one or many sources, to keep the proxy unavailable even if a supervisor or service manager restarts it.

How to fix it

Upgrade Squid to version 6.8 or later. For source-based deployments, apply the upstream fix identified as commit 8de6aae86ad83e1684bc0647eb6fd406e34c3176 or the appropriate stable-release patch from the Squid patch archives. There is no vendor-supported workaround for the underlying parser bug. Where immediate patching is not possible, reduce exposure by restricting access to Squid listener ports to trusted networks, placing the proxy behind access controls or load balancers that can drop malformed HTTP traffic, disabling unnecessary public reachability, rate-limiting suspicious clients, and ensuring service supervision/failover is configured; these measures reduce risk but should not be treated as a fix.

How to confirm the fix worked

Confirm the installed Squid version is 6.8 or later, or verify that the upstream patch/commit 8de6aae86ad83e1684bc0647eb6fd406e34c3176 is present in the deployed build. Validate package status using the operating system package manager, container image inventory, or source build metadata, and compare against all running instances rather than only repository versions. Restart Squid after patching and verify the running binary reports the expected version with commands such as `squid -v` or equivalent service inventory tooling. Confirm that externally reachable proxy ports are limited to intended networks. Review recent service uptime and crash logs to ensure no continued instability after remediation.

Typical attack path

1. Discover an exposed Squid proxy, reverse proxy, or network path where Squid processes HTTP traffic.
2. Confirm the service accepts HTTP messages that use Transfer-Encoding: chunked.
3. Send a crafted chunked-encoded HTTP message that triggers excessive recursive processing in Squid's HTTP chunked decoder.
4. Cause the Squid process or worker to crash, abort, or become unresponsive.
5. Repeat the crafted requests to sustain service disruption, especially where automatic restart restores the process after each crash.

How to detect it

To assess possible prior exploitation, correlate Squid service crashes or restarts with inbound or proxied HTTP requests using chunked transfer encoding. Review Squid `cache.log` for fatal errors, assertions, segmentation faults, abnormal termination messages, worker exits, or repeated service startup banners. Review Squid `access.log`, reverse proxy logs, load balancer logs, packet captures, and WAF logs for bursts of HTTP requests containing `Transfer-Encoding: chunked`, malformed chunk sizes, unusual chunk extensions, incomplete chunk terminators, or connections that terminate immediately before a crash. Review host telemetry such as systemd journal, syslog, container runtime logs, kernel logs, and core dump records for `squid` crashes, stack exhaustion, segmentation violations, or rapid restart loops. Because the vulnerability causes denial of service rather than persistent compromise, durable host IOCs may be limited; the strongest signal is timing correlation between crafted chunked HTTP traffic and Squid process failure.

• Transfer-Encoding: chunked
• transfer-encoding: chunked
• /var/log/squid/cache.log
• /var/log/squid/access.log
• /var/spool/squid
• FATAL: Received Segment Violation
• Squid Cache (Version
• squid.service: Main process exited
• squid.service: Failed with result
• segfault at
• traps: squid
• core dumped
• assertion failed
• kid1|
• kid2|

What your security team should do

• Prioritize patching internet-facing, partner-facing, or untrusted-client-facing Squid deployments to version 6.8 or a vendor backport containing commit 8de6aae86ad83e1684bc0647eb6fd406e34c3176.
• Inventory all Squid instances, including containers, appliances, reverse proxy tiers, egress proxies, development environments, and embedded downstream packages.
• Restrict Squid listener access to trusted networks and authenticated paths wherever operationally possible, especially until patching is complete.
• Add monitoring for Squid process crashes, rapid restarts, abnormal 5xx/connection failure spikes, and bursts of malformed chunked HTTP traffic.
• Review historical Squid access logs, cache logs, systemd/syslog entries, and load balancer/WAF logs for signs of unexplained crashes correlated with chunked transfer requests.
• Do not rely on the absence of CISA KEV status as a reason to defer remediation; the vulnerability is remotely reachable, low-complexity, and has a high availability impact.