CVE-2026-75514 in BunkerWeb
Summary
by MITRE • 08/20/2026
BunkerWeb is an open-source, next-generation Web Application Firewall. Prior to 1.6.13, the blacklist, greylist, and antibot modules in src/common/core/blacklist/blacklist.lua, src/common/core/greylist/greylist.lua, and src/common/core/antibot/antibot.lua trust PTR suffix matches in IGNORE_RDNS, GREYLIST_RDNS, and ANTIBOT_IGNORE_RDNS without using get_ips to confirm that the hostname resolves to the client address. An unauthenticated remote attacker who controls a PTR record can spoof a trusted suffix to bypass rDNS-based blacklisting, gain greylist treatment, or skip an antibot challenge. This issue is fixed in version 1.6.13.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in BunkerWeb versions prior to 1.6.13 represents a critical flaw in the implementation of reverse DNS (rDNS) based security controls, specifically affecting the blacklist, greylist, and antibot modules. As an open-source Web Application Firewall, BunkerWeb relies on various heuristics and reputation-based mechanisms to filter malicious traffic. The core issue lies within the Lua scripts responsible for handling these lists, where the system trusts PTR record suffixes without validating that the hostname actually resolves back to the client's IP address. This design oversight creates a significant trust boundary violation, allowing attackers to manipulate DNS records to bypass security measures designed to block or challenge suspicious sources of traffic.
The technical root cause is rooted in how the IGNORE_RDNS, GREYLIST_RDNS, and ANTIBOT_IGNORE_RDNS configurations are processed. When an incoming request arrives, the firewall performs a reverse DNS lookup on the client's IP address to retrieve its associated hostname. The vulnerable code then checks if this hostname ends with specific trusted suffixes defined by the administrator. However, the implementation fails to perform a forward DNS resolution of that retrieved hostname to verify it maps back to the original source IP. This omission means that an attacker who controls a domain name can configure their PTR record or associated A/AAAA records such that the reverse lookup yields a hostname ending in a trusted suffix, even though the actual IP address is not legitimately owned by the entity controlling that domain.
From an operational perspective, this flaw allows unauthenticated remote attackers to bypass several layers of defense with relative ease. By spoofing the PTR record or manipulating DNS resolution paths, an attacker can trick the firewall into treating their malicious traffic as trusted. This results in three distinct negative outcomes depending on which module is targeted. First, if a blacklist rule relies on rDNS suffixes, the attacker's IP will not be blocked despite being identified as malicious by other means. Second, for greylisted IPs that are subjected to additional scrutiny or rate limiting, an attacker can gain exemption from these controls, allowing them to perform brute-force attacks or resource exhaustion more effectively than if they were throttled. Third, and perhaps most critically, the antibot module is designed to present challenges such as CAPTCHAs or JavaScript hurdles to distinguish humans from bots; bypassing this check allows automated scripts and botnets to operate without friction, facilitating credential stuffing, scraping, or DDoS attacks that would otherwise be mitigated by these anti-bot measures.
This vulnerability aligns with CWE-295 Improper Certificate Validation in the context of trust validation failures, as well as CWE-749 Exposed Dangerous Method if considering the exposure of configuration logic to manipulation. More specifically, it falls under CWE-601 URL Redirection to Untrusted Site via Open Redirect or similar misconfiguration patterns where external input (DNS records) is trusted without sufficient verification against internal state expectations. In terms of MITRE ATT&CK framework tactics, this flaw facilitates the Initial Access and Execution phases by allowing adversaries to evade detection systems that rely on reputation-based filtering. It also impacts the Defense Evasion tactic category, as attackers can bypass security controls through DNS manipulation techniques often categorized under T1078 Valid Accounts or more broadly under evasion of web application firewalls using trusted source spoofing.
The impact extends beyond simple access control bypasses; it undermines the integrity of the entire reputation-based filtering strategy employed by BunkerWeb administrators who rely on rDNS for threat intelligence integration. Organizations utilizing these features to block known bad actors or challenge suspicious automated traffic are left with a false sense of security, as their defenses can be trivially circumvented by anyone capable of controlling DNS records for domains that match the trusted suffixes. This is particularly dangerous in environments where legitimate services might use dynamic DNS or cloud provider IPs that share common reverse DNS patterns, making it difficult to distinguish between benign traffic and malicious spoofing without additional verification steps.
To mitigate this vulnerability, organizations must upgrade BunkerWeb to version 1.6.13 or later, which addresses the logic flaw by ensuring proper validation of hostname-to-IP mappings before applying trust decisions based on rDNS suffixes. Until an upgrade is possible, administrators should consider disabling reliance on PTR-based filtering for critical security controls like blacklisting and antibot challenges if they cannot verify that their DNS infrastructure prevents such spoofing attacks. Additionally, implementing additional layers of defense such as IP reputation services, behavioral analysis, or strict rate limiting independent of rDNS checks can provide compensating controls to reduce the risk posed by this misconfiguration. It is also advisable to review any custom Lua scripts or configurations that interact with reverse DNS lookups to ensure they adhere to best practices for input validation and trust boundary enforcement in network security appliances.