CVE-2026-75514 affects three identical logical flaws in BunkerWeb's rDNS-based trust modules: blacklist.lua, greylist.lua, and antibot.lua. Each checks whether a client's PTR record ends with a trusted suffix but skips the critical step of calling get_ips to verify that hostname resolves back to the originating IP. An attacker spoofing their source IP with a trusted PTR suffix bypasses the WAF's anti-spoofing checks entirely.
The pattern matters more than the individual vulnerability. Identical insecure logic replicated across three separate modules isn't coincidence—it's evidence that the API design made the insecure implementation the path of least resistance. The functions get_ignore_rdns() and get_greylist_rdns() return boolean suffix matches, presenting the result as a security verdict rather than an intermediate data point requiring additional validation. Developers used them as intended and shipped bypasses.
The 1.6.13 fix adds get_ips calls to verify bidirectional resolution. This closes the technical gap but introduces a synchronous DNS dependency into request paths that previously had none. Monitor for increased latency on rDNS-checked requests and consider whether the fix creates a new DoS vector—attackers who can't spoof trusted suffixes may instead flood the DNS resolution path.
The deeper question is what API refactoring prevents the next instance. If get_ignore_rdns() returned the hostname instead of a boolean, callers would be forced to choose how to use it. The genealogical record for rDNS bypass vulnerabilities shows recurrence every 3-5 years across infrastructure generations—sendmail in the 1990s, appliances in the 2000s, now WAFs. Each CVE is treated as an isolated incident, but the pattern persists because the underlying API mental model never changes. Verify your logging surfaces suffix-match events distinct from successful verifications; the inability to observe these checks is what allows the vulnerability to persist silently.