The remote openSUSE 16 host has packages installed that are affected by multiple vulnerabilities as referenced in the openSUSE-SU-2026:21550-1 advisory.

    Update to version 1.25.2.

    Security issues fixed:

    - CVE-2026-14586: DoS via assertion in `libngtcp2` for DNS-over-QUIC environments with high concurrency     (bsc#1271879).
    - CVE-2026-32665: Remote DNS-over-QUIC denial of service due to `quic-size` budget bypass (bsc#1271873).
    - CVE-2026-40691: DoS due to heap overflow via single bad DNSCrypt query over TCP (bsc#1271875).
    - CVE-2026-41637: Degradation of resolution service due to improperly accounted client-terminated DNS-     over-QUIC queries       (bsc#1271891).
    - CVE-2026-42955: Ghost domain window can be extended by up to one cached TTL configured value for A/AAAA     glue records       (bsc#1271892).
    - CVE-2026-44621: Libunbound applications configured with `unwanted-reply-threshold` could eventually be     abruptly       terminated (bsc#1271876).
    - CVE-2026-44687: Off-by-one error in `harden-below-nxdomain` logic can shadow a stub/forward zone by a     legitimate       parent's `NXDOMAIN` (bsc#1271893).
    - CVE-2026-44690: Cross-zone wildcard cache poisoning via `RRSIG.labels` manipulation (bsc#1271877).
    - CVE-2026-46582: Replay of a wildcard `rrset` as another piece of data triggers poisoning in the server     expired reply       path (bsc#1271894).
    - CVE-2026-50045: `max-global-quota` bypass via single client queries for a deeply nested name under a     DNSSEC-signed       parent (bsc#1271878).
    - CVE-2026-50046: Possible heap use-after-free in an error path when a DoT forwarded query is jostled out     (bsc#1271882).
    - CVE-2026-50243: `response-ip`/`rpz` can rewrite BOGUS answers instead of returning SERVFAIL     (bsc#1271880).
    - CVE-2026-50248: BOGUS configured primary hostname accepted for XFR in auth/rpz zones (bsc#1271881).
    - CVE-2026-50251: Attacker supplied `0.0.0.0`/`::` glue triggers defensive full-cache flush (bsc#1271883).
    - CVE-2026-50252: Possible cache poisoning attack by mapping source port population per thread     (bsc#1271884).
    - CVE-2026-54478: DNS Cookie bypass when proxy-protocol with with `answer-cookie:yes` is used     (bsc#1271895).
    - CVE-2026-55708: Privacy/configuration issue when adding local data in views through `unbound-control`     (bsc#1271896).
    - CVE-2026-55717: `serve-expired-client-timeout` and `response-ip` CNAME redirect could lead to a crash     (bsc#1271886).
    - CVE-2026-55973: DoS due to stack overflow triggered crash when `dns-error-reporting: yes` is set     (bsc#1271874).
    - CVE-2026-55990: Crash via crafted client UDP query due to DNSCrypt faulty configuration (bsc#1271887).
    - CVE-2026-55991: Remote DNS-over-QUIC (DoQ) flow-control reacheable assertion failure in `libngtcp2`     (bsc#1271888).
    - CVE-2026-56416: Possible heap buffer overflow when validator canonicalizes RDATA that contains domain     name       (bsc#1271889).
    - CVE-2026-56444: Degradation of resolution service when `discard-timeout` and `serve-expired-client-     timeout` are       combined in unusual configuration (bsc#1271890).

    Other updates and bugfixes:

    - Version 1.25.2:
      - Features:
        * TTL behavior changes: cached records reaching TTL 0 are expired;
          TTL 0 upstream answers are no longer cached by cachedb;
          serve-expired-reply-ttl is now capped by the original TTL value;
          TTL decoding updated to adhere to RFC 8767 section 4
        * Add new statistics: num.queries.replyaddr_limit and           requestlist.current.replies
        * Add 'log-thread-id' configuration option to log the system-wide           Linux thread ID for easier debugging
        * Add ECC-GOST12 support per RFC 9558 (available as           contrib/gost12.patch)
        * Allow synthesized DNAME TTL=0 to be served from cache within a           1-second grace period, reducing recursion for TTL=0 DNAMEs           (RFC 2308)
        * Fix DoT/DoH/DoQ to reload certificates on config reload without           requiring a full restart; fast_reload now supports changes to           tls-service-key, tls-service-pem and tls-cert-bundle
        * Allow ip@port notation in control-interface configuration
        * Add iter-scrub-rrsig option (default: 8) to limit the number of           RRSIGs processed by the scrubber
        * Add 'tls-protocols' configuration option to select which TLS           protocol versions are used; TLSv1.2 is re-enabled by default
        * Add pthread_setname_np support for named threads
      - Bug Fixes:
        * Fix handle leak in pythonmod on pythonmod_init
        * Fix crash when mesh_detect_cycle_found() is called with no mesh           state
        * Fix modstack_call_init to use the original string when it has           changed
        * Fix fr_atomic_copy_cfg
        * Fix auth-zone empty label for $ORIGIN when downloading via HTTP
        * Fix respip and dns64 to be usable simultaneously; RPZ now works           with DNS64
        * Fix HTTPS and QUIC not being enabled when port is listed in           interface-automatic-ports
        * Allow wait-limit-cookie: 0 to disable cookie-validated wait limits
        * Fix FIPS mode in OpenSSL causing unit test failure
        * Fix discard-timeout to only drop UDP, not stream connections
        * Reply with SERVFAIL when the wait-limit is exceeded
        * Add extended DNS error code for invalid query type
        * Replace deprecated SWIG $function with $action
        * Log a warning for possible circular dependency when using hostnames           in stub/forward zones
        * Fix infra cache for NAT64 by moving NAT64 synthesis to the           delegation point when adding target addresses
        * Fix discard-timeout packet accounting in the mesh area
        * Update IANA portlist
        * Copy DNSTAP configuration from daemon to workers after fast_reload
        * Fix HTTP/2 stream mesh state removal and drop handling for           postpone_drop and send failures
        * Log THROWAWAY and (DNSSEC) LAME responses with clearer           categorization in log output
        * Fix EDE removal logic consistency between encoding errors and           encoding replies
        * Fix EDNS subnet scope-zero queries not being stored when           forward-no-cache or stub-no-cache is set
        * Do not initialize quic_table unless QUIC is enabled
        * Fix fast_reload to copy iter_scrub_ns, iter_scrub_cname and           max_global_quota options
        * Fix allow-notify entries with hostnames to be copied after           IPv4/IPv6 lookup; fix skipping hostname lookups when only URLs           are configured
        * Fix NAT64 inconsistency with do-not-query-address during retries
        * Fix cachedb aggressive negative responses not setting the RA flag
        * Fix root key priming failure after loading RPZ zones containing           ZONEMD RRtype
        * Fix local-zone always_refuse to also block DS queries
        * Fix cache lookup/store in external cachedb when forwarder/stub           uses the no-cache option
        * Fix cachedb returning expired bogus data as non-bogus
        * Fix validator unchecked state handling with validation recursion           and EDNS subnet
        * Fix DNAME lookup flag and assertion in expired calculation debug           routine
        * Fix DNS rebinding bypass via SVCB/HTTPS records; private-address           now also elides SVCB and HTTPS records matching the filter
        * Warn for unused 'nodefault' local-zone configuration in           unbound-checkconf
        * Fix lock/unlock for view in memory error handling
        * Apply cache TTL policy to DNAME and synthesized CNAME on the           wire path
        * Fix detection of HTTP listening port in fast_reload
        * Fix ignoring out-of-zone DNAME records for CNAME synthesis
        * Fix invalid HTTP content length/chunk size checks and RR rdata           field length validation in zone transfer, preventing heap           buffer-overflow read errors
        * Fix defense in depth for service callback with empty packet
        * Fix shared memory statistics with threads
        * Fix EDNS client subnet to not store SERVFAIL in the global cache           after a failed lookup; stores a short-lived failure entry in the           subnet cache instead
        * Fix memory corruption related core dumps when alloc_reg_obtain           encounters an empty list
        * Fix RFC 7766 compliance when client sends EOF over TCP
        * Fix DoH session cleanup when the same query appears on multiple           streams
        * Fix TLS context setup for tls-service-pem
        * Fix TTL comparisons in rdata_copy for 32-bit signed/unsigned values
        * Fix memory leak in subnet SERVFAIL store
        * Fix for the Jiggle Attack: server now answers errors for error           cases and no longer reflects parts of the incoming query
        * Fix EDNS extended RCODE reflection: server no longer echoes           extended RCODE values after CHAOS class queries
        * Fix iterator RCODE handling of YXDOMAIN: only accept YXDOMAIN           answers that contain a DNAME record
        * Fix missing bounds check when decompressing dnames for downloaded           authority zones, preventing malformed content from truncated AXFR           packets
        * Fix upstream TLS connections being reused for different names at           the same IP address
        * Fix to disallow signatures with revoked DNSKEYs
        * Fix DNAME with unsigned CNAME to check for the correct match,           preventing certain zone configurations from granting secure status           to unchecked CNAMEs
        * Fix wildcard CNAME handling in the chain of trust
        * Fix buffer overrun in doq_repinfo_retrieve_localaddr()
      - Packaging changes:
        * Update keyring to new NLnet Labs release signing key

Tenable has extracted the preceding description block directly from the SUSE security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

An update of the unbound package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set     to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that     can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote     IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue     records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive     cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can     drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of     the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator     uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over     loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and     127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The     counter resets to zero on every cache flush, so the attack loops forever. (CVE-2026-50251)

Note that Nessus relies on the presence of the package as reported by the vendor.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1786637650 advisory.

  - The DNS protocol in RFC 1035 and updates allows remote attackers to cause a denial of service (resource     consumption) by arranging for DNS queries to be accumulated for seconds, such that responses are later     sent in a pulsing burst (which can be considered traffic amplification in some cases), aka the DNSBomb     issue. (CVE-2024-33655)

  - DISPUTE NOTE: this issue does not pose a security risk as it (according to analysis by the original     software developer, NLnet Labs) falls within the expected functionality and security controls of the     application. Red Hat has made a claim that there is a security risk within Red Hat products. NLnet Labs     has no further information about the claim, and suggests that affected Red Hat customers refer to     available Red Hat documentation or support channels. ORIGINAL DESCRIPTION: A NULL pointer dereference flaw     was found in the ub_ctx_set_fwd function in Unbound. This issue could allow an attacker who can invoke     specific sequences of API calls to cause a segmentation fault. When certain API functions such as     ub_ctx_set_fwd and ub_ctx_resolvconf are called in a particular order, the program attempts to read from a     NULL pointer, leading to a crash. This issue can result in a denial of service by causing the application     to terminate unexpectedly. (CVE-2024-43167)

  - In NLnet Labs Unbound 1.16.2 up to and including 1.25.1, a similar vulnerability as with CVE-2026-40622 in     the 'ghost domain names' family of attacks was found in Unbound that could extend the ghost domain window     by up to one cached TTL configured value for A/AAAA glue records. 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 A/AAAA query can cause Unbound to overwrite the cached expired parent-side glue 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 query is     required since Unbound implicitly performs that query. This is a variant of CVE-2026-40622 which only     addressed the NS query. (CVE-2026-42955)

  - With NLnet Labs Unbound up to and including version 1.25.1, applications using libunbound and configured     with 'unwanted-reply-threshold', could eventually be abruptly terminated if the threshold is reached and     libunbound needs to call 'libworker_alloc_cleanup' since the function is absent from the function call     allow list. When an application using libunbound sets 'unwanted-reply-threshold' to any non-zero value and     the iterator queries an authoritative that replies with enough wrong-transaction-ID UDP datagrams to cross     the threshold, the 'libworker_alloc_cleanup' will eventually be called. Since the function is absent from     the function call allow list, this leads to a fatal exit of libunbound and eventual termination of the     embedding application.Unbound itself is not affected since its relevant function 'worker_alloc_cleanup' is     registed in the allow list and proceeds to perform the documented cache flush. (CVE-2026-44621)

  - In NLnet Labs Unbound 1.13.2 up to and including 1.25.1, stub or forward zones where the name is below an     intermediate labed below a DNSSEC signed zone could be shadowed by the intermediate label's secure     NXDOMAIN answer from the parent. This is caused by an off-by-one error in 'harden-below-nxdomain' logic;
    enabled by default. It effectively bypasses the configuration and the configured stub/forward zone is     never contacted. 'harden-below-nxdomain' does an upward DNS cache walk together with a delegation point     guard that does not allow NXDOMAIN synthesis above stub/forward zones. The guard tests the domain name but     before stripping a label. This results in an iteration where the domain name equals the configured     stub/forward zone apex that passes the guard, strips one more label, and probes the cache at the apex's     immediate public parent. If that parent has a cached DNSSEC-secure NXDOMAIN, which it will for any private     namespace nested two or more labels under a signed public name, the walk returns it and the configured     stub/forward upstream is never contacted. This can only be triggered by the query for the intermediate     label (between the stub/forward apex and the DNSSEC parent zone). (CVE-2026-44687)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

According to the versions of the unbound packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

    In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, the 'view_local_data' and 'view_local_datas'     commands of 'unbound-control' create a bare local zones tree for an already configured named view when the     view is configured with no local data to begin with. However, the creation through the control interface     omits adding the default-protected zones (e.g., RFC 1918 reverse, AS112 zones, .onion, .localhost). Once     the local zone tree exists without the defaults, every query for a default-protected name from a client     mapped to that view escapes to the public DNS via the iterator instead of being answered locally,     bypassing local policy expectations.(CVE-2026-55708)

    In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to     serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing     policies depend on the source port while their outcome is revealed this secrecy is undermined. The     vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP     port and IP address while heavily depending on the incoming source UDP port as a randomization source.
    When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it     meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound     randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size,     assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel's     SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a     particular thread. All outgoing DNS queries generated during the resolution of that request use source     ports selected exclusively from the port subset assigned to the corresponding thread. Since these port     subsets are disjoint across threads, the source port observed in a resolver's outgoing query to an     authoritative name server serves as a reliable indicator of the worker thread that processed the original     client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given     fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks     by effectively lowering the random port population per thread.(CVE-2026-50252)

    In NLnet Labs Unbound 1.15.0 up to and including 1.25.1, the TLS server name used for DNS-over-TLS (DoT)     forwarded queries is tied to a struct's ('serviced_query') lifetime but also referenced by another struct     ('waiting_tcp'). When the owning struct is jostled out of the mesh while the DoT TCP stream is still     handshaking it frees the storage behind the referenced string and if the TLS stream then errors out, it     dereferences the freed pointer. The dereference is read-only and the practical impact is a daemon crash     resulting in denial of service. A malicious actor that knows a DoT forwarding/stub Unbound's configuration     could exploit the vulnerability by quering records in the appropriate zone while keeping Unbound uder     pressure so that the jostle logic kicks in. If answers for the vulnerable zone are slow, the likelihood of     jostling such queries is higher, although the timing of the jostle needs to be precise. Requirements for a     vulnerable Unbound is the existence of a stub/forward zone configured for DoT together with a configured     '#authname' suffix on the server identification. The connectivity to the server needs to exhibit a     transient failure at the correct time in order to kick off the vulnerable error path.(CVE-2026-50046)

    In NLnet Labs Unbound up to and including version 1.25.1, when the validator builds the canonical RDATA     form for an RRSIG-covered PX/RP/MINFO/SOA RRset, it computes the address of the second embedded domain     name as 'datstart + dname_valid(datstart, ...)' and passes it straight to 'query_dname_tolower()' without     checking that a second name is actually present in the RDATA. The wire-format parser accepts multi-dname     RRs whose RDATA ends after the first name, so an attacker who runs a DNSSEC-signed authoritative server     can deliver a record with an absent second domain name (e.g. SOA record) and cause 'query_dname_tolower()'     to walk label-by-label through stale bytes in the per-worker 'env-scratch_buffer', past the end of that     heap allocation if 'msg-buffer-size' has been lowered from the default. This leads to heap buffer overflow     and on a release build the outcome relies heavily on the contents of the buffer tail and the adjacent heap     chunk.(CVE-2026-56416)

    In NLnet Labs Unbound 1.16.2 up to and including 1.25.1, a similar vulnerability as with CVE-2026-40622 in     the 'ghost domain names' family of attacks was found in Unbound that could extend the ghost domain window     by up to one cached TTL configured value for A/AAAA glue records. 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 A/AAAA query can cause Unbound to overwrite the cached expired parent-side glue 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 query is     required since Unbound implicitly performs that query. This is a variant of CVE-2026-40622 which only     addressed the NS query.(CVE-2026-42955)

    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.(CVE-2026-50243)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when the 'dnscrypt:' clause lists more 'dnscrypt-     provider-cert:' files than there are matching 'dnscrypt-secret-key:' files, Unbound fills only the matched     prefix and leaves the tail slots at the '0xdb' fill that libsodium's allocator writes into every     allocation. Unbound would then iterate over the number of cert files, not the actual slots, so it walks     into a slot with garbage data filled with '0xdb' bytes. Any unauthenticated client that sends one UDP     datagram of  68 bytes whose first 8 bytes are '0xdb' to 'dnscrypt-port' will use that garbage entry     which leads to a garbage dereference killing the server. This is a silent faulty configuration that goes     unnoticed until triggered with the right client query. Unbound needs to be compiled with DNSCrypt support     ('--enable-dnscrypt').(CVE-2026-55990)

    With NLnet Labs Unbound up to and including version 1.25.1, applications using libunbound and configured     with 'unwanted-reply-threshold', could eventually be abruptly terminated if the threshold is reached and     libunbound needs to call 'libworker_alloc_cleanup' since the function is absent from the function call     allow list. When an application using libunbound sets 'unwanted-reply-threshold' to any non-zero value and     the iterator queries an authoritative that replies with enough wrong-transaction-ID UDP datagrams to cross     the threshold, the 'libworker_alloc_cleanup' will eventually be called. Since the function is absent from     the function call allow list, this leads to a fatal exit of libunbound and eventual termination of the     embedding application.Unbound itself is not affected since its relevant function 'worker_alloc_cleanup' is     registed in the allow list and proceeds to perform the documented cache flush.(CVE-2026-44621)

    In NLnet Labs Unbound 1.13.2 up to and including 1.25.1, stub or forward zones where the name is below an     intermediate labed below a DNSSEC signed zone could be shadowed by the intermediate label's secure     NXDOMAIN answer from the parent. This is caused by an off-by-one error in 'harden-below-nxdomain' logic;
    enabled by default. It effectively bypasses the configuration and the configured stub/forward zone is     never contacted. 'harden-below-nxdomain' does an upward DNS cache walk together with a delegation point     guard that does not allow NXDOMAIN synthesis above stub/forward zones. The guard tests the domain name but     before stripping a label. This results in an iteration where the domain name equals the configured     stub/forward zone apex that passes the guard, strips one more label, and probes the cache at the apex's     immediate public parent. If that parent has a cached DNSSEC-secure NXDOMAIN, which it will for any private     namespace nested two or more labels under a signed public name, the walk returns it and the configured     stub/forward upstream is never contacted. This can only be triggered by the query for the intermediate     label (between the stub/forward apex and the DNSSEC parent zone).(CVE-2026-44687)

    In NLnet Labs Unbound 1.10.0 up to and including 1.25.1, when 'serve-expired: yes' is set together with a     'response-ip: net redirect' /'response-ip-data: net CNAME target' rule (or the RPZ 'rpz-     cname-override' equivalent), a remote client who controls any delegated domain can crash the daemon. The     serve-expired-client-timeout callback runs a two-pass loop to chase the respip-generated CNAME alias; on     the second pass it resets 'alias_rrset' but not 'partial_rep'. Later, this inconsistency leads to a NULL     pointer dereference and an eventual crash. A malicious actor can exploit the vulnerability by controlling     any zone that replies with an A/AAAA record that falls inside the configured response-ip/rpz subnet. By     delaying the answer when the previous record has expired, the vulnerable path of 'serve-expired-client-     timeout' is taken leading to denial of service via the server crash.(CVE-2026-55717)

    In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of     data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache,     before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure     on the rrset, and another thread that is on the serve expired path then picks up the updated rrset     contents with the secure status for a reply, it can be used to change a specific record, next to a     wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the     possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME     wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then     quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry)     query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is     injected into the response, the wildcard rrset will update the expired sibling record with a secure status     before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper     answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability     is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC     accompanying rrset.(CVE-2026-46582)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when an auth/rpz zone has a configured primary     hostname that resolves to BOGUS A/AAAA, it is still considered as a possible XFR endpoint. A malicious     actor that can spoof the hostname's A/AAAA record (no valid RRSIG required) becomes the zone's XFR primary     and can replaces the entire zone/the resolver's entire response policy.(CVE-2026-50248)

    In Unbound 1.9.0 up to and including 1.25.1, when a DNSCrypt query is received over TCP, the routine that     encrypts the reply in place fails to bound the reply length against the destination buffer size. The size     clamp that protects the UDP path is not applied on the TCP path, so a reply larger than 65504 bytes is     shifted forward by 48 bytes inside a buffer of capacity equal to 'msg-buffer-size', writing past the end     of the heap allocation. A single malicious encrypted query crashes the resolver and lead to denial of     service. This vulnerability needs Unbound to be compiled with DNSCrypt support ('--enable-dnscrypt') and     the 'dnscrypt:' clause to be configured and enabled for the listening interfaces.(CVE-2026-40691)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, insufficient validation of the RRSIG.Labels field     combined with premature cache writes during RFC 8198 aggressive NSEC processing leads to cache poisoning     that permits a malicious actor controlling a single delegated zone to poison arbitrary sibling zones under     NSEC-signed parent domains. A malicious actor with one registered domain under an NSEC-signed TLD can     serve malicious insecure DNS responses for unrelated sibling domains (sharing the same parent zone).
    Arbitrary delegations that do not exist under the parent domain and are covered by the parent's NSEC chain     can be brought into insecure existence by fraudulent wildcard DS records (less labels than expected,     unknown algorithm) from the malicious sibling domain. This allows the malicious actor to inject insecure     wildcard records for those delegations.(CVE-2026-44690)

    In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set     to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that     can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote     IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue     records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive     cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can     drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of     the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator     uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over     loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and     127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The     counter resets to zero on every cache flush, so the attack loops forever.(CVE-2026-50251)

Tenable has extracted the preceding description block directly from the EulerOS unbound security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of unbound installed on the remote host is prior to 1.7.3-15. It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2-2026-3849 advisory.

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, insufficient validation of the RRSIG.Labels field     combined with premature cache writes during RFC 8198 aggressive NSEC processing leads to cache poisoning     that permits a malicious actor controlling a single delegated zone to poison arbitrary sibling zones under     NSEC-signed parent domains. A malicious actor with one registered domain under an NSEC-signed TLD can     serve malicious insecure DNS responses for unrelated sibling domains (sharing the same parent zone).
    Arbitrary delegations that do not exist under the parent domain and are covered by the parent's NSEC chain     can be brought into insecure existence by fraudulent wildcard DS records (less labels than expected,     unknown algorithm) from the malicious sibling domain. This allows the malicious actor to inject insecure     wildcard records for those delegations. (CVE-2026-44690)

    In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set     to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that     can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote     IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue     records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive     cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can     drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of     the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator     uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over     loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and     127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The     counter resets to zero on every cache flush, so the attack loops forever. (CVE-2026-50251)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

According to the versions of the unbound packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, insufficient validation of the RRSIG.Labels field     combined with premature cache writes during RFC 8198 aggressive NSEC processing leads to cache poisoning     that permits a malicious actor controlling a single delegated zone to poison arbitrary sibling zones under     NSEC-signed parent domains. A malicious actor with one registered domain under an NSEC-signed TLD can     serve malicious insecure DNS responses for unrelated sibling domains (sharing the same parent zone).
    Arbitrary delegations that do not exist under the parent domain and are covered by the parent's NSEC chain     can be brought into insecure existence by fraudulent wildcard DS records (less labels than expected,     unknown algorithm) from the malicious sibling domain. This allows the malicious actor to inject insecure     wildcard records for those delegations.(CVE-2026-44690)

    In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set     to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that     can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote     IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue     records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive     cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can     drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of     the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator     uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over     loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and     127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The     counter resets to zero on every cache flush, so the attack loops forever.(CVE-2026-50251)

    With NLnet Labs Unbound up to and including version 1.25.1, applications using libunbound and configured     with 'unwanted-reply-threshold', could eventually be abruptly terminated if the threshold is reached and     libunbound needs to call 'libworker_alloc_cleanup' since the function is absent from the function call     allow list. When an application using libunbound sets 'unwanted-reply-threshold' to any non-zero value and     the iterator queries an authoritative that replies with enough wrong-transaction-ID UDP datagrams to cross     the threshold, the 'libworker_alloc_cleanup' will eventually be called. Since the function is absent from     the function call allow list, this leads to a fatal exit of libunbound and eventual termination of the     embedding application.Unbound itself is not affected since its relevant function 'worker_alloc_cleanup' is     registed in the allow list and proceeds to perform the documented cache flush.(CVE-2026-44621)

    In NLnet Labs Unbound 1.13.2 up to and including 1.25.1, stub or forward zones where the name is below an     intermediate labed below a DNSSEC signed zone could be shadowed by the intermediate label's secure     NXDOMAIN answer from the parent. This is caused by an off-by-one error in 'harden-below-nxdomain' logic;
    enabled by default. It effectively bypasses the configuration and the configured stub/forward zone is     never contacted. 'harden-below-nxdomain' does an upward DNS cache walk together with a delegation point     guard that does not allow NXDOMAIN synthesis above stub/forward zones. The guard tests the domain name but     before stripping a label. This results in an iteration where the domain name equals the configured     stub/forward zone apex that passes the guard, strips one more label, and probes the cache at the apex's     immediate public parent. If that parent has a cached DNSSEC-secure NXDOMAIN, which it will for any private     namespace nested two or more labels under a signed public name, the walk returns it and the configured     stub/forward upstream is never contacted. This can only be triggered by the query for the intermediate     label (between the stub/forward apex and the DNSSEC parent zone).(CVE-2026-44687)

    In NLnet Labs Unbound 1.10.0 up to and including 1.25.1, when 'serve-expired: yes' is set together with a     'response-ip: net redirect' /'response-ip-data: net CNAME target' rule (or the RPZ 'rpz-     cname-override' equivalent), a remote client who controls any delegated domain can crash the daemon. The     serve-expired-client-timeout callback runs a two-pass loop to chase the respip-generated CNAME alias; on     the second pass it resets 'alias_rrset' but not 'partial_rep'. Later, this inconsistency leads to a NULL     pointer dereference and an eventual crash. A malicious actor can exploit the vulnerability by controlling     any zone that replies with an A/AAAA record that falls inside the configured response-ip/rpz subnet. By     delaying the answer when the previous record has expired, the vulnerable path of 'serve-expired-client-     timeout' is taken leading to denial of service via the server crash.(CVE-2026-55717)

    In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of     data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache,     before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure     on the rrset, and another thread that is on the serve expired path then picks up the updated rrset     contents with the secure status for a reply, it can be used to change a specific record, next to a     wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the     possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME     wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then     quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry)     query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is     injected into the response, the wildcard rrset will update the expired sibling record with a secure status     before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper     answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability     is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC     accompanying rrset.(CVE-2026-46582)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when an auth/rpz zone has a configured primary     hostname that resolves to BOGUS A/AAAA, it is still considered as a possible XFR endpoint. A malicious     actor that can spoof the hostname's A/AAAA record (no valid RRSIG required) becomes the zone's XFR primary     and can replaces the entire zone/the resolver's entire response policy.(CVE-2026-50248)

    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.(CVE-2026-50243)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when the 'dnscrypt:' clause lists more 'dnscrypt-     provider-cert:' files than there are matching 'dnscrypt-secret-key:' files, Unbound fills only the matched     prefix and leaves the tail slots at the '0xdb' fill that libsodium's allocator writes into every     allocation. Unbound would then iterate over the number of cert files, not the actual slots, so it walks     into a slot with garbage data filled with '0xdb' bytes. Any unauthenticated client that sends one UDP     datagram of  68 bytes whose first 8 bytes are '0xdb' to 'dnscrypt-port' will use that garbage entry     which leads to a garbage dereference killing the server. This is a silent faulty configuration that goes     unnoticed until triggered with the right client query. Unbound needs to be compiled with DNSCrypt support     ('--enable-dnscrypt').(CVE-2026-55990)

    In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to     serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing     policies depend on the source port while their outcome is revealed this secrecy is undermined. The     vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP     port and IP address while heavily depending on the incoming source UDP port as a randomization source.
    When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it     meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound     randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size,     assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel's     SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a     particular thread. All outgoing DNS queries generated during the resolution of that request use source     ports selected exclusively from the port subset assigned to the corresponding thread. Since these port     subsets are disjoint across threads, the source port observed in a resolver's outgoing query to an     authoritative name server serves as a reliable indicator of the worker thread that processed the original     client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given     fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks     by effectively lowering the random port population per thread.(CVE-2026-50252)

    In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, the 'view_local_data' and 'view_local_datas'     commands of 'unbound-control' create a bare local zones tree for an already configured named view when the     view is configured with no local data to begin with. However, the creation through the control interface     omits adding the default-protected zones (e.g., RFC 1918 reverse, AS112 zones, .onion, .localhost). Once     the local zone tree exists without the defaults, every query for a default-protected name from a client     mapped to that view escapes to the public DNS via the iterator instead of being answered locally,     bypassing local policy expectations.(CVE-2026-55708)

    In NLnet Labs Unbound up to and including version 1.25.1, when the validator builds the canonical RDATA     form for an RRSIG-covered PX/RP/MINFO/SOA RRset, it computes the address of the second embedded domain     name as 'datstart + dname_valid(datstart, ...)' and passes it straight to 'query_dname_tolower()' without     checking that a second name is actually present in the RDATA. The wire-format parser accepts multi-dname     RRs whose RDATA ends after the first name, so an attacker who runs a DNSSEC-signed authoritative server     can deliver a record with an absent second domain name (e.g. SOA record) and cause 'query_dname_tolower()'     to walk label-by-label through stale bytes in the per-worker 'env-scratch_buffer', past the end of that     heap allocation if 'msg-buffer-size' has been lowered from the default. This leads to heap buffer overflow     and on a release build the outcome relies heavily on the contents of the buffer tail and the adjacent heap     chunk.(CVE-2026-56416)

Tenable has extracted the preceding description block directly from the EulerOS unbound security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Fedora 43 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2026-3170ee6a1c advisory.

    Update to 1.25.2 (rhbz#2506061)

    Security fixes:

    - Fix CVE-2026-14586, Assertion in libngtcp2 when under pressure in high concurrency DNS-over-QUIC     environments. Thanks to Kunta Chu, Kaihua Wang, and Jianjun Chen from Tsinghua University, for the report.
    - Fix CVE-2026-32665, Remote DNS-over-QUIC denial of service due to `quic-size` budget bypass. Thanks to     N0zoM1z0 (https://github.com/N0zoM1z0) for the report. In addition, thanks to Kunta Chu, Kaihua Wang, and     Jianjun Chen from Tsinghua University, for also reporting this issue. In addition, thanks to Qifan Zhang,     Palo Alto Networks, for also reporting this issue. In addition, thanks to Xuanchao Xie, for also reporting     this issue.
    - Fix CVE-2026-40691, Packet of death for DNSCrypt over TCP. Thanks to Qifan Zhang, Palo Alto Networks,     for the report. In addition, thanks to Trung Nguyen (@everping) of CyStack, for also reporting this issue.
    - Fix CVE-2026-41637, Degradation of resolution service from improperly accounted client-terminated DNS-     over-QUIC queries. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-42955, Extra fix for CVE-2026-40622 to also clamp the TTL of A/AAAA records disallowing a     one-time 'ghost domain' delegation renewal via glue records. Thanks to Qifan Zhang, Palo Alto Networks,     for the report.
    - Fix CVE-2026-44621, Libunbound applications configured with 'unwanted-reply-threshold' could eventually     be abruptly terminated. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-44687, Off-by-one error in 'harden-below-nxdomain' logic can shadow a stub/forward zone by     a legitimate parent's NXDOMAIN. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-44690, Cross-zone wildcard cache poisoning via RRSIG.labels manipulation. Thanks to Qifan     Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-46582, A wildcard replay, as another piece of data, triggers poisoning in the serve expired     reply path. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-50045, 'max-global-quota' reset by DNSSEC validation restarts. Thanks to Kunjie Shang,     University of Science and Technology of China, for the report.
    - Fix CVE-2026-50046, Possible heap use-after-free in an error path when a DoT forwarded query is jostled     out. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-50243, 'response-ip'/'rpz' can rewrite BOGUS answers instead of returning SERVFAIL. Thanks     to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-50248, BOGUS configured primary hostname accepted for XFR in auth/rpz zones. Thanks to     Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-50251, Attacker supplied `0.0.0.0`/`::` glue triggers defensive full-cache flush. Thanks to     Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-50252, Possible cache poisoning attack by mapping source port population per thread. Thanks     to Inbal Schussheim and Amit Klein, Hebrew University, for the report.
    - Fix CVE-2026-52863, Memory corruption could lead to crash and denial of service. Thanks to Qifan Zhang,     Palo Alto Networks, for the report.
    - Fix CVE-2026-54478, DNS Cookie bypass when combined with proxy-protocol use. Thanks to Qifan Zhang, Palo     Alto Networks, for the report.
    - Fix CVE-2026-55708, Privacy/configuration issue when adding local data in views through 'unbound-     control'. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-55717, 'serve-expired-client-timeout' and 'response-ip' CNAME redirect could lead to a     crash. Thanks to Qifan Zhang, Palo Alto Networks, for the report. In addition, thanks to Xin Wang, Jiapeng     Li, and Jiajia Liu, Northwestern Polytechnical University, for also reporting this issue.
    - Fix CVE-2026-55973, 'dns-error-reporting: yes' leads to stack buffer overflow. Thanks to Qifan Zhang,     Palo Alto Networks, for the report.
    - Fix CVE-2026-55990, Packet of death for a DNSCrypt misconfigured Unbound. Thanks to Qifan Zhang, Palo     Alto Networks, for the report.
    - Fix CVE-2026-55991, Remote DNS-over-QUIC (DoQ) flow-control assertion failure in libngtcp2. Thanks to     Qifan Zhang, Palo Alto Networks, for the report. In addition, thanks to Xuanchao Xie, for also reporting     this issue.
    - Fix CVE-2026-56416, Possible heap buffer overflow when validator canonicalizes RDATA that contains     domain name. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    - Fix CVE-2026-56444, Degradation of resolution service when 'discard-timeout' and 'serve-expired-client-     timeout' are combined in unusual configuration. Thanks to Qifan Zhang, Palo Alto Networks, for the report.
    In addition, thanks to Xin Wang, Jiapeng Li, and Jiajia Liu, Northwestern Polytechnical University, for     also reporting this issue. In addition, thanks to Haruki Oyama (Waseda University), for also reporting     this issue.

    Source: https://nlnetlabs.nl/projects/unbound/download/#unbound-1-25-2



Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

According to the versions of the unbound packages installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

    In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, the 'view_local_data' and 'view_local_datas'     commands of 'unbound-control' create a bare local zones tree for an already configured named view when the     view is configured with no local data to begin with. However, the creation through the control interface     omits adding the default-protected zones (e.g., RFC 1918 reverse, AS112 zones, .onion, .localhost). Once     the local zone tree exists without the defaults, every query for a default-protected name from a client     mapped to that view escapes to the public DNS via the iterator instead of being answered locally,     bypassing local policy expectations.(CVE-2026-55708)

    In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to     serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing     policies depend on the source port while their outcome is revealed this secrecy is undermined. The     vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP     port and IP address while heavily depending on the incoming source UDP port as a randomization source.
    When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it     meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound     randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size,     assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel's     SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a     particular thread. All outgoing DNS queries generated during the resolution of that request use source     ports selected exclusively from the port subset assigned to the corresponding thread. Since these port     subsets are disjoint across threads, the source port observed in a resolver's outgoing query to an     authoritative name server serves as a reliable indicator of the worker thread that processed the original     client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given     fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks     by effectively lowering the random port population per thread.(CVE-2026-50252)

    In NLnet Labs Unbound 1.15.0 up to and including 1.25.1, the TLS server name used for DNS-over-TLS (DoT)     forwarded queries is tied to a struct's ('serviced_query') lifetime but also referenced by another struct     ('waiting_tcp'). When the owning struct is jostled out of the mesh while the DoT TCP stream is still     handshaking it frees the storage behind the referenced string and if the TLS stream then errors out, it     dereferences the freed pointer. The dereference is read-only and the practical impact is a daemon crash     resulting in denial of service. A malicious actor that knows a DoT forwarding/stub Unbound's configuration     could exploit the vulnerability by quering records in the appropriate zone while keeping Unbound uder     pressure so that the jostle logic kicks in. If answers for the vulnerable zone are slow, the likelihood of     jostling such queries is higher, although the timing of the jostle needs to be precise. Requirements for a     vulnerable Unbound is the existence of a stub/forward zone configured for DoT together with a configured     '#authname' suffix on the server identification. The connectivity to the server needs to exhibit a     transient failure at the correct time in order to kick off the vulnerable error path.(CVE-2026-50046)

    In NLnet Labs Unbound up to and including version 1.25.1, when the validator builds the canonical RDATA     form for an RRSIG-covered PX/RP/MINFO/SOA RRset, it computes the address of the second embedded domain     name as 'datstart + dname_valid(datstart, ...)' and passes it straight to 'query_dname_tolower()' without     checking that a second name is actually present in the RDATA. The wire-format parser accepts multi-dname     RRs whose RDATA ends after the first name, so an attacker who runs a DNSSEC-signed authoritative server     can deliver a record with an absent second domain name (e.g. SOA record) and cause 'query_dname_tolower()'     to walk label-by-label through stale bytes in the per-worker 'env-scratch_buffer', past the end of that     heap allocation if 'msg-buffer-size' has been lowered from the default. This leads to heap buffer overflow     and on a release build the outcome relies heavily on the contents of the buffer tail and the adjacent heap     chunk.(CVE-2026-56416)

    In NLnet Labs Unbound 1.16.2 up to and including 1.25.1, a similar vulnerability as with CVE-2026-40622 in     the 'ghost domain names' family of attacks was found in Unbound that could extend the ghost domain window     by up to one cached TTL configured value for A/AAAA glue records. 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 A/AAAA query can cause Unbound to overwrite the cached expired parent-side glue 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 query is     required since Unbound implicitly performs that query. This is a variant of CVE-2026-40622 which only     addressed the NS query.(CVE-2026-42955)

    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.(CVE-2026-50243)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when the 'dnscrypt:' clause lists more 'dnscrypt-     provider-cert:' files than there are matching 'dnscrypt-secret-key:' files, Unbound fills only the matched     prefix and leaves the tail slots at the '0xdb' fill that libsodium's allocator writes into every     allocation. Unbound would then iterate over the number of cert files, not the actual slots, so it walks     into a slot with garbage data filled with '0xdb' bytes. Any unauthenticated client that sends one UDP     datagram of  68 bytes whose first 8 bytes are '0xdb' to 'dnscrypt-port' will use that garbage entry     which leads to a garbage dereference killing the server. This is a silent faulty configuration that goes     unnoticed until triggered with the right client query. Unbound needs to be compiled with DNSCrypt support     ('--enable-dnscrypt').(CVE-2026-55990)

    With NLnet Labs Unbound up to and including version 1.25.1, applications using libunbound and configured     with 'unwanted-reply-threshold', could eventually be abruptly terminated if the threshold is reached and     libunbound needs to call 'libworker_alloc_cleanup' since the function is absent from the function call     allow list. When an application using libunbound sets 'unwanted-reply-threshold' to any non-zero value and     the iterator queries an authoritative that replies with enough wrong-transaction-ID UDP datagrams to cross     the threshold, the 'libworker_alloc_cleanup' will eventually be called. Since the function is absent from     the function call allow list, this leads to a fatal exit of libunbound and eventual termination of the     embedding application.Unbound itself is not affected since its relevant function 'worker_alloc_cleanup' is     registed in the allow list and proceeds to perform the documented cache flush.(CVE-2026-44621)

    In NLnet Labs Unbound 1.13.2 up to and including 1.25.1, stub or forward zones where the name is below an     intermediate labed below a DNSSEC signed zone could be shadowed by the intermediate label's secure     NXDOMAIN answer from the parent. This is caused by an off-by-one error in 'harden-below-nxdomain' logic;
    enabled by default. It effectively bypasses the configuration and the configured stub/forward zone is     never contacted. 'harden-below-nxdomain' does an upward DNS cache walk together with a delegation point     guard that does not allow NXDOMAIN synthesis above stub/forward zones. The guard tests the domain name but     before stripping a label. This results in an iteration where the domain name equals the configured     stub/forward zone apex that passes the guard, strips one more label, and probes the cache at the apex's     immediate public parent. If that parent has a cached DNSSEC-secure NXDOMAIN, which it will for any private     namespace nested two or more labels under a signed public name, the walk returns it and the configured     stub/forward upstream is never contacted. This can only be triggered by the query for the intermediate     label (between the stub/forward apex and the DNSSEC parent zone).(CVE-2026-44687)

    In NLnet Labs Unbound 1.10.0 up to and including 1.25.1, when 'serve-expired: yes' is set together with a     'response-ip: net redirect' /'response-ip-data: net CNAME target' rule (or the RPZ 'rpz-     cname-override' equivalent), a remote client who controls any delegated domain can crash the daemon. The     serve-expired-client-timeout callback runs a two-pass loop to chase the respip-generated CNAME alias; on     the second pass it resets 'alias_rrset' but not 'partial_rep'. Later, this inconsistency leads to a NULL     pointer dereference and an eventual crash. A malicious actor can exploit the vulnerability by controlling     any zone that replies with an A/AAAA record that falls inside the configured response-ip/rpz subnet. By     delaying the answer when the previous record has expired, the vulnerable path of 'serve-expired-client-     timeout' is taken leading to denial of service via the server crash.(CVE-2026-55717)

    In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, a replay of a wildcard rrset as another piece of     data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache,     before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure     on the rrset, and another thread that is on the serve expired path then picks up the updated rrset     contents with the secure status for a reply, it can be used to change a specific record, next to a     wildcard that could be covered by the wildcard, into the wildcard. A malicious actor can exploit the     possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME     wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then     quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry)     query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is     injected into the response, the wildcard rrset will update the expired sibling record with a secure status     before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper     answer as bogus. The updated poisoned rrset is now secure and points to the wildcard. This vulnerability     is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC     accompanying rrset.(CVE-2026-46582)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when an auth/rpz zone has a configured primary     hostname that resolves to BOGUS A/AAAA, it is still considered as a possible XFR endpoint. A malicious     actor that can spoof the hostname's A/AAAA record (no valid RRSIG required) becomes the zone's XFR primary     and can replaces the entire zone/the resolver's entire response policy.(CVE-2026-50248)

    In Unbound 1.9.0 up to and including 1.25.1, when a DNSCrypt query is received over TCP, the routine that     encrypts the reply in place fails to bound the reply length against the destination buffer size. The size     clamp that protects the UDP path is not applied on the TCP path, so a reply larger than 65504 bytes is     shifted forward by 48 bytes inside a buffer of capacity equal to 'msg-buffer-size', writing past the end     of the heap allocation. A single malicious encrypted query crashes the resolver and lead to denial of     service. This vulnerability needs Unbound to be compiled with DNSCrypt support ('--enable-dnscrypt') and     the 'dnscrypt:' clause to be configured and enabled for the listening interfaces.(CVE-2026-40691)

    In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, insufficient validation of the RRSIG.Labels field     combined with premature cache writes during RFC 8198 aggressive NSEC processing leads to cache poisoning     that permits a malicious actor controlling a single delegated zone to poison arbitrary sibling zones under     NSEC-signed parent domains. A malicious actor with one registered domain under an NSEC-signed TLD can     serve malicious insecure DNS responses for unrelated sibling domains (sharing the same parent zone).
    Arbitrary delegations that do not exist under the parent domain and are covered by the parent's NSEC chain     can be brought into insecure existence by fraudulent wildcard DS records (less labels than expected,     unknown algorithm) from the malicious sibling domain. This allows the malicious actor to inject insecure     wildcard records for those delegations.(CVE-2026-44690)

    In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set     to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that     can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote     IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue     records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive     cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can     drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of     the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator     uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over     loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and     127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The     counter resets to zero on every cache flush, so the attack loops forever.(CVE-2026-50251)

Tenable has extracted the preceding description block directly from the EulerOS Virtualization unbound security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2026:97497 advisory.

    The unbound packages provide a validating, recursive, and caching DNS or DNSSEC resolver.

    Security Fix(es):

    * unbound: Unbound DNS Cache Poisoning via Promiscuous Additional Section RRSet Acceptance     (CVE-2026-42960)

    * unbound: Unbound DNSSEC Validator NSEC3 Hash Calculation Limit Bypass via Negative Cache Code Path     Leading to DoS (CVE-2026-42923)

    * unbound: Unbound: Denial of Service due to locking inconsistency during RPZ XFR reload (CVE-2026-44608)

    Bug Fix(es) and Enhancement(s):

    * Update to latest 1.26 [rhel-9] (JIRA:RHEL-246537)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

    Additional Changes:

    For detailed information on changes in this release, see the Red Hat Enterprise Linux 9 Release Notes     linked from the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
335078	openSUSE 16: libunbound8 / python3-unbound / unbound / unbound-anchor / etc (openSUSE-SU-2026:21550-1)	Nessus	SuSE Local Security Checks	2026/8/13	2026/9/1	high
333040	Photon OS 5.0: Unbound PHSA-2026-5.0-92-0943	Nessus	PhotonOS Local Security Checks	2026/8/6	2026/11/2	high
329663	Linux Distros Unpatched Vulnerability : CVE-2026-50251	Nessus	Misc.	2026/7/25	2026/11/13	medium
352033	AlmaLinux 9.2 [TuxCare] Security Update: python3-unbound / unbound / unbound-devel / unbound-libs Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1786637650)	Nessus	Alma Linux Local Security Checks	2026/9/30	2026/9/30	medium
364088	EulerOS 2.0 SP15 : unbound (EulerOS-SA-2026-3955)	Nessus	Huawei Local Security Checks	2026/10/8	2026/10/9	high
332050	Amazon Linux 2 : unbound, --advisory ALAS2-2026-3849 (ALAS-2026-3849)	Nessus	Amazon Linux Local Security Checks	2026/8/4	2026/8/4	high
364771	EulerOS 2.0 SP13 : unbound (EulerOS-SA-2026-4202)	Nessus	Huawei Local Security Checks	2026/10/12	2026/10/13	high
331344	Fedora 43 : unbound (2026-3170ee6a1c)	Nessus	Fedora Local Security Checks	2026/7/31	2026/10/7	high
377223	EulerOS Virtualization 2.15.0 : unbound (EulerOS-SA-2026-4857)	Nessus	Huawei Local Security Checks	2026/11/7	2026/11/9	high
378202	RHEL 9 : unbound (RHSA-2026:97497)	Nessus	Red Hat Local Security Checks	2026/11/10	2026/11/12	high

检测

插件搜索

high

high

medium

medium

high

high

high

high

high

high