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