WAF ip_blocklist with on_demand_tls

[doogienz]

I'm trying to do a very simple blocklist on a dynamic list. We have an application enabled which uses caddy file {query.domain} to verify that it's allowed to talk to the box:

        on_demand_tls {
                ask http://localhost:8001

Which in turn has the section:

8001 {
        bind 127.0.0.1 ::1

        root * /etc/caddy/allowed-domains
        @allowed file {query.domain}
        respond @allowed 200
        respond 400
}

And finally through to the actual host entry with the waf:

:443 {
        log {
                output file /var/log/caddy/wildcard-access.log {
                        roll_size 100MB
                        roll_keep 5
                }
        }

        route {
                waf {
                        ip_blacklist_file /etc/caddy/provisioner/ip_blacklist.txt
                        rule_file /etc/caddy/waf-rules.json
                }
        }

        tls {
                on_demand
        }

        reverse_proxy https://p3.backend.local {
                header_up Host p3.backend.local
                header_up X-Real-IP {remote_host}
                }
}

I have a single IP in testing in the ip_blacklist file, and I can see it loads it, and has 1 valid entry, but I just see this in the logs:

May 21 20:53:13 caddy01.ord caddy[358674]: 2026/05/21 20:53:13.838        INFO        WAF request evaluation started        {"log_id": "2a21834f-4003-4ba0-89e6-dc3cb843a130", "method": "GET", "uri": "/", "remote_address": "1.2.3.4:51412", "user_agent": "curl/8.7.1"}
May 21 20:53:14 caddy01.ord caddy[358674]: 2026/05/21 20:53:14.077        INFO        WAF request evaluation completed        {"log_id": "2a21834f-4003-4ba0-89e6-dc3cb843a130", "total_score": 0, "blocked": false, "status_code": 200}     

And no blocking of the IP in the blacklist. I've hunted around, am I missing something I should have added somewhere?

[fabriziosalmi]

Hi @doogienz — you were right, and I am sorry this sat unanswered for two months.

Your report was accurate and the log you attached was exactly the evidence needed: the WAF printed IP blacklist loaded with a valid entry and then did not block. That was not a configuration mistake on your side. I investigated it properly today and it turned out to be three separate bugs, now published as GHSA-w6gv-76q4-prqg. You are credited as the reporter.

1. The IP blacklist never blocked anything, for anyone. loadIPBlacklist took the trie by value while both callers passed a dereferenced pointer, so every entry was inserted into a copy that was thrown away on return. The trie the WAF actually consults stayed empty. The startup log counted entries from an intermediate step, which is exactly why it looked healthy. This had been broken since v0.0.7 — fifteen releases.

2. A forged X-Forwarded-For bypassed the blacklist. Once enforcement was restored, the next problem surfaced: when the header was present, r.RemoteAddr was never checked at all, so any blacklisted client could send X-Forwarded-For: 8.8.8.8 and walk straight through. The peer address is now always checked, and the forwarded chain in addition.

3. Hot-reloading a blacklist or rule file deadlocked the server. Not what you hit, but found alongside: the reload path blocked forever while holding a lock every request needs, so the process silently stopped answering.

Fixed in v0.3.9:

caddy add-package github.com/fabriziosalmi/caddy-waf@v0.3.9

To confirm it works, add an IP to ip_blacklist_file, restart, and request from it — you should get 403 with Reason: ip_blacklist, and still get it if you add an X-Forwarded-For header.

One note on your config, unrelated to the bugs: your reverse_proxy sits outside the route block. Put the WAF and the terminal handler inside the same route, in that order, so the WAF short-circuits before the proxy runs.

Thank you for the report and for the detail in it. It should not have taken this long.