GHSA-gx7w-56w6-g48x

## AI Disclosure I used an LLM to help review the source code, reason about attack surface, and help draft and refine this report. I manually validated the finding by reproducing it locally, confirming the vulnerable code path, and verifying the HTTP behavior with `curl -v`. ## Summary Caddy's remote admin access control performs path authorization using prefix matching: - [`admin.go`](/caddy/admin.go#L719): `strings.HasPrefix(r.URL.Path, allowedPath)` This allows a client certificate authorized only for `/pki/ca/prod` to access sibling PKI resources whose paths merely share the same prefix, such as `/pki/ca/prod-backup`. This is an authorization bug in Caddy's source code, not a misconfiguration issue. The configured policy is more restrictive than the behavior that Caddy actually enforces. ## Affected Component Remote admin access control for PKI admin endpoints. Relevant code: - [`admin.go`](/caddy/admin.go#L687) - [`admin.go`](/caddy/admin.go#L719) - [`modules/caddypki/adminapi.go`](/caddy/modules/caddypki/adminapi.go#L68) - [`modules/caddypki/adminapi.go`](/caddy/modules/caddypki/adminapi.go#L164) ## Root Cause In `RemoteAdmin.enforceAccessControls()`, allowed paths are checked like this: ```go for _, allowedPath := range accessPerm.Paths { if strings.HasPrefix(r.URL.Path, allowedPath) { pathFound = true break } } ``` This does not enforce a path-segment boundary. So if the allowed path is: /pki/ca/prod then all of the following are treated as authorized: - /pki/ca/prod-backup - /pki/ca/prod1 - /pki/ca/prodanything For PKI admin endpoints, the CA ID is taken directly from the request path: - modules/caddypki/adminapi.go:164 So /pki/ca/prod-backup is interpreted as CA ID prod-backup, even though only /pki/ca/prod was intended to be allowed. ## Security Impact A remote admin client certificate restricted to one PKI CA path can access other CA resources with the same