Unbound DNS Resolver CVE-2026-50046

Exploitation requires two non-default configuration conditions to be simultaneously present: a stub or forward zone in Unbound configured for DNS-over-TLS (DoT), AND a #authname suffix appended to the upstream server identification string in that zone's configuration. Unbound instances using plain DNS forwarding, DNS-over-HTTPS, or DoT without the #authname field are not vulnerable. Beyond configuration, successful exploitation further requires the attacker to know which zone is configured for DoT, to sustain sufficient query pressure against that zone to activate Unbound's jostle logic, and to induce a transient upstream DoT connection failure at a precise moment during TLS handshaking - described by the vendor as requiring precise timing. Slow upstream DoT responses increase the window in which jostle and failure can align, slightly easing exploitation. Authentication is not required to send DNS queries (PR:N from CVSS), but the specific configuration prerequisites and tight timing requirements are meaningful real-world constraints that substantially limit exploitability beyond the CVSS score alone.

The CVSS 5.9 Medium rating with AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H accurately characterizes this vulnerability. The high attack complexity (AC:H) is well-supported by the description: successful exploitation requires simultaneous query pressure sufficient to trigger jostle eviction, a transient DoT upstream failure at precisely the right moment in the TLS handshake, and foreknowledge of the target's zone configuration. These are hard real-world constraints that make reliable exploitation difficult even for a skilled adversary. The impact ceiling is a daemon crash - no confidentiality or integrity compromise is possible since the dereference is read-only. The vulnerability has no CISA KEV listing and no known public POC, further reducing near-term risk. EPSS data is not provided but would be expected to be low given the AC:H rating and specific configuration requirements. The CVSS vector and description are fully consistent - no discrepancies to flag. Real-world priority should be high for operators specifically running Unbound as a recursive resolver with DoT forwarding and #authname configuration, and low-to-negligible for all other deployments, including those using Unbound without DoT or without the #authname suffix.

An attacker who has determined through reconnaissance that a target Unbound instance is configured with DoT forwarding and a #authname suffix floods the resolver with DNS queries for the relevant forwarded zone, driving it into the jostle-pressure state, while simultaneously ensuring the upstream DoT server experiences a transient TLS handshake failure - either by controlling the upstream server, interposing on the network path, or exploiting upstream instability. With precise timing, the jostle evicts the serviced_query and frees the TLS server name string; the concurrent TLS error handler then reads the freed memory, causing a segfault and crashing the Unbound daemon. No public exploit code exists at time of analysis.