CVE-2021-41773: The Path to Pwnage in Apache 2.4.49

For years, Apache HTTP Server (httpd) has been the workhorse of the internet. It's boring, reliable, and generally secure. But in version 2.4.49, the developers decided to refactor the path normalization logic—specifically the ap_normalize_path function in server/util.c. The goal was noble: improve RFC 1808 compliance and perhaps squeeze out a little more performance.

Here is the thing about parsing strings in C: it is a minefield. You are managing pointers, memory buffers, and encoding states all at once. The developers wanted to strip out path traversal sequences like ../ to ensure users couldn't break out of the web root. However, they failed to account for the order of operations when URL-decoding characters.

This vulnerability is particularly embarrassing because it affects a specific version (2.4.49) so severely that it feels like a CTF challenge rather than enterprise software. It proves that even the most mature projects can introduce catastrophic bugs when touching legacy core components.

The root cause lies in how ap_normalize_path handles URL decoding. The function iterates through the URI string, looking for dot-dot-slash sequences to remove. Simultaneously, it decodes URL-encoded characters (like %2e for .).

The logic failure was subtle but fatal. The function checks for ../ sequences before fully resolving the decoded characters in the current context. When an attacker sends .%2e/ (which translates to ../), the normalization routine sees a literal dot, followed by a percent sign. It doesn't trigger the ../ removal logic because, at that exact moment in the loop, it doesn't look like a traversal sequence.

After the check passes, the function decodes %2e into a .. The result in memory becomes ../, but the security check has already moved its pointer past the beginning of the sequence. It effectively validated the disguise rather than the face behind the mask. The code essentially said, "You look like a dot and a percent sign, come on in," and then the percent sign took off its mask to reveal another dot, completing the traversal.

Let's look at the logic flow conceptually. The vulnerable code in server/util.c was trying to collapse paths.

In a healthy state, if you send ../, the server collapses it. If you send %2e%2e/, the server decodes it to ../ and should re-scan or handle it. In 2.4.49, the loop logic was effectively:

1. Scan character.
2. Is it a traversal sequence? No.
3. Is it encoded? Yes, decode it.
4. Advance pointer.

By sending .%2e/, the first dot is literal. The %2e is decoded to a dot in place. The string becomes ../, but the loop has finished validating the position where the traversal check would have triggered. The server effectively constructs a path pointing to the parent directory and hands it off to the file handler.

This meant that /icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd would successfully traverse out of the /icons/ alias (which exists by default) and climb up to the root filesystem.

Exploiting this is trivially easy, but you need a client that doesn't try to be smart. Browsers and standard curl commands will normalize the path before sending it, killing the exploit. You must use curl --path-as-is.

Level 1: Local File Inclusion (LFI) To steal /etc/passwd, we just need to find a directory that has an Alias configured (like /icons/ or /assets/) and traverse out of it.

curl -v --path-as-is "http://target.com/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"

Level 2: Remote Code Execution (RCE) This is where it gets dark. If mod_cgi is enabled (common in older deployments or specific enterprise apps), we can traverse not just to a text file, but to an executable binary. By traversing to /bin/sh, we can force Apache to execute the shell.

curl -v --path-as-is "http://target.com/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/bin/sh" \
    -d "echo Content-Type: text/plain; echo; id"

If successful, the server executes /bin/sh, pipes the POST body into stdin, and returns the output of id. You are now www-data (or worse).

The CVSS score is 9.8 for a reason. This isn't a complex heap overflow requiring a specific memory layout. This is a logic bug that works 100% of the time on vulnerable configurations.

The impact is bifurcated:

1. Information Disclosure: Attackers can read configuration files, source code, and credentials stored on the filesystem. This often leads to further compromise (e.g., finding database passwords).
2. Remote Code Execution: With mod_cgi, the server is completely compromised. Ransomware gangs immediately added this to their toolkits because it offers a low-effort entry point into corporate networks.

What makes this terrifying is the EPSS score of nearly 95%. It is actively scanned for and exploited by bots every single day.

Apache initially released version 2.4.50 to fix this. However, in a comedic twist, the fix was incomplete. They simply checked for the .%2e sequence but failed to account for double-encoding (e.g., %%32%65). This led to CVE-2021-42013, which was effectively the exact same vulnerability, just with a slightly different payload.

The Real Solution: Upgrade to Apache 2.4.51 or later immediately. This version correctly handles path normalization by aggressively decoding and validating path segments before using them.

Mitigation Strategies: If you cannot upgrade (why?), you can use mod_rewrite to block these patterns, but that is a band-aid. The only true fix is binary replacement.

Require all denied

Ensure your <Directory /> block is set to deny all access by default. This prevents the server from serving files from root even if the traversal succeeds.