CVE-2026-46415 in Defender Plugin
Summary
by MITRE • 07/20/2026
The 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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
The vulnerability in the Caddy Defender plugin represents a critical security flaw that undermines network access control mechanisms in web server deployments. This issue affects versions prior to 0.10.1 where the plugin incorrectly evaluates request blocking based on the immediate peer connection rather than the actual client IP address. The fundamental problem lies in how the plugin processes network traffic flow within proxy environments, creating a potential bypass mechanism that allows malicious actors to circumvent intended security policies.
The technical implementation flaw stems from the plugin's reliance on `r.RemoteAddr` for IP address evaluation instead of utilizing Caddy's built-in client IP resolution capabilities. When Caddy operates behind trusted proxies, CDNs, or load balancers, the immediate peer connection (`RemoteAddr`) reflects the proxy server's IP rather than the original client's IP address. Caddy's architecture includes a sophisticated mechanism that resolves the true client IP into a `client_ip` request variable after applying configured `trusted_proxies` policies, but the Defender plugin ignored this resolved value entirely.
This vulnerability creates a significant operational impact for organizations relying on Caddy Defender for access control and rate limiting. The bypass occurs because the plugin operates under the assumption that all traffic originates from the immediate peer, which is accurate in direct client-to-server scenarios but fails in proxy-based architectures. The flaw specifically targets deployments where security policies should be enforced based on actual client IP addresses rather than intermediary proxy IPs, potentially allowing blocked IP ranges to access protected resources through legitimate proxy connections.
From a cybersecurity perspective, this vulnerability aligns with CWE-284 (Improper Access Control) and represents a classic case of trust boundary violation. The issue demonstrates how middleware components can inadvertently create security gaps when they don't properly integrate with the underlying platform's security mechanisms. The ATT&CK framework categorizes this as a privilege escalation technique through proxy manipulation, where attackers exploit the difference between perceived and actual network positions.
The fix implemented in version 0.10.1 addresses this by prioritizing Caddy's resolved `client_ip` request variable when available, falling back to `RemoteAddr` only when necessary. This change ensures that Defender operates correctly in proxy environments while maintaining backward compatibility for direct client connections. However, the remediation requires careful deployment planning since organizations cannot rely on workarounds in affected versions.
Organizations using vulnerable versions must implement compensating controls at network edges before traffic reaches Caddy, including configuring equivalent IP blocking at trusted proxies, CDNs, load balancers, or firewall layers. This approach ensures that security policies remain effective regardless of the Defender plugin's limitations. Deployments where Caddy receives direct client traffic without intermediate proxies remain unaffected, making this vulnerability specific to proxy-based architectures. The recommended mitigation strategy emphasizes defense in depth, requiring multiple layers of protection rather than relying solely on a single security control within the application stack.