CVE-2024-39573 - How An SSRF in Apache mod_rewrite Can Lead to a Proxy Disaster

Apache HTTP Server is one of the most popular web servers on the planet. But even giants can have weak spots. If you’re running Apache v2.4.59 or earlier, a nasty vulnerability was uncovered (CVE-2024-39573) that can let attackers use your server as a sneaky proxy with a simple misconfiguration in mod_rewrite.

Let’s break it down in plain language, with examples, suggestions, and a peek at the internals.

What Is CVE-2024-39573?

CVE-2024-39573 is a security vulnerability affecting the way Apache's mod_rewrite interacts with mod_proxy. If you use RewriteRules to redirect requests to certain URLs, it's possible that attackers can trick your server into connecting to internal or even external addresses. This can be exploited for SSRF (Server-Side Request Forgery), which means your server can be forced to make requests to resources it shouldn't.

The Core Issue

When you write a RewriteRule that sends traffic to a URL like http(s)://, Apache with both mod_rewrite and mod_proxy installed can unexpectedly pass that request on for proxying—even if you didn’t mean to. This lets attackers control where the rewrite points, creating a path for SSRF attacks or “open proxy” abuse.

The fix (in v2.4.60) is to require a new keyword ([P] for proxy) in the RewriteRule before Apache will send rewritten hits to the proxy module.

Let’s say your Apache config looks like this

# VULNERABLE: This allows any rewritten URL to be proxied!!

RewriteEngine On
RewriteRule ^/api/(.*)$ http://internal-api.local/$1 [L]

# This looks like a simple redirect, but...

If mod_proxy is enabled, an attacker could call

GET /api/http://evil.com/

And Apache will rewrite it to

http://internal-api.local/http://evil.com/

But more complex rule patterns (like using backreferences or wildcards) can make this SSRF practical and dangerous.

Simple vulnerable config

RewriteEngine On
# Dangerous: passes all URLs starting with /proxy/ to whatever URL is in the path
RewriteRule ^/proxy/(.*) http://$1 [L]

Exploit example:

Suppose your Apache listens on https://victim.com. An attacker sends

curl "https://victim.com/proxy/localhost:808/admin"

The rewrite transforms this into a proxy request to http://localhost:808/admin.

If you also support http(s) backreferences

curl "https://victim.com/proxy/http://169.254.169.254/latest/meta-data/"

*(This is the AWS metadata address, often targeted by attackers for cloud instance credentials)*

How To Fix

Upgrade to Apache 2.4.60 or later!
This release requires RewriteRules to include the [P] flag before mod_proxy will handle rewritten URLs, adding an intentional barrier.

Example: Secure RewriteRule

# Specify [P] only for rules that should be proxied, and restrict what can be matched
RewriteEngine On
RewriteRule ^/internal/(.+)$ http://safe-backend.local/$1 [P,L]

Official Apache Security Advisory (CVE-2024-39573):

https://httpd.apache.org/security/vulnerabilities_24.html#CVE-2024-39573

- mod_rewrite Documentation
- mod_proxy Documentation

Summary Table

| Action | Secure? | Description |
|----------------------|:-----------:|--------------------------------------------------|
| Upgrade to 2.4.60 | ✅ | Fixes CVE-2024-39573 by requiring [P] for proxy rules |
| Use [P] carefully | ✅ | Mark proxy rewrites intentionally |
| Variable user input | ❌ | Never let user-controlled input become host/URL |
| Unprotected mod_proxy| ❌ | Don’t enable if you don’t need |

Conclusion

This vulnerability shows how tricky and dangerous “unexpected features” in widespread software can be. Apache is incredibly flexible, but this time, that flexibility was used against it. Patch up, check your configs, and keep your web servers out of the proxy crosshairs!

Timeline

Published on: 07/01/2024 19:15:05 UTC
Last modified on: 07/12/2024 14:15:16 UTC