CVE-2026-50243 in Unbound
Summary
by MITRE • 07/22/2026
In NLnet Labs Unbound 1.6.2 up to and including 1.25.1, when Unbound is configured with the 'respip' module in front of the validator together with a 'response-ip' redirect rule or an RPZ file with an RPZ-IP trigger, the rewriting handler does not check the security status of the upstream answer and can instead rewrite a BOGUS A/AAAA answer to point to an operator's configured IP. If the validator finds an expired or otherwise invalid RRSIG on an answer whose A record falls within a 'response-ip'/RPZ configuration, the answer is still rewritten and given a hard coded security level of INSECURE. This results in the client receiving an INSECURE NOERROR reply rewritten by the operator's configured IP. A malicious actor can exploit the possible poisonous effect by spoofing a BOGUS A/AAAA answer that falls inside the operator's configured subnet rewrites. Such DNSSEC protected answers are then insecurely redirected to the operator's configured target.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability exists in NLnet Labs Unbound DNS resolver versions 1.6.2 through 1.25.1 where the respip module fails to properly validate upstream DNS responses before applying IP redirection rules. The flaw occurs when Unbound is configured with response-ip redirect rules or RPZ files containing RPZ-IP triggers, creating a dangerous condition where malicious actors can exploit the security gap in the rewriting handler. The vulnerability stems from the fact that the rewriting process does not verify the security status of upstream DNS answers, allowing BOGUS A/AAAA records to be rewritten without proper validation checks.
The technical implementation issue manifests when the validator encounters expired or otherwise invalid RRSIG signatures on DNS answers that contain A records falling within configured response-ip or RPZ-IP trigger ranges. Despite the invalid security status, the system still applies the rewrite rule and assigns a hardcoded security level of INSECURE to the modified answer. This behavior creates a fundamental security weakness where legitimate DNSSEC protections are bypassed through the manipulation of response handling logic. The system essentially transforms potentially malicious BOGUS responses into seemingly legitimate answers that appear secure but are actually redirected according to operator configuration.
The operational impact of this vulnerability is significant as it allows attackers to perform cache poisoning attacks by spoofing BOGUS A/AAAA records within the configured subnet ranges. When these poisoned records fall within the operator's redirect rules, they trigger the insecure rewriting process and redirect traffic to the attacker-controlled target IP addresses specified in the configuration. This creates a vector for man-in-the-middle attacks, DNS redirection, and potential compromise of user traffic routing. The vulnerability essentially undermines the DNSSEC security model by allowing malicious actors to bypass cryptographic validation mechanisms through the legitimate response rewriting functionality.
The flaw aligns with CWE-20: Improper Input Validation and CWE-310: Cryptographic Issues, specifically addressing weaknesses in DNSSEC validation and input sanitization within the resolver's response handling pipeline. From an ATT&CK perspective, this vulnerability maps to T1071.004: Application Layer Protocol: DNS and T1566: Phishing, as it enables attackers to manipulate DNS responses to redirect users to malicious infrastructure. The vulnerability also relates to T1499.004: Network Denial of Service and T1212: Exploitation for Credential Access when combined with other attack vectors.
Mitigation strategies should include immediate patching of Unbound to versions beyond 1.25.1 where this vulnerability has been addressed, implementing strict validation of upstream responses before applying any IP rewriting rules, and configuring response-ip and RPZ rules with minimal scope to reduce potential impact. Organizations should also consider implementing additional monitoring for unexpected DNS response patterns and ensure that RPZ configurations do not inadvertently create broad redirection opportunities. Network segmentation and additional DNS security measures such as DNS Firewall rules can provide layered protection against exploitation attempts while awaiting full patch deployment.