Caddy Defender trusted proxy client IP bypass

Vulnerability

Caddy Defender versions before v0.10.1 used r.RemoteAddr (the immediate peer address) when evaluating whether to block a request [2][3]. In deployments where Caddy runs behind a trusted proxy, CDN, or load balancer, RemoteAddr is the proxy’s address, not the original client’s IP. Caddy itself resolves the real client IP into its client_ip request variable after applying the configured trusted_proxies policy, but Defender ignored that variable [1].

Exploitation

An attacker whose IP is in a Defender-blocked range can bypass the block if they route traffic through a trusted proxy whose own IP address is not blocked [2]. The attacker sends requests to the proxy, which forwards them to Caddy; Defender sees the proxy’s IP and permits the request [3]. No special authentication or prior access is required beyond the ability to reach the trusted proxy.

Impact

Successful exploitation defeats Defender’s IP-based blocking and manipulation features (e.g., blocking, garbage responses, tarpit) [2]. This enables AI crawlers, scrapers, or other unwanted clients listed in Defender’s configured ranges to access the site as if they were not blocked, violating the administrator’s access control intent [1].

Mitigation

Upgrade to Caddy Defender v0.10.1 or later, where Defender prefers Caddy’s resolved client_ip variable over RemoteAddr [2][3][4]. No complete workaround exists for affected versions; as a temporary measure, administrators can enforce equivalent IP blocking at the trusted proxy, CDN, load balancer, or firewall before traffic reaches Caddy [2]. Deployments where Caddy receives traffic directly from clients (no intermediate trusted proxy) are not affected [2].