CVE-2024-38475: Apache HTTP Server mod_rewrite RCE and Source Code Disclosure Explained

CVE-2024-38475 is one of the most important Apache HTTP Server vulnerabilities to emerge from the 2024 research into what Orange Tsai called “Confusion Attacks.” At first glance, its description sounds straightforward: a flaw in mod_rewrite can allow remote attackers to reach filesystem locations that were never intended to be accessible through a URL, potentially resulting in source code disclosure or code execution.

The underlying problem is considerably more interesting.

CVE-2024-38475 is not simply a conventional path traversal bug where an attacker inserts ../ sequences into a request. It exposes a deeper ambiguity in the way Apache HTTP Server interprets the result of a rewrite operation. Depending on context, the same value can be treated as a URL, a filesystem path, or an object that still needs to be mapped relative to DocumentRoot.

When attacker-controlled backreferences or variables appear at the beginning of a server-level RewriteRule substitution, that ambiguity can cause Apache to resolve a request against filesystem locations outside the administrator’s intended web namespace.

The Apache Software Foundation describes the vulnerability as affecting Apache HTTP Server 2.4.59 and earlier, specifically server-context substitutions whose first segment is derived from a backreference or variable. Apache fixed the vulnerability in 2.4.60, released on July 1, 2024. (Apache HTTP Server)

The vulnerability later became significantly more urgent. On May 1, 2025, CISA added CVE-2024-38475 to its Known Exploited Vulnerabilities Catalog, confirming evidence of exploitation in the wild. (CISA)

As of August 2026, upgrading merely to 2.4.60 should no longer be considered the ideal remediation target. Apache currently recommends 2.4.68, released June 8, 2026, over previous releases. (Apache HTTP Server)

That combination—an architectural vulnerability, widespread deployment, configuration-dependent exploitation, and confirmed real-world abuse—is what makes CVE-2024-38475 worth understanding in depth.

CVE-2024-38475 at a Glance

項目	詳細
CVE	CVE-2024-38475
製品	Apache HTTP Server
コンポーネント	mod_rewrite
脆弱性クラス	Improper output escaping / filesystem mapping confusion
CWE	CWE-116
影響を受けるバージョン	Apache HTTP Server 2.4.0 through 2.4.59
First fixed version	Apache HTTP Server 2.4.60
Current recommended Apache release	2.4.68 as of August 2026
Authentication required	Potentially none
User interaction	なし
Major consequences	Arbitrary local-file exposure, source code disclosure, secret leakage, and possible RCE chains
CISA KEV	Yes, added May 1, 2025
Primary researcher	Orange Tsai of DEVCORE
Key mitigation mechanism	Reject unsafe leading-variable/backreference substitutions by default; UnsafePrefixStat explicitly restores the old behavior

NVD currently records a CVSS v3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, corresponding to a score of 9.1. (NVD)

One caveat is important: CVSS scores found in third-party advisories are not always identical. For example, SonicWall assigned a 9.8 score to the CVE in the context of affected SMA appliances. That appliance-specific impact should not automatically be applied to every generic Apache deployment. (SonicWall PSIRT)

What Is mod_rewrite?

mod_rewrite is one of Apache HTTP Server’s most powerful—and notoriously complex—modules.

Administrators use it to transform incoming URLs according to regular expressions and conditions. A basic rule looks like:

RewriteEngine On
RewriteRule "^/old/(.*)$" "/new/$1" [L]

The first expression matches the incoming URL path. The second expression is the substitution.

Backreferences such as:

$1
$2
...

contain portions captured by the RewriteRule regular expression.

Backreferences originating from RewriteCond expressions are represented as:

%1
%2
...

Apache also allows server variables and environment information to participate in rewriting.

This flexibility means a rewrite result may eventually represent several fundamentally different things:

• another URL path;
• an external redirect;
• a proxy target;
• a filesystem path;
• a new URI that Apache sends through another mapping phase.

Apache’s documentation explicitly notes that a substitution beginning with / can be interpreted as a filesystem path in server or virtual-host context if its first component exists on the filesystem. (Apache HTTP Server)

That historical flexibility is central to CVE-2024-38475.

The Architectural Problem Behind CVE-2024-38475

Orange Tsai’s Apache research focused less on isolated memory-safety bugs and more on what happens when different Apache modules assign different meanings to the same internal state.

He grouped the resulting problems into three categories:

1. Filename Confusion
2. DocumentRoot Confusion
3. Handler Confusion

The research ultimately produced multiple Apache CVEs, including CVE-2024-38474, CVE-2024-38475, CVE-2024-38476, CVE-2024-39573 and several others. (Orange Tsai)

CVE-2024-38475 is closely associated with DocumentRoot Confusion, although another primitive—Filename Confusion—helps explain why some practical exploitation patterns become much more powerful.

The fundamental question is surprisingly simple:

いつ mod_rewrite produces a string beginning with /, is that string a URL path under the website, or is it an absolute path on the operating system?

Historically, Apache sometimes had to guess.

Those guesses can become dangerous when the beginning of the rewritten value originates from the request.

Understanding DocumentRoot Confusion

Imagine an Apache server configured like this:

DocumentRoot "/var/www/html"

RewriteEngine On
RewriteRule "^/html/(.*)$" "/$1.html"

An administrator probably intends:

/html/about

to resolve to something equivalent to:

/var/www/html/about.html

From the administrator’s perspective, / in the substitution feels like the root of the website.

But at certain points inside Apache’s rewrite and filename translation process, a leading / can also look like the beginning of an absolute filesystem path.

Orange Tsai demonstrated that Apache could perform filesystem checks involving both the apparent absolute path and the path beneath DocumentRoot. (Orange Tsai)

Normally, the .html suffix in the example still creates an important constraint.

An attacker cannot simply request:

/etc/passwd

because the resulting rewrite might become logically equivalent to:

/etc/passwd.html

which probably does not exist.

But another Apache rewriting behavior makes those suffixes less reliable than administrators might assume.

Filename Confusion and the Question Mark Problem

During rewriting, Apache historically treated rewrite results in ways normally associated with URLs, even when the value ultimately represented a filesystem path.

One particularly important behavior involved the question mark.

A question mark separates a URL path from its query string:

/page.php?id=123
         ^

When the rewrite engine interprets a filesystem-like string with URL semantics, a question mark can cause the remainder of that string to move into query-string handling instead of remaining part of the filename.

Consider a simplified rule:

RewriteRule "^/profile/(.+)$" "/srv/users/$1/profile.yml"

The administrator expects the request always to end up targeting a file called:

profile.yml

But Orange Tsai demonstrated that carefully positioned encoded question marks could affect how the rewritten result was divided between the filename and query string.

The important security lesson is not merely “%3F is dangerous.”

The deeper problem is that security controls relying on an appended suffix become unreliable if one processing stage interprets the rewritten value as a URL while another later treats it as a filesystem path.

Apache’s own technical documentation confirms that encoded characters in incoming paths are decoded before normal RewriteRule pattern processing, which is one reason transformations involving encoded delimiters deserve special attention. (Apache HTTP Server)

Combining the Two Confusions

The exploitation model becomes much clearer when Filename Confusion and DocumentRoot Confusion are considered together.

Suppose a vulnerable server essentially performs:

attacker input
      ↓
RewriteRule capture
      ↓
attacker-controlled backreference
      ↓
substitution looks like /something.ext
      ↓
Apache performs filesystem-related interpretation
      ↓
unexpected absolute location becomes reachable

Now add the possibility of interfering with a suffix appended by the rule:

expected:

/controlled-path.html

possible effective interpretation:

/controlled-path

Suddenly, a RewriteRule that looked constrained may become a generic mechanism for reaching files outside the intended website tree.

This explains the Apache advisory’s wording.

Apache says CVE-2024-38475 can allow an attacker to map URLs to filesystem locations that:

are permitted to be served by the server but are not intentionally/directly reachable by any URL.

The affected pattern is specifically described as substitutions in server context where a backreference or variable is used as the first segment of the substitution. (Apache HTTP Server)

That qualification matters enormously.

Not Every Apache Server Is Automatically Exploitable

One of the easiest mistakes when discussing CVE-2024-38475 is to write:

Apache 2.4.59 is vulnerable, therefore any remote attacker can execute arbitrary commands on Apache 2.4.59.

That is incorrect.

Version exposure is only one piece of the vulnerability.

Practical exploitation typically requires an unsafe rewrite configuration that exposes attacker-controlled data to the problematic translation behavior.

The most interesting configurations are generally server-scoped or virtual-host-scoped rules where the rewritten substitution begins with something derived from the request.

Conceptually dangerous patterns include rules shaped like:

RewriteRule "^/(.*)$" "/$1"

or:

RewriteRule "^/content/(.*)$" "/$1.html"

or a rule where the first significant path component originates from a server variable:

RewriteRule ... "%{SOME_VARIABLE}/..."

The exact exploitability of any rule depends on considerably more than its appearance, including:

• Apache version;
• rule context;
• URL decoding;
• filesystem layout;
• existing files and directories;
• filesystem permissions;
• aliases and symlinks;
• enabled Apache handlers;
• MIME configuration;
• backend applications;
• additional rewrite rules;
• whether exposed content is executable or merely readable.

This is why configuration review is essential.

A version scanner can tell you that a server may contain the vulnerable code.

It cannot necessarily tell you whether the rewrite configuration turns that code into an exploitable path.

Why Source Code Disclosure Is Possible

Suppose Apache unexpectedly resolves a rewritten URL to an application file that was never supposed to be served directly.

The obvious example is a server-side script.

Under normal conditions, requesting:

/index.php

might cause Apache to pass that file to PHP.

The client receives:

<html>
...
</html>

not:

<?php
$db_password = "...";
?>

But Apache’s request-processing architecture includes several independent stages: filename mapping, MIME type selection, handler selection, internal redirects and response generation.

If a file becomes reachable through an unintended mapping path, it may be processed differently from the route the administrator expected.

The result can sometimes be source code disclosure instead of script execution.

That source code may contain considerably more valuable information than the application UI exposes:

database credentials
API keys
OAuth secrets
internal hostnames
cloud credentials
encryption keys
session-signing keys
filesystem locations
administrator endpoints
debug settings

Source disclosure therefore frequently becomes a stepping stone rather than the final impact.

Arbitrary File Access Can Be Worse Than Source Disclosure

The ability to expose files outside DocumentRoot dramatically increases the number of interesting targets.

A hypothetical Linux server might contain:

/etc/application/config.yml
/var/lib/app/secrets.json
/opt/service/.env
/home/service/.ssh/config
/var/log/application.log

Whether Apache can actually expose any of these depends on the server’s effective filesystem permissions and configuration.

That last part is important.

CVE-2024-38475 does not magically bypass Unix permissions.

If Apache runs as:

wwwデータ

そして wwwデータ cannot read a file, the rewrite confusion does not inherently grant it root filesystem privileges.

The practical security boundary becomes:

What can the Apache worker already read, execute, interpret or pass to another handler?

On real application servers, that set may unfortunately include highly sensitive files.

From File Disclosure to Remote Code Execution

The phrase RCE in the CVE description deserves careful interpretation.

There are several ways an unintended filesystem mapping can ultimately produce code execution.

Direct Script Execution

If the unexpected target is a script in a directory where Apache is configured to execute CGI or another dynamic handler, reaching the file may cause it to run rather than merely be downloaded.

Local Application Gadgets

A local endpoint or script that was considered safe because it was not publicly routable may become accessible.

That script may itself contain dangerous functionality.

Examples could include:

development utilities
maintenance scripts
administrative CGI programs
diagnostic handlers
migration endpoints
internal proxy helpers

Once exposed to attacker-controlled HTTP input, such a component can become an RCE gadget.

Secret Disclosure Followed by Application Exploitation

This is one of the most interesting models.

CVE-2024-38475 may first disclose:

application secret

That secret is then used to construct:

trusted or signed application data

which triggers another application-level behavior leading to code execution.

In that case:

CVE-2024-38475
      ↓
secret disclosure
      ↓
application security boundary defeated
      ↓
deserialization / privileged action / authenticated functionality
      ↓
RCE

The Apache vulnerability does not need to be a direct command-injection primitive to produce a full remote compromise.

The Redmine Example

Orange Tsai demonstrated why this distinction is important using a Redmine environment.

His research showed how an unsafe RewriteRule could interact with filesystem paths and symbolic links to reach a Redmine secret file outside the expected web namespace.

The relevant application secret was used by the Ruby on Rails application for cryptographic operations.

Once an attacker knows a sufficiently powerful application secret, the security consequences may extend well beyond simple disclosure.

Orange’s demonstration chained the exposed secret into Ruby on Rails behavior and ultimately achieved remote code execution through application-level deserialization. (Orange Tsai)

This is a valuable model for understanding CVE-2024-38475:

Rewrite confusion
       ↓
unexpected local file access
       ↓
application secret disclosure
       ↓
defeat application trust boundary
       ↓
code execution

Calling the vulnerability “arbitrary file read only” can therefore underestimate its impact.

Calling it “instant Apache RCE everywhere” overstates it.

The real answer lies in the surrounding environment.

Why CVE-2024-38475 Became More Important in 2025

CVE-2024-38475 was disclosed in July 2024.

For months, many defenders primarily encountered it as one entry in a large cluster of Apache vulnerabilities fixed in 2.4.60.

That changed in 2025.

CISA added CVE-2024-38475 to its Known Exploited Vulnerabilities catalog on May 1, 2025, with a federal remediation deadline of May 22, 2025. (NVD)

This matters because KEV inclusion is based on evidence that a vulnerability has been exploited in the wild—not merely that public proof-of-concept code exists.

The exploitation story became particularly visible through SonicWall SMA 100 appliances.

CVE-2024-38475 and SonicWall SMA

SonicWall incorporated Apache HTTP Server into its SMA 100 Series appliances.

A vulnerable Apache version combined with appliance-specific rewrite rules created a practical exploitation path for CVE-2024-38475.

SonicWall’s advisory lists the affected SMA 100 products as:

• SMA 200
• SMA 210
• SMA 400
• SMA 410
• SMA 500v

Versions 10.2.1.13-72sv and earlier were affected by the relevant vulnerability set, while CVE-2024-38475 was addressed in 10.2.1.14-75sv and later. (SonicWall PSIRT)

The appliance illustrates an important point about infrastructure CVEs.

You may not operate a traditional server that your administrators think of as “an Apache web server.”

But Apache may be embedded inside:

VPN appliances
management consoles
security products
network gateways
NAS systems
enterprise applications
virtual appliances

Vulnerability management therefore needs software-component visibility, not simply asset branding.

How the SonicWall Exploitation Worked Conceptually

watchTowr analyzed an SMA appliance and identified a vulnerable rewrite configuration that could be combined with CVE-2024-38475’s path interpretation behavior.

In the appliance context, the vulnerability could expose local files readable by the Apache process.

The researchers showed that sensitive appliance data could be retrieved, including session-related material.

They subsequently combined the resulting information with CVE-2023-44221, a separate command-injection vulnerability, to demonstrate a pre-authentication path toward full system compromise. (watchTowr Labs)

The important attack pattern is:

Unauthenticated HTTP request
          ↓
CVE-2024-38475
          ↓
sensitive local file exposure
          ↓
session / authentication material
          ↓
privileged context obtained
          ↓
second vulnerability
          ↓
command execution

The key phrase is second vulnerability.

This again shows why “CVE-2024-38475 RCE” should be interpreted in context.

Active Exploitation Is Not Merely Theoretical

SonicWall later explicitly characterized CVE-2024-38475 exploitation against affected SMA systems as active exploitation.

Its security guidance says the vulnerability could enable unauthorized access to sensitive session files and facilitate administrator session hijacking. (SonicWall)

Google Threat Intelligence Group later discussed campaigns involving SonicWall SMA appliances and noted that CVE-2024-38475 could be used against SMA 100 systems to exfiltrate SQLite databases containing sensitive material such as account data, session tokens and OTP-related information. Google did not, however, attribute every observed campaign or intrusion chain to CVE-2024-38475 itself. (グーグル・クラウド)

That distinction is useful for defenders:

Evidence of exploitation exists.

But that does not mean every compromise involving an affected appliance used this exact vulnerability.

Why RewriteRules Are a Security Boundary

Developers frequently think about:

application code

as the primary security boundary.

Operations teams may think about:

firewalls
authentication
reverse proxies

But rewrite configuration is often effectively executable routing logic.

Consider what a RewriteRule can influence:

incoming URL
    ↓
local filesystem
backend service
proxy target
application handler
redirect target
content type

That means a single permissive rule can dramatically change a web server’s attack surface.

Apache itself warns that mod_rewrite should be treated carefully and recommends simpler alternatives where possible because rewrite configurations can become confusing and fragile. (Apache HTTP Server)

CVE-2024-38475 turns that operational complexity into a concrete security issue.

Which RewriteRules Should You Audit?

A practical audit should begin with server and virtual-host configurations.

Look for:

RewriteEngine On

followed by RewriteRule directives.

Then prioritize rules whose substitution begins with attacker-derived data.

For example, examine configurations shaped conceptually like:

RewriteRule "^/something/(.*)$" "/$1"

or:

RewriteRule "^/(.+)$" "$1"

or:

RewriteRule ... "%1..."

or substitutions where an environment/server variable occurs before a known-safe literal prefix.

Do not mechanically classify every such rule as exploitable.

Instead ask:

1. Can the attacker control the relevant capture?
2. Does the substitution run in server or virtual-host context?
3. Could the expanded first component match a filesystem path?
4. Does the rule append an extension or suffix that might be affected by URL parsing?
5. Can symbolic links expand the accessible namespace?
6. What files can the Apache user read?
7. Are sensitive application files located on the same host?
8. Can unintended files invoke CGI or another handler?
9. Does a leaked secret unlock another attack primitive?
10. Was UnsafePrefixStat added after an upgrade?

The last question is increasingly important.

Apache 2.4.60 Changed the Default Behavior

Apache’s fix was intentionally capable of breaking previously accepted rewrite configurations.

This was necessary because silently preserving the historical behavior would preserve the vulnerability.

Beginning with Apache HTTP Server 2.4.60, server-scoped substitutions that begin with variables or backreferences and resolve to filesystem paths are restricted.

Apache added a new rewrite flag:

UnsafePrefixStat

Its name is unusually honest.

Apache’s documentation explains that the flag is required if administrators explicitly want to restore potentially unsafe behavior for substitutions beginning with a variable or backreference. The documentation directly states that this protection exists because of CVE-2024-38475. (Apache HTTP Server)

言い換えれば、"忖度 "である：

[UnsafePrefixStat]

is not “the CVE-2024-38475 fix.”

It is effectively an opt-out from part of the fix.

Do Not Blindly Add UnsafePrefixStat

This deserves special emphasis because compatibility problems often produce exactly the wrong operational response.

Imagine an administrator upgrades from 2.4.59 to 2.4.60.

An old RewriteRule stops working.

Apache reports that the substitution is unsafe.

The administrator searches the error message and discovers:

UnsafePrefixStat

They add it.

The site works again.

Operationally, the incident looks solved.

Security-wise, however, the administrator may have restored exactly the behavior Apache intentionally disabled.

Apache’s own documentation says the flag should only be added once the substitution has been verified to be appropriately constrained. (Apache HTTP Server)

A better response is usually to redesign the rule so that the substitution begins with a known-safe literal prefix.

Instead of:

RewriteRule "^/files/(.*)$" "$1" [...]

prefer a design conceptually closer to:

RewriteRule "^/files/([A-Za-z0-9._/-]+)$" "/known/web/path/$1" [...]

while separately validating traversal, encoding, symlinks and the application’s intended URL namespace.

The exact secure configuration depends on the application, but the principle is universal:

User-controlled data should not define the filesystem root from which Apache begins resolution.

CVE-2024-38475 Versus CVE-2024-38474

CVE-2024-38474 and CVE-2024-38475 are easy to confuse.

Both involve mod_rewrite.

Both were discovered by Orange Tsai.

Both affect Apache HTTP Server 2.4.59 and earlier.

Both were fixed in 2.4.60.

And both can contribute to script execution or source disclosure.

But they address different security boundaries.

CVE-2024-38474

CVE-2024-38474 concerns an encoding issue involving question marks in rewrite backreferences.

Apache introduced another explicit compatibility flag:

UnsafeAllow3F

for rules that intentionally require the previously unsafe behavior. (NVD)

CVE-2024-38475

CVE-2024-38475 focuses on the dangerous interpretation of substitutions whose leading portion originates from a variable or backreference and may be treated as a filesystem path.

Its compatibility flag is:

UnsafePrefixStat

The two vulnerabilities emerged from the same broader family of parsing and semantic ambiguities, so practical research may discuss their primitives together.

They should not, however, be treated as interchangeable CVEs.

CVE-2024-38475 Versus CVE-2024-38476

Another neighboring vulnerability is CVE-2024-38476.

CVE-2024-38476 involves Apache’s handling of backend application output and internal redirects, potentially allowing information disclosure, SSRF or local script execution.

This belongs more naturally to the Handler Confusion portion of Orange Tsai’s research.

CVE-2024-38475 is primarily about reaching unintended filesystem locations through rewrite interpretation.

That distinction is useful when investigating a real environment:

38475 → where did Apache map the request?

38476 → what handler or processing path did Apache invoke afterward?

Complex exploitation may combine multiple primitives.

CVE-2024-38475 Versus CVE-2024-39573

CVE-2024-39573 is another mod_rewrite issue addressed in Apache 2.4.60.

It involves unsafe RewriteRules unexpectedly causing requests to be handled by mod_proxy, producing potential SSRF.

Again, the common architectural theme is that an administrator believes a rewrite result means one thing while another Apache module interprets it differently.

This explains why Orange Tsai used the phrase Confusion Attacks rather than treating every CVE as completely independent research. (Orange Tsai)

Detecting Exposure

Detection should operate at several levels.

1. Apache Version

Start with package inventory.

On common Linux systems:

apachectl -v

or:

httpd -v

may report the installed version.

Do not assume the banner returned remotely represents the real package version. Distributions frequently backport security patches without matching the upstream version string exactly.

Check the vendor’s security advisory for your distribution.

2. Loaded Modules

Determine whether mod_rewrite is active.

例えば、こうだ：

apachectl -M

Look for:

rewrite_module

Having mod_rewrite enabled is not by itself evidence of exploitability, but disabling an unused module reduces unnecessary attack surface.

3. Search the Effective Configuration

Depending on the operating system, investigate:

/etc/apache2/
/etc/httpd/
/usr/local/apache2/conf/

Search for:

grep -Rni "RewriteRule" /etc/apache2

or the corresponding configuration directory.

Also search for:

UnsafePrefixStat

because the presence of the flag deserves manual review.

A server running a fixed Apache version may still contain a rule whose legacy behavior has been explicitly re-enabled.

4. Identify Leading Backreferences and Variables

Pay particular attention when the substitution begins with:

$1
%1
${...}
%{...}

or when only minimal literal characters precede attacker-influenced values.

Apache’s documentation specifically ties these leading-variable/backreference filesystem substitutions to CVE-2024-38475. (Apache HTTP Server)

5. Review Symlinks and Sensitive Local Applications

DocumentRoot escape becomes more interesting when symlinks bridge web-accessible trees to system application directories.

Inventory:

symbolic links
shared application directories
legacy CGI directories
application configuration
secret files
maintenance scripts

Do not assess rewrite exposure independently from filesystem architecture.

HTTP Log Indicators

There is no universal network signature that identifies every CVE-2024-38475 exploit because exploitability depends heavily on the target RewriteRule.

Nevertheless, suspicious activity may include requests containing unusual combinations of:

encoded question marks
unexpected filesystem-like path components
repeated probing of rewrite-controlled routes
requests for configuration-like filenames
requests containing unusual suffix patterns designed to satisfy a RewriteRule

An encoded question mark such as:

%3F

is not malicious on its own.

Legitimate applications can contain encoded characters.

Detection should therefore look for コンテキスト, not merely a string.

例えば、こうだ：

request contains encoded delimiter
+
path targets rewrite endpoint
+
response suddenly becomes 200
+
response size resembles a local configuration file

is considerably more interesting than %3F alone.

File Access Telemetry Can Be Even More Valuable

Endpoint telemetry may reveal something network monitoring cannot.

Suppose the externally requested URL looks like:

/public/assets/...

but the Apache worker unexpectedly opens:

/etc/...

or:

/opt/internal-app/...

That mismatch is highly suspicious.

Tools based on:

auditd
eBPF
EDR file telemetry
system call tracing

can help organizations identify web-server processes accessing unusual paths.

Establishing a baseline matters because Apache legitimately reads many files:

certificates
configuration
static assets
logs
shared libraries
application content

The goal is identifying unexpected filesystem transitions caused by externally controlled requests.

Source Disclosure Detection

Defenders should also monitor responses.

A successful disclosure may contain recognizable markers such as:

<?php
BEGIN PRIVATE KEY
DATABASE_URL=
SECRET_KEY=
password:
SQLite format

Again, these strings need context.

For example, legitimate application output could contain examples of PHP syntax.

But a production endpoint suddenly returning raw:

<?php

where it previously returned rendered HTML should be treated as a serious incident.

Safe Validation Strategy

Testing CVE-2024-38475 safely requires more than sending a generic scanner payload against arbitrary servers.

The best validation process is configuration-driven.

First identify a potentially unsafe RewriteRule.

Then reconstruct the rule in an isolated environment containing only harmless test files.

例えば、こうだ：

/lab/public/visible.txt
/lab/private/test-marker.txt

Use a unique non-sensitive marker:

CVE-2024-38475-LAB-MARKER

The security question becomes:

Can a request intended for /lab/public/ cause Apache to resolve the private marker through the rewrite rule?

This validates the vulnerable primitive without targeting secrets, session stores or production credentials.

For production environments, configuration review plus version verification is generally preferable to deliberately attempting arbitrary-file retrieval.

Why Automated Scanners Can Produce Misleading Results

A scanner may detect:

Apache/2.4.59

and mark CVE-2024-38475 as vulnerable.

That means the vulnerable upstream version is present.

It does not necessarily prove that a remotely exploitable RewriteRule exists.

Conversely, an appliance might suppress its Apache banner entirely while still embedding an affected implementation and dangerous configuration.

Reliable verification therefore combines:

component detection
+
configuration analysis
+
request-path analysis
+
filesystem context
+
controlled runtime validation

This is a good example of why vulnerability management should distinguish version vulnerability from verified exploitability.

修復

The most important remediation is straightforward:

Upgrade Apache HTTP Server.

CVE-2024-38475 was fixed in:

Apache HTTP Server 2.4.60

Apache released that version on July 1, 2024. (Apache HTTP Server)

However, organizations should not interpret this as a recommendation to deploy 2.4.60 today.

As of August 2026, the Apache HTTP Server project identifies 2.4.68, released June 8, 2026, as the latest stable release and recommends it over previous releases. (Apache HTTP Server)

So the practical guidance is:

Minimum version specifically fixing CVE-2024-38475:
2.4.60

Preferred remediation today:
current vendor-supported Apache release,
currently upstream 2.4.68

If Apache comes from a Linux distribution, use the distribution’s patched package rather than replacing it blindly with a manually compiled upstream build.

Review RewriteRules After Upgrading

An upgrade may intentionally break unsafe rules.

Do not treat this as an ordinary compatibility regression.

If Apache rejects a rule because a variable or backreference can form the beginning of a filesystem path, investigate why the rule was designed that way.

Ask whether it can be rewritten using:

fixed literal prefixes
strict allowlists
explicit aliases
Redirect
ProxyPass
application routing

rather than unconstrained dynamic rewrites.

Apache itself recommends avoiding mod_rewrite where simpler mechanisms are sufficient. (Apache HTTP Server)

Treat UnsafePrefixStat as a Security Exception

Organizations should consider:

UnsafePrefixStat

a security-sensitive configuration flag.

A useful policy is:

UnsafePrefixStat requires security review.

Document:

• why it is needed;
• which RewriteRule requires it;
• what attacker-controlled values can enter the rule;
• why those values cannot produce arbitrary filesystem paths;
• what tests demonstrate the constraint;
• who approved the exception.

This turns an obscure Apache flag into something visible during future security audits.

Apply Least Privilege to Apache Filesystem Access

Even after patching, web servers should not have unnecessary read access to sensitive files.

The Apache worker account should generally not be able to read:

private SSH keys
backup archives
administrator home directories
cloud credential stores
unrelated application secrets
database backups
deployment credentials

Least privilege reduces the value of future path-disclosure vulnerabilities.

Containerization and filesystem isolation can provide another boundary when deployed correctly.

Separate Secrets From Web-Server Reachability

Consider the full local compromise graph:

Apache worker
      ↓
readable filesystem
      ↓
application secrets
      ↓
other systems

A web server configured only to serve static files should not automatically possess read access to production database credentials.

Similarly, secrets used by unrelated applications should not all be readable by one generic service account.

CVE-2024-38475 demonstrates why local permission architecture matters even for remotely triggered vulnerabilities.

Rotate Secrets After Confirmed Exploitation

Patching prevents future exploitation.

It does not invalidate information that may already have been stolen.

If forensic evidence suggests successful CVE-2024-38475 exploitation, defenders should identify which files the Apache process could read and consider rotating exposed material such as:

session secrets
application signing keys
API tokens
database credentials
administrator sessions
OAuth credentials
OTP-related secrets

The SonicWall response illustrates this principle clearly. Its advisory recommended additional credential-related actions because exploitation could expose session or authentication material. (SonicWall PSIRT)

Why CISA KEV Changes the Patch Priority

Thousands of vulnerabilities receive CVE identifiers every year.

Not all deserve emergency remediation.

CVE-2024-38475 now belongs to a different category because exploitation is no longer hypothetical.

CISA’s KEV entry means defenders have evidence that attackers have actually used the vulnerability in real environments. (CISA)

Therefore an organization still running a vulnerable Apache implementation should not reason:

"We have never seen this exploit against our exact application,
so the risk is theoretical."

A better conclusion is:

"The primitive has already proven operationally useful.
We must determine whether our configuration exposes it."

That difference should materially affect vulnerability-management priority.

Why Internet-Facing Appliances Are Especially Attractive

Security appliances often combine several dangerous characteristics:

internet-facing interface
+
high-value administrative sessions
+
embedded web server
+
custom rewrite logic
+
sensitive local databases
+
privileged backend components

A vulnerability that appears to be “only file disclosure” can therefore have disproportionate consequences on an edge appliance.

The web server may have access to:

authentication databases
VPN sessions
OTP seeds
configuration backups
certificates
administrator tokens
network configuration

That makes appliance-specific analysis critical.

CVE-2024-38475’s SonicWall history is a good demonstration of why generic CVE severity and actual asset-specific impact can differ substantially.

A Useful Mental Model for CVE-2024-38475

Instead of memorizing the vulnerability as:

Apache mod_rewrite path traversal

a more accurate mental model is:

Untrusted URL
     ↓
RewriteRule
     ↓
attacker-controlled prefix
     ↓
URL/filesystem semantic ambiguity
     ↓
unexpected filesystem resolution
     ↓
unintended local resource
     ↓
file disclosure / source exposure / local gadget
     ↓
possible authentication bypass or RCE chain

This model explains both the vulnerability and the fix.

Apache 2.4.60 changed the dangerous assumption at the point where:

attacker-controlled prefix

could begin determining:

filesystem resolution

and now requires an explicit opt-in through UnsafePrefixStat for affected legacy behavior. (Apache HTTP Server)

Frequently Asked Questions

Is CVE-2024-38475 an RCE vulnerability?

Potentially, yes, but not every vulnerable Apache installation provides direct RCE.

Apache officially describes the impact as code execution or source code disclosure. Actual consequences depend on the RewriteRule, filesystem layout, handlers and applications available on the host. (Apache HTTP Server)

Some environments may expose only files.

Others may expose secrets that unlock application-level RCE.

Still others may make executable local scripts reachable.

Can CVE-2024-38475 be exploited without authentication?

Yes, affected RewriteRules can operate on unauthenticated incoming HTTP requests.

The NVD vector currently records:

PR:N
UI:N
AV:N

indicating network exploitation without privileges or user interaction in the assessed scenario. (NVD)

Does enabling mod_rewrite automatically make Apache exploitable?

No.

A vulnerable version plus mod_rewrite is not sufficient evidence of remote exploitability.

The server also requires an affected rewrite configuration.

Is Apache 2.4.60 safe from CVE-2024-38475?

Apache 2.4.60 contains the upstream fix for this particular CVE.

But it is no longer the recommended production target.

As of August 2026, Apache’s current GA release is 2.4.68. (Apache HTTP Server)

What does UnsafePrefixStat do?

UnsafePrefixStat tells modern Apache versions to permit certain server-scoped RewriteRule substitutions beginning with a variable or backreference that may resolve to a filesystem path.

It exists specifically because the safe default introduced for CVE-2024-38475 can break legacy rules. (Apache HTTP Server)

It should not be added without security analysis.

Is CVE-2024-38475 being exploited?

Yes.

CISA added it to the Known Exploited Vulnerabilities Catalog on May 1, 2025. SonicWall has also documented active exploitation in the context of affected SMA products. (CISA)

Does the vulnerability bypass operating-system file permissions?

No.

Apache still operates with the filesystem permissions of its service account and associated processes.

However, web servers often have access to application configuration and secrets that are highly valuable to attackers.

Why is source code disclosure dangerous if the attacker cannot execute commands?

Because application source code frequently exposes:

secrets
credentials
internal APIs
hidden endpoints
cryptographic keys
database schema
authorization logic
vulnerable dependencies

Any of those can enable a second-stage attack.

Defensive Checklist

For defenders prioritizing CVE-2024-38475, the most useful workflow is:

優先順位	アクション
クリティカル	Identify Apache HTTP Server 2.4.59 and earlier
クリティカル	Patch using your vendor-supported current release
クリティカル	Audit server/vhost-context RewriteRules
クリティカル	Investigate substitutions beginning with variables or backreferences
クリティカル	Search for UnsafePrefixStat
高い	Review Apache-readable sensitive files
高い	Review symlinks and filesystem mappings
高い	Inspect logs for suspicious encoded-delimiter probing
高い	Investigate unexpected Apache access outside normal content directories
高い	Rotate secrets if successful exploitation is suspected
ミディアム	Remove unnecessary mod_rewrite 使用状況
ミディアム	Replace complex rewrite logic with simpler routing directives where possible
ミディアム	Add configuration-security checks to CI/CD and infrastructure review

Broader Security Lessons From CVE-2024-38475

CVE-2024-38475 is valuable beyond Apache because it demonstrates several recurring security principles.

The first is that semantic ambiguity can be as dangerous as memory corruption.

Nothing about the core vulnerability requires an attacker to corrupt a heap or overwrite a return address.

Instead:

module A thinks "URL"
module B thinks "filename"
administrator thinks "path under DocumentRoot"

The attack emerges from the disagreement.

The second lesson is that configuration is executable security logic.

A vulnerable component may remain harmless until combined with a particular RewriteRule.

A seemingly minor configuration change can therefore transform a low-impact condition into arbitrary file disclosure.

The third lesson is that information disclosure and code execution should not be evaluated independently.

An application secret may be just as powerful as direct access to a shell when it allows the attacker to forge trusted data, steal sessions or activate an internal gadget.

Finally, CVE-2024-38475 demonstrates why real pentesting needs to evaluate exploit chains rather than CVEs in isolation.

A scanner might report:

CVE-2024-38475

and stop.

An attacker asks:

What can I read?

What secret is inside it?

What trust boundary does that secret control?

What can I do after crossing that boundary?

The SonicWall case demonstrates exactly why the second approach matters.

最終的な感想

CVE-2024-38475 is best understood not as a generic “Apache RCE,” but as a dangerous failure in the boundary between URL rewriting and filesystem resolution.

In vulnerable Apache HTTP Server versions, an unsafe server-scoped RewriteRule can allow attacker-controlled backreferences or variables to influence the beginning of a path strongly enough that Apache maps a request to a filesystem location the administrator never intended to expose.

From there, consequences depend on the environment.

The result may be:

arbitrary file disclosure

or:

source code disclosure

or:

secret leakage

or:

access to a dangerous local application gadget

and, in sufficiently powerful configurations:

リモートコード実行

Apache fixed the vulnerability in version 2.4.60 by changing the behavior of unsafe leading-variable and leading-backreference substitutions. Administrators who genuinely require the old behavior can opt back in using UnsafePrefixStat, but doing so without proving that the substitution is constrained risks reintroducing the security condition the patch was designed to eliminate. (Apache HTTP Server)

The threat is no longer theoretical. CVE-2024-38475 entered CISA’s Known Exploited Vulnerabilities Catalog in May 2025, and exploitation has been documented in environments such as SonicWall SMA appliances. (CISA)

Organizations should therefore treat vulnerable Apache deployments as a priority, but remediation should go beyond checking a version number.

The right question is not merely:

“Are we running Apache 2.4.59?”

It is:

“Can any attacker-controlled RewriteRule result cause Apache to interpret a URL as a filesystem location we never intended to expose—and what happens if it does?”

That question captures the real security boundary behind CVE-2024-38475.