CVE-2026-46415
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedThe Caddy Defender plugin is a middleware for Caddy that allows users to block or manipulate requests based on the client's IP address. Prior to version 0.10.1, Caddy Defender used `r.RemoteAddr` when evaluating whether a request should be blocked. `RemoteAddr` is the address of the immediate peer connected to Caddy. In deployments where Caddy is behind a trusted proxy, CDN, or load balancer, the immediate peer is usually the proxy, not the original client. Caddy resolves the original client address into its `client_ip` request variable after applying the configured `trusted_proxies` policy, but Defender did not use that value. As a result, clients from blocked IP ranges could bypass Defender when accessing Caddy through a trusted proxy whose own IP address was not blocked. This affects deployments that use Defender behind trusted proxies and expect it to enforce blocking based on the real client IP. The issue is fixed in version 0.10.1 by making Defender prefer Caddys resolved `client_ip` request variable when it is available. Defender falls back to `RemoteAddr` only when Caddy has not provided a resolved client IP. There is no complete workaround in affected Defender versions for deployments that rely on Caddy's trusted proxy client IP resolution. Until upgrading, affected users should enforce equivalent IP blocking at the trusted proxy, CDN, load balancer, firewall, or other edge layer before traffic reaches Caddy. Deployments where Caddy receives traffic directly from clients, without an intermediate trusted proxy, are not affected by this bypass.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceThe Caddy Defender plugin used the raw `r.RemoteAddr` (immediate peer address) instead of Caddy's resolved `client_ip` request variable for IP blocking decisions. In deployments behind trusted proxies, this allowed attackers from blocked IP ranges to bypass Defender by connecting through a proxy whose IP was not blocked, since Defender saw only the proxy's IP address.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- Low
- Availability
- None
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify Caddy Defender plugin installationRun `caddy list-plugins` or check the Caddy binary with `caddy -version` and look for defender-related output. Alternatively, inspect the Caddy configuration file for any `defender` block or directive.Affected if The Caddy Defender plugin is not installed or not present in the plugin list.
-
Check Caddy Defender versionRun `caddy adapt` with your configuration to see compiled plugins, or check the build information. Compare the Defender version to the fixed version 0.10.1.Affected if The installed Caddy Defender version is lower than 0.10.1.
-
Verify IP-based blocking configurationInspect the Caddy configuration file (Caddyfile or JSON) for Defender directives related to IP blocking, such as `block`, `ip_rate_limit`, or similar IP-based access control rules.Affected if IP-based blocking rules are defined in the Caddy Defender configuration.
-
Confirm proxy or CDN deployment topologyReview the network architecture to determine if Caddy is deployed behind a trusted proxy, CDN, or load balancer. Check for X-Forwarded-For or similar headers being trusted in the Caddy configuration.Affected if Caddy sits behind a trusted proxy, CDN, or load balancer and the Defender is using r.RemoteAddr for IP blocking.
-
Test IP blocking bypassSend a request through the proxy/CDN/load balancer from a blocked IP address and verify whether the request is allowed through. Compare behavior when directly accessing Caddy without the proxy.Affected if Requests from blocked IPs succeed when going through the proxy but fail when directly accessing Caddy.
A user is affected if Caddy Defender version is below 0.10.1, IP-based blocking is configured, and Caddy is deployed behind a trusted proxy, CDN, or load balancer where blocked client IPs can bypass restrictions.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade Caddy Defender to version 0.10.1 or later, which now uses Caddy's resolved `client_ip` variable and falls back to `RemoteAddr` only when no resolved client IP exists. As a temporary workaround, enforce equivalent IP blocking at the trusted proxy/CDN/load balancer layer.
Caddy Defender plugin version 0.10.1
- Download or ensure you have xcaddy installed (go install github.com/caddyserver/xcaddy@latest)
- Stop your current Caddy service
- Use xcaddy to build Caddy with the updated Defender plugin version 0.10.1: xcaddy build --with github.com/caddyserver/caddy-adapter-usage/plugins/caddyserver/caddy-defender=v0.10.1
- Replace the existing Caddy binary with the newly built binary
- Start the Caddy service
- Verify the Defender plugin version is 0.10.1 using: caddy list-plugins
- Test that IP blocking now correctly uses the resolved client_ip from trusted_proxies configuration
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation2.0 h
- Testing3.0 h
- Review / QA1.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $2,224.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-46415 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-46415 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data