Is CVE-2021-40438 (Apache HTTP Server-Side Request Forgery (SSRF)) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-40438 to its Known Exploited Vulnerabilities catalogue on 1 December 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. A crafted request uri-path can cause mod_proxy to forward the request to an origin server choosen by the remote user.

What active exploitation means for this CVE

For CVE-2021-40438, the question is not just whether a flaw exists, but whether attackers are already using it in the wild. CISA’s KEV listing is the practical signal that changes the response posture: it means this SSRF issue should be treated as an active exposure, not a theoretical one. For background on how KEV is used to prioritise exploited flaws, see the Zero-Day and Exploited Vulnerabilities Guide and CISA’s Known Exploited Vulnerabilities Catalog.

SSRF matters here because the vulnerable server can be induced to make an outbound request on the attacker’s behalf. Even when the direct effect looks limited to request forwarding, SSRF often becomes a bridge to internal services, metadata endpoints, or trust zones the attacker could not reach directly. The key security question is therefore not only “is the server vulnerable?” but “what internal destinations can be reached through that request path?”

How Apache mod_proxy changes the exposure

The weakness is rooted in request handling, not in user authentication or login logic. If an attacker can shape the request uri-path so that mod_proxy forwards it to an origin server they choose, the server becomes a proxying oracle. That can expose internal systems, sensitive network paths, and sometimes cloud metadata or admin interfaces if outbound access is not tightly controlled.

This makes the issue especially relevant where Apache sits in front of other application tiers or internal services. The exploitation path often depends on how proxy rules, URL parsing, name resolution, and network egress are configured. A “small” SSRF bug can become high impact when the front-end server can reach internal-only resources that were assumed to be unreachable from the internet.

For a practical pattern library on this attack class, the SSRF Prevention Guide and the Capital One breach 2019 show why proxy-mediated request forwarding deserves urgent attention even when the flaw looks narrow.

What to do first if you rely on Apache HTTP Server

Start by confirming whether any Apache instances are exposed to untrusted request traffic and whether they use mod_proxy in a way that can reach internal or privileged destinations. Then validate the vendor advisory and CISA KEV entry for the exact remediation path, rather than relying on memory or generic hardening checklists. The first operational priority is to remove exploitable reach, then verify whether the affected service could have been used as a pivot.

If patching or configuration change must wait, reduce the reachable attack surface immediately: constrain proxy targets, tighten egress, and block access to internal address ranges and metadata services where feasible. The most important judgement is whether the server can reach anything that would matter if an attacker could control the forwarded destination.

For teams managing many exposed services, the right companion workflow is vulnerability triage and verification, not only patch deployment. The Vulnerability Management Guide is useful here because exploited flaws require prioritisation, evidence of remediation, and post-fix validation, not just ticket closure.

Risk and Threat Considerations

SSRF becomes materially worse when the proxy can reach internal services, cloud metadata, or administrative interfaces that were never meant to be internet-reachable. In that situation, the flaw is not just a request-routing issue, it is a trust-boundary break that can expose credentials, tokens, or internal-only application functions.

Failure mechanism: The attacker supplies a crafted request path that makes mod_proxy forward traffic to an attacker-chosen destination, bypassing the intended destination controls and potentially reaching internal resources.

Impact: The exposed server can be used for internal reconnaissance, service abuse, metadata retrieval, or credential theft, and CISA’s KEV inclusion means the flaw should be treated as actively exploited risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Exploit-in-the-wild flaws need rapid identification and remediation.
Recommendation — Prioritise, patch, and verify this exploited CVE through continuous vulnerability management.
NIST CSF 2.0	PR.PS-05 — Mechanisms to achieve resilience and recovery are implemented	Exploitability and reachability depend on resilient, bounded service design.
Recommendation — Limit proxy reach and reduce exposed pathways that could be abused during exploitation.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This KEV-listed vulnerability requires prompt remediation and validation.
	SC-7 — Boundary Protection	SSRF abuse depends on weak trust boundaries and outbound reachability.
	AC-4 — Information Flow Enforcement	Forwarding to attacker-chosen destinations is an information-flow control problem.
Recommendation — Remediate the flaw quickly and confirm the vulnerable Apache deployment is no longer exposed. Restrict outbound destinations and enforce boundary controls around proxy traffic. Enforce destination allowlists and block flows to sensitive internal targets.

Practitioner Guidance

What to verify: Confirm whether any Apache instance with mod_proxy enabled can reach internal networks, loopback targets, cloud metadata endpoints, or sensitive upstream services. If it can, assume the blast radius is larger than the public-facing service itself.

Decision rule: If the vulnerable host is internet-facing and proxying to internal resources, prioritise mitigation and compromise assessment before you spend time debating whether the exploitation you have seen is “likely” or “confirmed”. Active exploitation changes the order of operations.

What good looks like: The server cannot proxy to arbitrary destinations, outbound destinations are tightly constrained, and you have evidence that no suspicious internal requests or unexpected upstream lookups occurred during the exposure window.

Practitioner takeaway: For exploited SSRF issues, the real unit of risk is the server’s ability to reach something sensitive on behalf of the attacker, not the visibility of the original HTTP request alone.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org