The Apache path traversal (CVE-2021-41773)

In October 2021, Apache 2.4.49 shipped with a change to how it normalised request paths. Within days, servers running it were having /etc/passwd read over the web, and — where mod_cgi was loaded — having commands run on them. It was exploited in the wild within hours of disclosure, by unauthenticated attackers, with a one-line curl.

It is the clearest worked example on this site of two things: how thin the line is, and how much Apache’s defaults were doing to hold it.

What the bug was

Apache is supposed to reject .. sequences that would climb above the document root. CVE-2021-41773 was a flaw in that check: a .. encoded as %2e%2e slipped through normalisation, so a request like

GET /cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd

resolved, on the filesystem, to /etc/passwd.

The 2.4.50 fix was incomplete — it didn’t account for double encoding — so CVE-2021-42013 followed days later with %%32%65 in place of .. Two CVEs, one bug, one week.

With mod_cgi loaded, the same traversal reached executables and ran them, turning file disclosure into remote code execution:

POST /cgi-bin/.%2e/.%2e/bin/sh    (with a command in the body)

Why most servers were fine

This is the part worth internalising, because it’s the lesson rather than the trivia.

The exploit only reached files Apache was willing to serve. A default Apache config carries this:

<Directory />
    Require all denied
</Directory>

That denies the entire filesystem by default and grants access back only for specific document roots. So even with the traversal bug, a request for /etc/passwd hit Require all denied and got a 403 — the bug climbed out of the document root and immediately ran into a wall.

The servers that got hit were the ones that had replaced that default with Require all granted — usually to make some unrelated 403 go away. They’d removed the wall, so when the traversal bug arrived, there was nothing behind it.

That’s why keeping Require all denied is control #10 on this site. It is not defence in depth against a hypothetical — it is the specific thing that decided who got compromised in a real, widely-exploited event.

The shortest path from exposed to safe

1. Patch. 2.4.49 and 2.4.50 are the vulnerable versions; 2.4.51 fixed both, and you should be far past that — 2.4.68 is current. If you’re on 2.4.49 or 2.4.50, this is not a hardening task, it’s an incident.
2. Keep Require all denied on <Directory /> — the control that contained it even unpatched.
3. Disable mod_cgi/mod_cgid — the difference between file disclosure and code execution. If you serve PHP via FPM or proxy to an app, you don’t need CGI.

Steps 2 and 3 are the durable ones: they mean the next path bug — and there will be one — is contained the way this one was for the servers that kept their defaults.

Verify it worked

Are you on a vulnerable version?

apachectl -v

2.4.49 or 2.4.50 is an emergency. Anything from 2.4.51 up is patched for these specific CVEs — but the config controls below matter regardless, for the next bug.

Is the containment in place?

sudo grep -rA3 '<Directory />' /etc/apache2/ /etc/httpd/ 2>/dev/null | grep -i require
sudo apachectl -M 2>/dev/null | grep -E 'cgi_module|cgid_module'

Want Require all denied and no cgi modules.

Test the traversal directly — these must all fail:

curl -si --path-as-is 'http://localhost/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd' | head -1
curl -si --path-as-is 'http://localhost/icons/.%2e/.%2e/.%2e/.%2e/etc/passwd' | head -1
curl -si --path-as-is 'http://localhost/.%2e/.%2e/.%2e/etc/passwd' | head -1

Expect 403 or 404. A 200 returning root:x:0:0: is active exploitation surface — patch and lock the root directory now.

Were you hit? The exploit is visible in the access log because the payload is in the URL:

sudo grep -iE '%2e%2e|\.%2e|%%32%65|/cgi-bin/\.' /var/log/apache2/access.log* 2>/dev/null | \
  grep -v ' 403 ' | head -50

Any of those with a 200 is a request that succeeded — that’s a file read, or worse. Correlate the client IPs and check what else they did:

sudo grep -iE '%2e%2e|%%32%65' /var/log/apache2/access.log* 2>/dev/null | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head

Before you apply this

If you were on 2.4.49 or 2.4.50 and internet-facing, and any request with a traversal payload returned 200, assume compromise — particularly if mod_cgi was loaded, because then the payloads could run commands, not just read files.

Response:

1. Patch immediately — this is not a maintenance-window change.
2. Grep the logs (above) for successful traversal requests. A 200 on any of them is a file read at minimum.
3. If mod_cgi was loaded and any traversal hit a cgi path with 200, treat it as RCE: check for web shells, unexpected cron entries, new SSH keys, and outbound connections — the standard host-compromise checklist.
4. Rotate everything the web user could read — the traversal reads any file www-data can access, which includes application config, .env files, database credentials, and API keys. All of it is potentially disclosed.

Even without CGI, file disclosure alone means your secrets left. /etc/passwd is the proof-of-concept target; the real targets are your application’s credentials.

The durable fix outlasts this CVE: keep Require all denied and drop unused modules. The servers that had those in October 2021 read this story in the news instead of in their logs.

Related

• Hardening Apache httpd — the full checklist, and patch first.
• Keep Require all denied — the control that contained this.