CVE-2024-40632

Linkerd is a Kubernetes service mesh that helps manage and secure how services talk to each other. This bug is about Linkerd’s own “shutdown” control endpoint: if an attacker can trick an application behind Linkerd into making a special internal request (via SSRF), they may be able to shut Linkerd down and cause an outage.

Think of it like a security system that has a hidden “power off” switch—usually it’s protected, but if someone can force your app to reach that switch internally, the whole system can be turned off.

This matters if you run Linkerd2/Linkerd on Kubernetes and you have applications managed by Linkerd that are susceptible to SSRF. If there’s no SSRF weakness in your applications, this specific shutdown risk is not expected to be reachable.

Reachability gate: it’s only a risk when both (1) Linkerd is on a vulnerable version and (2) an attacker can exploit SSRF in an application behind Linkerd to reach the shutdown endpoint.

This is a GREEN item because it requires a specific chain: your Linkerd must be on a vulnerable version AND there must be an exploitable SSRF weakness in an app behind it. There is no KEV listing and no public exploit code noted, so there’s no sign of broad, immediate abuse.

Still, treat it as a real availability risk: if you can reach SSRF anywhere in your stack, upgrade Linkerd promptly to remove the shutdown endpoint risk.

1. Confirm exposure in your environment

   • Determine your Linkerd version (Linkerd2/Linkerd) and whether you’re running the edge channel.
   • Find the applications running through Linkerd and check their inputs/behaviors for SSRF patterns (for example: user-supplied URLs/IPs that are fetched by the server).

2. Determine whether the “SSRF → shutdown endpoint” chain is plausible

   • This issue is tied to the presence of SSRF in the Linkerd-managed application.
   • If you have no known SSRF-prone functionality, you likely don’t have the prerequisites for this specific shutdown impact.

3. Upgrade to the fixed version

   • Upgrade Linkerd to edge-24.6.2 (or later) as the fix.
   • There are no known workarounds; upgrading is the primary remediation.

4. Post-upgrade verification

   • Confirm Linkerd components are healthy and restarting behavior has stopped.
   • Verify your workloads can continue normal traffic through Linkerd.

5. If you can’t patch immediately (temporary containment)

   • Focus on reducing SSRF risk in the applications behind Linkerd (tighten URL/IP allow-lists, block internal address ranges, and remove/limit SSRF-capable features).
   • This does not replace upgrading Linkerd, but it reduces the chance that an attacker can reach the shutdown endpoint through SSRF.

6. What to monitor

   • Any sudden Linkerd restarts or service disruptions after suspicious requests.
   • Security signals indicating SSRF attempts or abnormal internal outbound requests from your services.

Severity is low (availability impact only): the weakness is CWE-918 (Server-Side Request Forgery). Mechanism: if an attacker exploits an SSRF vulnerability in a Linkerd-managed application, the attacker can induce the application to make an internal request that reaches Linkerd’s shutdown endpoint (described as localhost:4191/shutdown), causing a denial-of-service by triggering shutdown.

Exploitation/exploitability status: no public exploit code was found on record, and CVE-2024-40632 is not listed in CISA KEV. No exploit maturity beyond the theoretical chain is indicated in the findings.

EPSS: a low predicted likelihood was given (trend flat). Per the verdict, this did not change the GREEN status; KEV/news confirm exploitation were not provided.

Operational implication: the risk is conditional on reachability via SSRF plus a vulnerable Linkerd version; without SSRF in the application layer, the shutdown endpoint is not expected to be reachable by an external attacker.