---
Introduction
Apache HTTP Server is one of the most popular web servers worldwide, essential for hosting millions of websites. But like all complex software, it can have vulnerabilities. CVE-2024-38475 is a critical security issue in Apache HTTP Server (up to version 2.4.59) that could allow attackers to access files, expose source code, or even execute code, all by abusing mod_rewrite rules in specific configurations. In this post, we'll break down how this vulnerability works, show an example with code, describe how it can be exploited, and explain fixes.
What is CVE-2024-38475?
This vulnerability revolves around improper escaping of output in mod_rewrite. When certain rewrite rules are used at the server context (like in the main Apache config, not just in .htaccess), and especially when these substitutions start with variables or backreferences, attackers can craft URLs that access files you never meant to serve directly.
Leak source code
The affected component is the mod_rewrite module, and all versions up to 2.4.59 are affected.
How the Bug Works
The key problem is that mod_rewrite, in certain cases, doesn’t properly escape user input. When a rewrite rule substitution begins with a variable or a backreference (like $1), and is used in a server context, the mapping to filesystem paths can be manipulated.
Vulnurable Apache RewriteRule
Suppose you have this Apache rule in your main config (or VirtualHost, not just in .htaccess):
RewriteEngine on
RewriteRule ^/(.+)/foo\.php$ /$1/bar.php [L]
Here, a request like /some/path/foo.php would be rewritten to /some/path/bar.php.
What’s dangerous?
If an attacker can control $1, and mod_rewrite doesn’t escape it properly, they might craft a URL like:
/../../../../etc/passwd/foo.php
This could be mapped to /../../../../etc/passwd/bar.php, which after resolution could let the attacker access sensitive files outside your document root, such as /etc/passwd, or other files you didn't mean to expose.
`
http://yourserver/../../../../../var/www/secret-config/foo.php
RewriteRule Processes the Request:
- The regex ^/(.+)/foo\.php$ matches /../../../../../var/www/secret-config/foo.php
- $1 becomes ../../../../../var/www/secret-config
- Substitution is ../../../../../var/www/secret-config/bar.php
Apache tries to serve the rewritten file
- If file permissions allow, /var/www/secret-config/bar.php will be served
Outcome: The attacker can now see or execute files that were never meant to be public.
Substitutions at *server context* beginning with backreference or variable are dangerous.
- Output is not escaped (/ is not protected), so crafted URLs can "jump" directories.
- Exploit lets attacker map URLs to files that are not otherwise reachable, breaking your assumptions of web root enforcement.
Unsafe rules will no longer work as before.
- To regain old behavior, you must use the new UnsafePrefixStat rewrite flag and ensure your substitutions are safe.
Example Fix
# Safe after patch: avoids untrusted variables at start
RewriteRule ^/(.+)/foo\.php$ /safe/$1/bar.php [L]
# Or: If you have reviewed and constrained the input
RewriteRule ^/(.+)/foo\.php$ /$1/bar.php [L,UnsafePrefixStat]
Upgrade Apache to 2.4.60 or later.
- Check all RewriteRules in global/server context for patterns starting with backreferences or variables.
References
- Apache HTTPD Security Advisory - CVE-2024-38475
- mod_rewrite Documentation
- Official Commit Fixing CVE-2024-38475
- Security Fix Release Announcements
Conclusion
CVE-2024-38475 is a powerful reminder that seemingly simple configuration patterns can have serious security implications. Check your Apache rewrite rules, upgrade to the latest version, and review any substitutions that allow untrusted user input at the start.
It’s not just about writing code—it’s about defending users, data, and infrastructure from attackers who look for every possible loophole. Don’t let untrusted paths become your undoing!
*Stay safe, patch quickly, and review your rewrite rules!*
Timeline
Published on: 07/01/2024 19:15:04 UTC
Last modified on: 07/12/2024 14:15:15 UTC