In June 2024, a serious vulnerability, CVE-2024-40725, was discovered in the Apache HTTP Server, affecting version 2.4.61. The issue is actually a fallout from a partial fix for another vulnerability, CVE-2024-39884. The quick summary? Using certain legacy Apache directives like AddType in your config could accidentally leak your server’s source code—including PHP and other sensitive scripts—if files are accessed in certain ways.

In this post, I’ll explain how this happened, how to spot if you’re affected, and, most importantly, how to fix it.

What’s the Problem? (Simple Version)

Apache HTTP Server is the world’s most popular web server. It supports "handlers" that define how it processes different file types. The AddType directive, for example, lets you tell Apache to treat certain file extensions as a specific content type (like PHP files as PHP scripts).

In Apache 2.4.61, a partial fix for a previous bug (CVE-2024-39884) didn't fully close a loophole. Under certain indirect request cases—like using certain modules or proxy paths—Apache would not apply the correct handler. Instead of running a script (like PHP), Apache might just serve it as raw text. That’s a big problem: users could see your source code, including passwords, secrets, or business logic.

Example Scenario

1. AddType application/x-httpd-php .php
2. User requests http://site.com/proxy/path/index.php, routed strangely with mod_proxy or internal rewriting.

Technical Details (How it Works)

The root of the problem is in the old-style, MIME-type handler configuration with AddType and related directives like AddHandler. Normally, Apache looks up the handler by the extension, and the right module processes the file.

With modules like mod_proxy or mod_negotiation

In some of these cases, the handler lookup was missed, so files got served as plain files—not scripts. If you use AddType to map .php files to application/x-httpd-php, but the PHP handler isn't applied due to this bug—your source code goes out the door, line by line!

Here’s a minimal Apache config showing the dangerous setup

<VirtualHost *:80>
    DocumentRoot "/var/www/html"
    AddType application/x-httpd-php .php
    # Let's say mod_proxy or rewrite interacts oddly here
</VirtualHost>

And with, say, mod_rewrite rewriting to another file behind the scenes

RewriteEngine On
RewriteRule ^/view/(.*)$ /protected/$1.php

A clever request to /view/config could leak /protected/config.php as plain source.

Severity and Impact

- Impact: High – Full source code disclosure, leading to further exploits (DB credentials, sensitive business logic, etc.)
- Attack Complexity: Low to Moderate – Needs an indirect request (rewrites, proxies, etc.), but techniques are well-known.
- Users Affected: Anyone running Apache 2.4.61 with AddType or similar legacy handler configs, especially with mod_rewrite, mod_alias, or mod_proxy in play.

Say your site has /secret.php

<?php
$secret = "db_password_here";
echo "This is secret content!";
?>

In browser, instead of page output

<?php
$secret = "db_password_here";
echo "This is secret content!";
?>

Now your DB password is public.

Remediation & Recommendations

Immediate fix:
Upgrade your Apache server to version 2.4.62
This version contains the complete fix for both CVE-2024-39884 and CVE-2024-40725.

Link:
Apache HTTP Server Downloads

Other mitigations (until you can patch)

- Don’t use AddType or AddHandler for things like PHP—they are legacy, use SetHandler or dedicated FilesMatch configs if possible.
- Use permissions: Ensure .php source code files are never readable except by the web server and the handler (i.e., not world-readable).
- Check your rewrite, alias, and proxy rules: Make sure they don’t allow unintended source file access.

References

- CVE-2024-40725 (MITRE, in progress)
- Apache 2.4.62 Release Notes
- Apache Security Advisory (CVE-2024-39884)
- Discussion on the fix (mailing list)

Final Advice

If you’re running Apache 2.4.61 or earlier—and have *any* legacy MIME-type based mapping (especially for scripts)—patch now.
Legacy directives may seem harmless, but modern configurations (rewrites, proxies, containers) can open up old wounds.

Upgrade, audit your configs, and check your logs for odd accesses.
Don’t give attackers free access to your secrets.

Stay safe and patch smart!

*(If you found this helpful, bookmark it or share it in your sysadmin group. Security is a team effort!)*

Timeline

Published on: 07/18/2024 10:15:02 UTC
Last modified on: 08/22/2024 17:13:09 UTC