The Caddy Defender middleware filters requests based on the client's IP address, but prior to version 0.10.1 it evaluated the immediate peer address (r.RemoteAddr) instead of the client IP that Caddy resolves via its trusted‑proxy policy. In deployments where Caddy is behind a CDN, load balancer, or other trusted proxy, the real client address is stored in the client_ip request variable, yet Defender ignored this value. Consequently, a request from a blocked IP can reach the protected application if it arrives through a proxy whose own address is not blocked. The issue was fixed in Defender 0.10.1, which now prefers the client_ip value when available and only falls back to r.RemoteAddr when no resolved IP exists. Until an upgrade is performed, the only reliable mitigation is to block offensive IP ranges at the edge layer (e.g., in the proxy, CDN, load balancer, or firewall) before traffic reaches Caddy, as no complete internal workaround exists for older Defender releases. This weakness involves insufficient access control (CWE‑284) and exploitation of non‑privileged principals (CWE‑348).

The issue affects installations of the Caddy Defender plugin with versions older than 0.10.1 when used in environments that rely on Caddy’s trusted‑proxy client‑IP resolution. Deployments where Caddy serves directly from client connections, without an intermediate trusted proxy, are not impacted. The fix is bundled in version 0.10.1 of the plugin, provided by the vendor JasonLovesDoggo.

With a CVSS score of 8.2, the vulnerability is considered high severity. The EPSS score is less than 1%, indicating a low exploitation probability, and the flaw is not catalogued in CISA KEV, suggesting limited evidence of active exploitation. The attack requires that an adversary controls traffic at a proxy or can craft requests to traverse a trusted proxy to Caddy, and must also identify a blocked IP that the defender targets. While the vector is mainly network‑based, the damage can include unauthorized access and lateral movement if the defender was the only block. Official guidance recommends upgrading, and until then, blocking at the edge layer is the safest mitigation.