What is the CVSS score of CVE-2026-46415?

CVE-2026-46415 has a CVSS 3.1 base score of 8.2 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. EPSS exploitation probability: 0.0%.

Which versions of Caddy Defender are affected by CVE-2026-46415?

Caddy Defender versions before 0.10.1 contain an IP filtering bypass that allows attackers to reach protected backends by evading IP allowlist/blocklist controls when deployed behind proxies, CDNs,…. A patch is available.

How to fix or mitigate CVE-2026-46415?

Within 24 hours: Audit all Caddy Defender deployments to identify affected versions (anything prior to 0.10.1) and document their network topology (proxy/CDN/load balancer configurations). Within 7 days: Deploy Caddy Defender 0.10.1 or later to all affected instances and verify IP filtering rules are re-evaluated correctly. Within 30 days: Conduct functional testing of IP allowlist/blocklist enforcement to confirm controls operate as intended post-patch.

Caddy Defender CVE-2026-46415

HIGH

Improper Access Control (CWE-284)

2026-05-19 https://github.com/JasonLovesDoggo/caddy-defender

GHSA-3h23-rrpc-3p87

Authentication Bypass

8.2

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.2 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

Low

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

May 19, 2026 - 20:47 vuln.today

Analysis Generated

May 19, 2026 - 20:47 vuln.today

DescriptionGitHub Advisory

Impact

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.

Patches

The issue is fixed 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.

Users should upgrade to v0.10.1 or later.

Workarounds

There is no complete workaround in affected Defender versions for deployments that rely on Caddys 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.

AnalysisAI

IP allowlist/blocklist bypass in Caddy Defender versions prior to 0.10.1 lets attackers from blocked IP ranges evade filtering when Caddy sits behind a trusted proxy, CDN, or load balancer. The module evaluated requests against r.RemoteAddr (the proxy's IP) instead of Caddy's resolved client_ip variable, so any source whose true IP should have been blocked could reach protected backends. No public exploit identified at time of analysis, and the issue is not in CISA KEV.

Technical ContextAI

Caddy Defender is a Caddy v2 middleware module (Go package github.com/JasonLovesDoggo/caddy-defender) that enforces IP-based access control by matching the connecting client against configured CIDR ranges. The root cause maps to CWE-284 (Improper Access Control): the middleware called net.SplitHostPort(r.RemoteAddr) to derive the client IP, but in standard reverse-proxy topologies r.RemoteAddr is the TCP peer - the upstream proxy/CDN - not the originating client. Caddy core already parses X-Forwarded-For (or equivalent) against the operator-configured trusted_proxies policy and stores the resolved address in the request context under caddyhttp.ClientIPVarKey; Defender ignored this canonical value. The PR #139 fix introduces clientIPFromRequest(), which prefers caddyhttp.GetVar(ctx, ClientIPVarKey) and only falls back to RemoteAddr when Caddy has not resolved a client IP.

RemediationAI

Vendor-released patch: upgrade caddy-defender to v0.10.1 or later (go get github.com/JasonLovesDoggo/caddy-defender@v0.10.1 and rebuild Caddy via xcaddy), per advisory GHSA-3h23-rrpc-3p87 and PR https://github.com/JasonLovesDoggo/caddy-defender/pull/139. There is no in-module workaround; until upgrade, enforce equivalent IP blocking one hop upstream - at the CDN (e.g., Cloudflare IP Access Rules, AWS WAF IPSet, Fastly ACL), load balancer (ALB security group, HAProxy acl src), or perimeter firewall - accepting the trade-off that this duplicates rule management and may not match Defender's specific range presets. Operators who can route traffic directly to Caddy without an intermediary are not affected and need no action, but should still upgrade for defense in depth. After upgrading, verify Caddy's trusted_proxies global option is correctly configured, otherwise client_ip will not be resolved and Defender will silently fall back to RemoteAddr.