Vulnerability-Lookup

URL	Tags
https://www.nlnetlabs.nl/downloads/unbound/CVE-20…	vendor-advisory

Vendor	Product	Version	CPE status
NLnet Labs	Unbound	Affected: 1.6.0 , < 1.25.2 (semver)	guessed

FKIE_CVE-2026-46582

Vulnerability from fkie_nvd - Published: 2026-07-22 14:17 - Updated: 2026-10-24 13:10

Severity

3.7 (Low) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

Summary

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.

References

	URL	Tags
	sep@nlnetlabs.nl	https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-46582.txt	Vendor Advisory

Impacted products

	Vendor	Product	Version
	nlnetlabs	unbound	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Unbound",
          "vendor": "NLnet Labs",
          "versions": [
            {
              "lessThan": "1.25.2",
              "status": "affected",
              "version": "1.6.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "sep@nlnetlabs.nl"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:nlnetlabs:unbound:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "08138649-8C21-4AD6-ADC3-45CD66607B71",
              "versionEndExcluding": "1.25.2",
              "versionStartIncluding": "1.6.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    },
    {
      "lang": "es",
      "value": "En NLnet Labs Unbound 1.6.0 hasta la versi\u00f3n 1.25.1 inclusive, una repetici\u00f3n de un rrset comod\u00edn como otra pieza de datos, podr\u00eda considerarse brevemente seguro para DNSSEC bas\u00e1ndose \u00fanicamente en la validaci\u00f3n RRSIG y almacenado en cach\u00e9, antes de que una validaci\u00f3n posterior lo trate como falso bas\u00e1ndose en la validaci\u00f3n NSEC. Cuando el hilo de resoluci\u00f3n marca como seguro el rrset, y otro hilo que est\u00e1 en la ruta de servir expirados luego toma el contenido actualizado del rrset con el estado seguro para una respuesta, puede usarse para cambiar un registro espec\u00edfico, junto a un comod\u00edn que podr\u00eda ser cubierto por el comod\u00edn, en el comod\u00edn. Un actor malicioso puede explotar el posible efecto venenoso al tener cualquier dominio firmado con DNSSEC (irrelevante para el dominio de la v\u00edctima) y un registro CNAME envoltorio que apunta a un registro junto a un comod\u00edn (que podr\u00eda ser cubierto por el comod\u00edn). Luego, consultar a Unbound por el registro hermano del comod\u00edn sembrar\u00eda el mensaje seguro. Una consulta posterior (despu\u00e9s de la expiraci\u00f3n) para el envoltorio CNAME necesitar\u00eda resolver el registro hermano objetivo. Si la repetici\u00f3n del comod\u00edn se inyecta en la respuesta, el rrset comod\u00edn actualizar\u00e1 el registro hermano expirado con un estado seguro antes de completar la validaci\u00f3n adecuada del comod\u00edn con registros NSEC y finalmente tratando la respuesta del envoltorio CNAME como falsa. El rrset envenenado actualizado ahora es seguro y apunta al comod\u00edn. Esta vulnerabilidad es expl\u00edcita para la ruta de servir expirados y necesita la inyecci\u00f3n del rrset comod\u00edn firmado sin el rrset NSEC que lo acompa\u00f1a."
    }
  ],
  "id": "CVE-2026-46582",
  "lastModified": "2026-10-24T13:10:00.147",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 3.7,
          "baseSeverity": "LOW",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 1.4,
        "source": "sep@nlnetlabs.nl",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-46582",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-07-22T18:56:31.700965Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-07-22T14:17:19.397",
  "references": [
    {
      "source": "sep@nlnetlabs.nl",
      "tags": [
        "Vendor Advisory"
      ],
      "url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-46582.txt"
    }
  ],
  "sourceIdentifier": "sep@nlnetlabs.nl",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-358"
        }
      ],
      "source": "sep@nlnetlabs.nl",
      "type": "Secondary"
    }
  ]
}

GHSA-CJ23-2CRP-2XVV

Vulnerability from github – Published: 2026-07-22 15:31 – Updated: 2026-07-22 15:31

Details

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.

Severity

3.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-46582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-358"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T14:17:19Z",
    "severity": "LOW"
  },
  "details": "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.",
  "id": "GHSA-cj23-2crp-2xvv",
  "modified": "2026-07-22T15:31:24Z",
  "published": "2026-07-22T15:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46582"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-46582.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

MSRC_CVE-2026-46582

Vulnerability from csaf_microsoft - Published: 2026-07-23 01:04 - Updated: 2026-07-23 14:44

Summary

A wildcard replay, as another piece of data, triggers poisoning in the serve expired reply path

Scope

1 vulnerability in this advisory, including CVE-2026-46582.

CVE-2026-46582

3.7 (Low)


                
                  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

Fixed: 1 product Known affected: 1 product

https://learn.microsoft.com/en-us/azure/azure-linux/tutoria…

Open the full advisory

OESA-2026-3333 (CVE-2026-44621)

Vulnerability from osv_openeuler – Published: 2026-08-13 13:59 – Updated: 2026-08-13 13:59 – Source website

Summary

unbound security update

Details

Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. Unbound is available for most platforms such as FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows. Unbound is a totally free, open source software under the BSD license. It doesn't make custom builds or provide specific features to paying customers only.

Security Fix(es):

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.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 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.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 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 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)

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.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.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 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)

Severity

7.5 (High)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-44621	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-44690	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46582	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-50243	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-50248	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-50251	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-55708	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-55717	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-55990	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-56416	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "python3-unbound-1.13.2-25.oe2203sp4.aarch64.rpm",
          "unbound-1.13.2-25.oe2203sp4.aarch64.rpm",
          "unbound-anchor-1.13.2-25.oe2203sp4.aarch64.rpm",
          "unbound-debuginfo-1.13.2-25.oe2203sp4.aarch64.rpm",
          "unbound-debugsource-1.13.2-25.oe2203sp4.aarch64.rpm",
          "unbound-devel-1.13.2-25.oe2203sp4.aarch64.rpm",
          "unbound-help-1.13.2-25.oe2203sp4.aarch64.rpm",
          "unbound-libs-1.13.2-25.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "unbound-1.13.2-25.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "python3-unbound-1.13.2-25.oe2203sp4.x86_64.rpm",
          "unbound-1.13.2-25.oe2203sp4.x86_64.rpm",
          "unbound-anchor-1.13.2-25.oe2203sp4.x86_64.rpm",
          "unbound-debuginfo-1.13.2-25.oe2203sp4.x86_64.rpm",
          "unbound-debugsource-1.13.2-25.oe2203sp4.x86_64.rpm",
          "unbound-devel-1.13.2-25.oe2203sp4.x86_64.rpm",
          "unbound-help-1.13.2-25.oe2203sp4.x86_64.rpm",
          "unbound-libs-1.13.2-25.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "unbound",
        "purl": "pkg:rpm/openEuler/unbound\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.2-25.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. Unbound is available for most platforms such as FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows. Unbound is a totally free, open source software under the BSD license. It doesn\u0026amp;apos;t make custom builds or provide specific features to paying customers only.\r\n\r\nSecurity Fix(es):\n\nWith NLnet Labs Unbound up to and including version 1.25.1, applications using libunbound and configured with \u0026apos;unwanted-reply-threshold\u0026apos;, could eventually be abruptly terminated if the threshold is reached and libunbound needs to call \u0026apos;libworker_alloc_cleanup\u0026apos; since the function is absent from the function call allow list. When an application using libunbound sets \u0026apos;unwanted-reply-threshold\u0026apos; 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 \u0026apos;libworker_alloc_cleanup\u0026apos; 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 \u0026apos;worker_alloc_cleanup\u0026apos; is registed in the allow list and proceeds to perform the documented cache flush.(CVE-2026-44621)\n\nIn 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\u0026apos;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)\n\nIn 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)\n\nIn NLnet Labs Unbound 1.6.2 up to and including 1.25.1, when Unbound is configured with the \u0026apos;respip\u0026apos; module in front of the validator together with a \u0026apos;response-ip\u0026apos; 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\u0026apos;s configured IP. If the validator finds an expired or otherwise invalid RRSIG on an answer whose A record falls within a \u0026apos;response-ip\u0026apos;/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\u0026apos;s configured IP. A malicious actor can exploit the possible poisonous effect by spoofing a BOGUS A/AAAA answer that falls inside the operator\u0026apos;s configured subnet rewrites. Such DNSSEC protected answers are then insecurely redirected to the operator\u0026apos;s configured target.(CVE-2026-50243)\n\nIn 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\u0026apos;s A/AAAA record (no valid RRSIG required) becomes the zone\u0026apos;s XFR primary and can replaces the entire zone/the resolver\u0026apos;s entire response policy.(CVE-2026-50248)\n\nIn NLnet Labs Unbound up to and including version 1.25.1, when \u0026apos;unwanted-reply-threshold\u0026apos; 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 \u0026apos;unwanted-reply-threshold\u0026apos; 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 \u0026apos;unwanted-reply-threshold\u0026apos; 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\u0026apos;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)\n\nIn NLnet Labs Unbound 1.6.0 up to and including 1.25.1, the \u0026apos;view_local_data\u0026apos; and \u0026apos;view_local_datas\u0026apos; commands of \u0026apos;unbound-control\u0026apos; 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)\n\nIn NLnet Labs Unbound 1.10.0 up to and including 1.25.1, when \u0026apos;serve-expired: yes\u0026apos; is set together with a \u0026apos;response-ip: \u0026lt;net\u0026gt; redirect\u0026apos; /\u0026apos;response-ip-data: \u0026lt;net\u0026gt; CNAME \u0026lt;target\u0026gt;\u0026apos; rule (or the RPZ \u0026apos;rpz-cname-override\u0026apos; 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 \u0026apos;alias_rrset\u0026apos; but not \u0026apos;partial_rep\u0026apos;. 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 \u0026apos;serve-expired-client-timeout\u0026apos; is taken leading to denial of service via the server crash.(CVE-2026-55717)\n\nIn NLnet Labs Unbound 1.7.0 up to and including 1.25.1, when the \u0026apos;dnscrypt:\u0026apos; clause lists more \u0026apos;dnscrypt-provider-cert:\u0026apos; files than there are matching \u0026apos;dnscrypt-secret-key:\u0026apos; files, Unbound fills only the matched prefix and leaves the tail slots at the \u0026apos;0xdb\u0026apos; fill that libsodium\u0026apos;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 \u0026apos;0xdb\u0026apos; bytes. Any unauthenticated client that sends one UDP datagram of \u2265 68 bytes whose first 8 bytes are \u0026apos;0xdb\u0026apos; to \u0026apos;dnscrypt-port\u0026apos; 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 (\u0026apos;--enable-dnscrypt\u0026apos;).(CVE-2026-55990)\n\nIn 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 \u0026apos;datstart + dname_valid(datstart, ...)\u0026apos; and passes it straight to \u0026apos;query_dname_tolower()\u0026apos; 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 \u0026apos;query_dname_tolower()\u0026apos; to walk label-by-label through stale bytes in the per-worker \u0026apos;env-\u0026gt;scratch_buffer\u0026apos;, past the end of that heap allocation if \u0026apos;msg-buffer-size\u0026apos; 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)",
  "id": "OESA-2026-3333",
  "modified": "2026-08-13T13:59:28Z",
  "published": "2026-08-13T13:59:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3333"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44690"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46582"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50243"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50251"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55708"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55717"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55990"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56416"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "unbound security update",
  "upstream": [
    "CVE-2026-44621",
    "CVE-2026-44690",
    "CVE-2026-46582",
    "CVE-2026-50243",
    "CVE-2026-50248",
    "CVE-2026-50251",
    "CVE-2026-55708",
    "CVE-2026-55717",
    "CVE-2026-55990",
    "CVE-2026-56416"
  ]
}

OESA-2026-3334 (CVE-2026-40691)

Vulnerability from osv_openeuler – Published: 2026-08-13 13:59 – Updated: 2026-08-13 13:59 – Source website

Summary

unbound security update

Details

Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. Unbound is available for most platforms such as FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows. Unbound is a totally free, open source software under the BSD license. It doesn't make custom builds or provide specific features to paying customers only.

Security Fix(es):

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)