The nginx alias path traversal

This configuration serves the directory above your static files to anyone who asks:

location /static {
    alias /var/www/site/static/;
}

The bug is the missing slash after /static. That’s it. It is valid config, it passes nginx -t, it serves your assets correctly, and it has been the single most common serious nginx misconfiguration for over a decade.

Why it happens

alias replaces the matched location prefix with a filesystem path. nginx strips the prefix as a string operation — it is not path-aware and does not care about directory boundaries.

Walk a request through it:

Request:    GET /static../
Location:   /static          matches (prefix match on the string)
Strip:      "/static"        leaves the remainder "../"
alias:      /var/www/site/static/  +  ../
Result:     /var/www/site/static/../   →   /var/www/site/

The remainder ../ is concatenated onto the alias path and resolved by the filesystem, landing one directory above the static root.

The trick that makes it work is that /static../ is a single path segment called static.. — not a .. traversal segment. So it survives nginx’s URI normalisation untouched, and only becomes a ../ after the prefix is stripped, at which point it’s too late.

One level up doesn’t sound like much. Consider what’s usually there: /var/www/site/ holds your .env, your config.php, your .git directory, your source, and your database credentials. GET /static../.env reads it.

The fix is one character

Make the slashes agree:

location /static/ {
    alias /var/www/site/static/;
}

Now /static../ does not match location /static/ at all — the segment static.. isn’t static/ — so it falls through to another location or a 404.

Better: use root instead.

location /static/ {
    root /var/www/site;      # serves /var/www/site/static/...
}

root appends the full URI to the path rather than replacing a prefix. There is no strip step, so there is no remainder to escape with. The class of bug does not exist.

The rule of thumb: reach for alias only when the URL path and the filesystem path genuinely differ. When they’re the same — which is most of the time — root is both simpler and immune.

Where to look for it

The pattern to hunt is any location without a trailing slash that contains an alias. It is disproportionately common in configs for /static, /assets, /media, /uploads, /files and /downloads — because those are exactly the paths people alias to a directory outside the web root.

Verify it worked

Find every vulnerable block in the effective config. This is the check to run now, before reading further:

sudo nginx -T 2>/dev/null | awk '
  /location [^ ]*[^/] *\{/ { loc=$0; inblock=1 }
  inblock && /alias/ { print "SUSPECT:", loc, "->", $0 }
  /\}/ { inblock=0 }
'

Any output is a candidate. Confirm by hand — the test is whether the location ends in / when the alias does.

Then prove it from the outside. Against a vulnerable server this returns the parent directory’s content instead of a 404:

curl -sI 'https://your.site/static../'

And the payload that matters:

curl -s 'https://your.site/static../.env'
curl -s 'https://your.site/static../config.php'

Anything other than a 404 here is an active disclosure. Try your real alias prefixes, not /static — use the list your nginx -T search produced.

Note that curl may normalise the path itself; use --path-as-is to send it raw:

curl -s --path-as-is 'https://your.site/static../.env'

Before you apply this

If this config has been live and internet-facing, treat the files above the alias as disclosed. Not “possibly disclosed” — this is trivially discoverable by automated scanners, and /static../.env is in the wordlist of every one of them.

Fixing the slash closes the hole. It does nothing about credentials that already left.

Response, in order:

1. Fix the config — add the slash, or move to root. nginx -t then reload.

2. Check whether it was found. The requests are in your access log, and they are distinctive:

   sudo grep -E '\.\./|%2e%2e|static\.\.' /var/log/nginx/access.log | grep -v ' 404 ' | head -50

   Anything with a 200 is a file someone read. That is your disclosure list.

3. Rotate everything in the exposed directory. Database passwords, API keys, secret keys, JWT signing secrets, S3 credentials — everything in the .env your app reads.

4. Check for a .git directory above the alias. If one was reachable, assume the full source history — including any secret ever committed and later removed — has been cloned.

A 404 on all of those means nobody found it before you did, which is the good outcome and worth confirming rather than assuming.

Related

• Hardening nginx — the full checklist.
• Run workers as an unprivileged user — bounds what a path bug can read.