Join our Newsletter — 33% off our NHI Course

CVE-2021-40438 (Apache HTTP Server-Side Request Forgery (SSRF))

CVE-2021-40438 is a HTTP server-side request forgery (SSRF) vulnerability in Apache Apache. CISA added it to the Known Exploited Vulnerabilities catalogue on 1 December 2021, which means attackers have used it in real attacks. A crafted request uri-path can cause mod_proxy to forward the request to an origin server choosen by the remote user.

How this vulnerability works in Apache HTTP Server

CVE-2021-40438 is dangerous because it lets a remote user influence where Apache forwards a request, turning a public HTTP endpoint into an unintended request initiator. That pattern matters most when the server can reach internal services, management interfaces, or metadata-style endpoints that should never be exposed to the internet.

The core failure is not just “bad input”, it is trust boundary collapse. A crafted uri-path can steer mod_proxy toward a target chosen by the attacker, which means the server may fetch content, relay requests, or disclose responses in ways the operator never intended. For a broader view of SSRF attack patterns, the Web Application Attacks Guide places SSRF alongside other request-manipulation flaws that abuse server-side trust.

Why SSRF is especially harmful on proxy-capable web servers

SSRF becomes more serious when the vulnerable component can reach resources that external users cannot. In that situation, the attacker is not only probing the web server, but also using it as a proxy into internal network zones, backend APIs, and any hostnames or services reachable from the server but hidden from the outside.

This is why SSRF is often a pivot rather than a standalone flaw. In real deployments it can expose internal-only content, interact with service endpoints, or assist follow-on compromise when internal services trust the source of the request. The classic cloud-role-credential abuse pattern is illustrated by Capital One breach 2019, where SSRF was part of a path to privileged cloud access.

How organisations check exposure and prioritise remediation

Exposure assessment starts with knowing which Apache instances run the affected module path, whether they are internet-facing, and whether they can reach sensitive internal targets. Teams should also review reverse proxies, WAF rules, upstream load balancers, and any virtual host or rewrite logic that can influence request routing, because SSRF risk is shaped by network reachability as much as by the vulnerable code path itself.

For patch work and prioritisation, the safest reference points are the vendor advisory and the CISA KEV catalogue, since KEV inclusion means the flaw has been used in real attacks. The general vulnerability-management workflow is well covered in Vulnerability Management Guide, while authoritative record lookup belongs in NIST National Vulnerability Database and CVE Program.

Detection, containment, and post-exploitation review

Detection is usually about spotting outbound requests the server should never make, especially to internal RFC1918 ranges, loopback, link-local metadata services, or unusual hostnames and ports. Logs from the web server, proxy layer, DNS resolver, egress firewall, and cloud network controls can help reconstruct whether the application acted as a request broker.

After patching, review whether the exploitation attempt reached any sensitive target and whether any downstream response may have exposed secrets, tokens, or internal data. If the vulnerable instance could access privileged services, assume the investigation may need to extend beyond the web tier and into the identities or credentials that those services would trust.

Risk and Threat Considerations

SSRF is dangerous because it converts server trust into attacker reach. On a proxy-capable web server, that can expose internal systems, cloud metadata services, or other back-end resources that were never intended to be reachable from the internet.

Failure mechanism: The attacker shapes an allowed request so the server makes a follow-on request to an arbitrary or attacker-influenced destination, bypassing normal network segmentation and request-origin assumptions.

Impact: The result can include internal data disclosure, service enumeration, access to privileged metadata, and a path into higher-value systems that were protected only by network location or implicit trust.

Standards & Framework Alignment

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

OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP ASVS V4 — API and Web Service SSRF is an API and web service request-routing weakness.
Recommendation — Verify server-side request handling and block attacker-controlled upstream destinations.
NIST SP 800-53 Rev 5 SC-7 — Boundary Protection SSRF exploitation depends on crossing trust boundaries into private targets.
SI-10 — Information Input Validation The flaw is triggered by crafted request input that affects server-side routing.
Recommendation — Restrict server egress and separate public request paths from internal services. Validate and constrain request paths before they influence proxy or forwarding logic.
CIS Controls v8 CIS-12 — Network Infrastructure Management Containment relies on limiting outbound network paths from exposed servers.
Recommendation — Segment web servers and deny unnecessary outbound access to internal targets.
OWASP API Security Top 10 API7 — Server Side Request Forgery The term directly names an API security SSRF pattern.
Recommendation — Hunt for request-forwarding paths that let attackers drive server-side outbound calls.

Practitioner Guidance

Why practitioners should care: Treat this class of flaw as an exposure problem, not just a web-input bug. The key question is whether the server can reach anything that should be private, trusted, or operationally sensitive.

What to watch for: Focus on outbound request destinations, unusual redirects, and any application behaviour that changes based on attacker-controlled URLs or paths. If a fix cannot be applied immediately, constrain egress, restrict proxy reachability, and make sure the server cannot talk to internal-only endpoints it does not genuinely need.

Practitioner takeaway: SSRF remediation is strongest when code fixes, network containment, and post-incident review are handled together, because one missing layer can leave the same attack path available.