Cloudanix VulnDB

CVE-2026-40622

High · 7.5

CVSS

7.5

EPSS

0.1%

Published

May 20, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in a DNS resolver can let attacker-controlled domains keep working longer than they should after being removed or taken down.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Data Tampering
Component
Network Service
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw affects Unbound recursive DNS caching behavior. An attacker who controls a delegated DNS zone can manipulate how Unbound handles cached NS records so that an expired parent-side referral NS rrset is overwritten with the child-zone apex NS rrset. This can extend the lifetime of a “ghost domain” in the resolver cache by up to the configured cache-max-ttl value. The result is an integrity failure in DNS resolution: a domain that should no longer be resolvable after delegation removal or expiration may continue resolving for clients using the vulnerable resolver. The issue is remotely reachable, requires no authentication, and is more easily triggered when harden-referral-path: yes is enabled because Unbound may perform the relevant NS query implicitly.

Why it matters to the business

Organizations using affected Unbound versions may continue resolving attacker-controlled, suspended, or taken-down domains longer than intended. This can help malicious infrastructure remain reachable for phishing, malware delivery, command-and-control, fraud, or abuse operations even after external remediation actions such as domain takedown. The issue is not known to be in CISA KEV, is not currently associated with ransomware campaigns, and has a low EPSS score with no 30-day increase, but it affects a widely deployed recursive DNS resolver and can undermine DNS-based abuse disruption and security controls that rely on timely delegation changes.

How an attack unfolds

An attacker first controls a DNS zone and its authoritative name servers. Clients or the attacker cause the vulnerable Unbound resolver to cache delegation and NS data for that zone. After the parent-side delegation expires, is removed, or is otherwise no longer valid, the attacker causes an NS query for the child-zone apex to reach the resolver. In default configurations, this requires a client NS query; in configurations using harden-referral-path: yes, Unbound may make this query as part of referral hardening. Due to improper handling of the NS rrset trust and TTL behavior, Unbound can overwrite the expired parent-side referral NS records with the child-side apex NS records, effectively extending the ghost domain’s resolvability by up to cache-max-ttl. The attacker can then continue using the domain through clients that rely on the poisoned resolver cache until the extended cache window expires or the resolver is patched/flushed.

How to fix it

Upgrade NLnet Labs Unbound to version 1.25.1 or later. The fixed version prevents TTL extension for parent NS records regardless of trust level. Where immediate upgrade is not possible, reduce cache-max-ttl to limit the maximum ghost-domain extension window, review whether harden-referral-path: yes is required, and flush resolver caches after applying mitigations or upgrading. These mitigations reduce exposure but should not be treated as equivalent to patching. Ensure all packaged, containerized, appliance-bundled, and downstream deployments of Unbound are updated, not only manually installed binaries.

How to confirm the fix worked

Confirm the running Unbound version is 1.25.1 or later using package inventory, service metadata, or unbound -V. Verify that the active service process was restarted after upgrade and is not still running an older binary. Review unbound.conf and included configuration files for cache-max-ttl and harden-referral-path settings to understand residual risk before patching. If using containers or appliances, validate the image or firmware includes the patched Unbound build. After upgrade, flush caches or restart the resolver, then confirm that removed or expired delegations do not continue resolving beyond expected TTL behavior in a controlled test zone.

Typical attack path

  1. Register or otherwise control a DNS zone and authoritative name servers.
  2. Cause a vulnerable Unbound recursive resolver to cache NS/delegation data for the attacker-controlled zone.
  3. Allow or arrange for the parent-side referral data to expire, be removed, or become invalid, such as after domain suspension or takedown.
  4. Trigger an NS query for the child-zone apex, either directly through a client query or indirectly when harden-referral-path: yes is enabled.
  5. Abuse Unbound’s vulnerable cache update behavior to replace the expired parent-side referral NS rrset with the child-side apex NS rrset.
  6. Continue resolving and using the ghost domain through the vulnerable resolver for up to the configured cache-max-ttl value.

How to detect it

To determine whether this behavior was already abused, review recursive DNS telemetry rather than host artifacts. Useful sources include Unbound query logs, dnstap captures, DNS security gateway logs, passive DNS records, resolver cache dumps if available, firewall/proxy logs for traffic to IPs returned by suspicious domains, and registrar or threat-intelligence events showing domain suspension or delegation removal. Look for NS queries for domain apexes followed by continued successful A/AAAA/CNAME/MX lookups after the parent delegation should have expired or disappeared. Pay particular attention to attacker-like infrastructure patterns: newly registered domains, domains later suspended or sinkholed, domains with changing authoritative name servers, and domains that continue returning NOERROR answers from the resolver after external public resolvers return NXDOMAIN, SERVFAIL, or no delegation. In environments with harden-referral-path: yes, investigate resolver-initiated NS lookups for child-zone apexes even when no direct client NS query is visible. Correlate any suspect ghost-domain resolution with outbound HTTP, TLS, SMTP, or other application traffic to the returned addresses to determine business impact.

What your security team should do

  • Prioritize patching internet-facing or enterprise-recursive Unbound resolvers to version 1.25.1 or later.
  • Inventory all Unbound deployments, including embedded resolver instances in appliances, containers, DNS gateways, and security products.
  • Flush resolver caches after patching to remove any potentially extended ghost-domain records.
  • Temporarily lower cache-max-ttl on systems that cannot be upgraded immediately to reduce the maximum persistence window.
  • Review configurations using harden-referral-path: yes because exploitation can be triggered without a direct client NS query in that mode.
  • Enable or retain DNS query/response telemetry, such as dnstap, resolver logs, passive DNS, or DNS security gateway logs, for post-remediation review.
  • Monitor for domains that continue resolving internally after suspension, takedown, registrar hold, or parent delegation removal.
  • Treat detections as abuse-infrastructure persistence events and investigate downstream traffic to any resolved IPs for phishing, malware, or command-and-control activity.

The record

NLnet Labs Unbound 1.16.2 up to and including version 1.25.0 has a vulnerability of the 'ghost domain names' family of attacks that could extend the ghost domain window by up to one cached TTL configured value. Similar to other 'ghost domain names' attacks, an adversary needs to control a (ghost) zone and be able to query a vulnerable Unbound. A single client NS query can cause Unbound to overwrite the cached expired parent-side referral NS rrset with the child-side apex NS rrset and essentially extend the ghost domain window by up to one cached TTL configured value ('cache-max-ttl'). In configurations where 'harden-referral-path: yes' is used (non-default configuration), no client NS query is required since Unbound implicitly performs that query. Unbound 1.25.1 contains a patch with a fix that does not allow extension of TTLs for (parent) NS records regardless of their trust.

Affected packages

Ecosystem Package Introduced Fixed
openSUSE:Leap 16.0 unbound 0 1.24.1-160000.2.1
openSUSE:Tumbleweed unbound 0 1.25.1-1.1

Related vulnerabilities