Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
AI Disclosure This vulnerability was discovered via deepseek-v4-pro[1m] for finding potential vulnerabilities / inconsistencies in the code base. I made the AI check if Caddy is compliant with various RFCs, incl. 7230. I also used it to help write the PoC, since it was honestly much faster than writing it by hand. I also let it write parts of this advisory text for brevity's sake, but had to rewrite half of it by hand. Summary Caddy's reverse proxy fails to strip RFC 7230 hop-by-hop headers from upstream responses when handling WebSocket upgrades (HTTP 101 Switching Protocols). Headers including `Alt-Svc`, `Keep-Alive`, `Proxy-Authenticate`, `Transfer-Encoding`, or `Trailer`, which Caddy actually correctly strips for normal HTTP responses, pass through unfiltered to the client during protocol upgrades. An upstream that sets these headers (intentionally or otherwise) can inject them into client responses, enabling connection hijacking via `Alt-Svc`, cookie injection via…
Recommended action: Upgrade to 2.11.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Caddy v2.11.3 — Three vulnerabilities in handler/placeholder layer Tested against: caddy:2.11.3 (official Docker image, SHA verified at runtime) Reproduction environment: Docker Desktop 4.73.1 / Engine 29.4.3 on Windows 10 host, isolated containers, no network egress required for any of the exploits This advisory bundles three independent issues discovered together during a source review of the placeholder/replacer layer. Each issue has been reproduced end-to-end against the unmodified caddy:2.11.3 image with the minimal Caddyfile that the documentation suggests for the affected feature. --- Issue 1: Rewrite handler — placeholder double-expansion enables env var / file disclosure File: modules/caddyhttp/rewrite/rewrite.go:215-249 and buildQueryString at 327 Class: CWE-94 (Code Injection), same bug class as CVE-2026-30852 (varsregexp) Severity: Low (requires operator config with trailing ? in rewrite URI) Root cause When the operator's rewrite URI template: 1. Contains a placeholder…
Recommended action: Upgrade to 2.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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 - admin.go - modules/caddypki/adminapi.go - modules/caddypki/adminapi.go Root Cause In RemoteAdmin.enforceAccessControls(),…
Recommended action: Upgrade to 2.11.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/caddyserver/caddy/v2 >= 2.4.0, < 2.11.3
Fixed in
2.11.3· Vendor fix available
Issue
This report is not about a normal textual prefix-expansion case. The issue here is that the authorization layer and the /config traversal layer do not agree on what object the path refers to. In this case, a path authorized for one config object is accepted, but then resolves to a different config object during traversal. AI Disclosure The reporter used an LLM to help review the code, reason about the behavior, and help draft this report. The reporter manually reproduced and validated the issue locally, confirmed the relevant source paths, and captured the requests and responses below. Summary A remote admin client certificate restricted to the following path: can still read and modify a different array element by requesting: /config/apps/http/servers/srv/routes/01 This happens because: - the authorization layer uses string prefix matching - the /config traversal layer parses array indices numerically using strconv.Atoi() So: - authorization sees /.../01 as matching /.../0 -…
Recommended action: Upgrade to 2.11.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/caddyserver/caddy/v2 >= 2.7.0, <= 2.10.2
Fixed in
2.11.3· Vendor fix available
Issue
The FastCGI transport's splitPos() in modules/caddyhttp/reverseproxy/fastcgi/fastcgi.go misuses golang.org/x/text/search with search.IgnoreCase when the request path contains a non-ASCII byte. Two distinct flaws in that fallback let an attacker mislead Caddy's FastCGI splitting into treating a non-.php (or other configured splitpath extension) file as a script. In any deployment where the attacker can place content into a file served via FastCGI (uploads, file storage, etc.), this can be escalated to remote code execution by crafting a URL whose path triggers either flaw. This function was adapted from FrankenPHP's code (see the source comment) and inherits the same bugs. Both were originally reported against FrankenPHP by @KC1zs4 as GHSA-3g8v-8r37-cgjm (which absorbed the duplicate GHSA-v4h7-cj44-8fc8). Credit for finding the underlying flaws belongs to @KC1zs4. Details Flaw 1 — Control-flow: stale match after inner non-ASCII fallback In the inner for j loop, when a byte…
Recommended action: Upgrade to 2.11.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Caddy's FastCGI path splitting logic computes the split index on a lowercased copy of the request path and then uses that byte index to slice the original path. This is unsafe for Unicode because strings.ToLower() can change UTF-8 byte length for some characters. As a result, Caddy can derive an incorrect SCRIPTNAME/SCRIPTFILENAME and PATHINFO, potentially causing a request that contains .php to execute a different on-disk file than intended (path confusion). In setups where an attacker can control file contents (e.g., upload features), this can lead to unintended PHP execution of non-.php files (potential RCE depending on deployment). Details The issue is in github.com/caddyserver/caddy/modules/caddyhttp/fastcgi.Trasnport.splitPos() (and the subsequent slicing in buildEnv()): The returned index is computed in the byte space of lowerPath, but buildEnv() applies it to the original path: - docURI = path[:splitPos] - pathInfo = path[splitPos:] - scriptName =…
Recommended action: Upgrade to 2.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
commit: e0f8d9b2047af417d8faf354b675941f3dac9891 (as-of 2026-02-04) channel: GitHub security advisory (per SECURITY.md) summary The local caddy admin API (default listen 127.0.0.1:2019) exposes a state-changing POST /load endpoint that replaces the entire running configuration. When origin enforcement is not enabled (enforceorigin not configured), the admin endpoint accepts cross-origin requests (e.g., from attacker-controlled web content in a victim browser) and applies an attacker-supplied JSON config. this can change the admin listener settings and alter HTTP server behavior without user intent. Severity Medium Justification: - The attacker can apply an arbitrary caddy config (integrity impact) by driving a victim’s local admin API. - Exploitation requires a victim running caddy with the admin API enabled and visiting an attacker-controlled page (or otherwise issuing the request from an untrusted local client). Affected component - caddyconfig/load.go: adminLoad.handleLoad (/load…
Recommended action: Upgrade to 2.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Caddy's HTTP host request matcher is documented as case-insensitive, but when configured with a large host list (100 entries) it becomes case-sensitive due to an optimized matching path. An attacker can bypass host-based routing and any access controls attached to that route by changing the casing of the Host header. Details In Caddy v2.10.2, the MatchHost matcher states it matches the Host value case-insensitively: - modules/caddyhttp/matchers.go: type MatchHost matches requests by the Host value (case-insensitive). However, in MatchHost.MatchWithError, when the host list is considered "large" (len(m) 100): - MatchHost.large() returns true for len(m) 100 (modules/caddyhttp/matchers.go, around the large() helper). - The matcher takes a "fast path" using binary search over the sorted host list, and checks for an exact match using a case-sensitive string comparison (m[pos] == reqHost). - After the fast path fails, the fallback loop short-circuits for large lists by breaking as…
Recommended action: Upgrade to 2.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Caddy's HTTP path request matcher is intended to be case-insensitive, but when the match pattern contains percent-escape sequences (%xx) it compares against the request's escaped path without lowercasing. An attacker can bypass path-based routing and any access controls attached to that route by changing the casing of the request path. Details In Caddy v2.10.2, MatchPath is explicitly designed to be case-insensitive and lowercases match patterns during provisioning: - modules/caddyhttp/matchers.go: rationale captured in the MatchPath comment. - MatchPath.Provision lowercases configured patterns via strings.ToLower. - MatchPath.MatchWithError lowercases the request path for the normal matching path: reqPath := strings.ToLower(r.URL.Path). But when a match pattern contains a percent sign (%), MatchPath.MatchWithError switches to "escaped space" matching and builds the comparison string from r.URL.EscapedPath(): - reqPathForPattern := CleanPath(r.URL.EscapedPath(), mergeSlashes)…
Recommended action: Upgrade to 2.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Two swallowed errors in ClientAuthentication.provision() cause mTLS client certificate authentication to silently fail open when a CA certificate file is missing, unreadable, or malformed. The server starts without error but accepts any client certificate signed by any system-trusted CA, completely bypassing the intended private CA trust boundary. Details In modules/caddytls/connpolicy.go, the provision() method has two return nil statements that should be return err: Bug #1 — line 787: Bug #2 — line 800: Compare with line 811 which correctly returns the error: When the error is swallowed on line 787, the chain is: 1. TrustedCACerts remains empty (no DER data appended from the file) 2. The len(clientauth.TrustedCACerts) 0 guard on line 794 is false — skipped 3. clientauth.CARaw is nil — line 806 returns nil 4. clientauth.ca remains nil — no CA pool was created 5. provision() returns nil — caller thinks provisioning succeeded Then in ConfigureTLSConfig(): 6. Active() returns…
Recommended action: Upgrade to 2.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Caddy v2.4.6 was discovered to contain an open redirection vulnerability which allows attackers to redirect users to phishing websites via crafted URLs
Recommended action: Upgrade to 2.5.0-beta.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.