low · CVSS v3 3.7 · EPSS 0.0011

CVE-2026-35501

Unbound DNS resolver versions 1.0.1 through 1.26.1 can incorrectly accept forged NSEC records when configured with a root trust anchor and a

Overview

Unbound DNS resolver versions 1.0.1 through 1.26.1 can incorrectly accept forged NSEC records when configured with a root trust anchor and an island‑of‑security zone, allowing a malicious actor to bypass DNSSEC validation. This flaw arises from legacy handling of DS and NSEC queries at the trust anchor apex. The vulnerability could lead to DNS spoofing or cache poisoning in misconfigured deployments.

Description

When NLnet Labs Unbound 1.0.1 up to and including version 1.26.1 is configured with both a root trust anchor and an additional 'trust-anchor:' for an island-of-security zone whose parent is provably insecure under the root chain, a malicious actor with a forged NSEC reply with the SOA bit cleared can trick Unbound to treat the configured trust island as insecure. This happens because the DNSSEC validator in Unbound accepts and caches the NSEC insecure response bypassing the RRSIG validation that the validator was supposed to do. The acceptance of the NSEC record at the trust anchor apex was allowed due to and old fix for type DS and NSEC queries from clients when trust anchor for that name existed.

Impact

The flaw compromises DNSSEC integrity by allowing forged NSEC responses to be cached, potentially enabling attackers to redirect or spoof domain name resolutions. Network operators relying on Unbound for DNSSEC validation are at risk of serving incorrect records to clients, undermining trust in the DNS infrastructure.

Remediation

Upgrade Unbound to version 1.26.2 or later where the NSEC handling bug is fixed. If upgrading is not immediately possible, remove or correct any island‑of‑security trust‑anchor configurations and ensure that only valid DS records are trusted. Verify that the validator is not accepting NSEC records with the SOA bit cleared and monitor logs for unexpected NSEC responses.

Risk context

The CVSS v3 score is 3.7 (low) and the EPSS is 0.0011, indicating a very low probability of exploitation in the wild. Nonetheless, defenders should apply the patch promptly to eliminate the possibility of DNS spoofing in misconfigured environments.

Affected products

  • Unbound 1.0.1
  • Unbound 1.26.1
  • Unbound 1.26.0
  • Unbound 1.25.0
  • Unbound 1.24.0
  • Unbound 1.23.0
  • Unbound 1.22.0
  • Unbound 1.21.0

Scores

Severity
low
CVSS v2
2.6
CVSS v3
3.7
CVSS v4
—
EPSS
0.0011

dnssec unbound trust-anchor nsec dns low-severity ephemeral

← All CVEs

Related CVEs

low

CVE-2026-98869

In the Linux kernel, the following vulnerability has been resolved: bpf: Infer zext_dst based on static register liveness analysis As reported in the thread [1], the verifier's 32-bit operations zero extension logic is broken. This logic is responsible for correct semantics of 32-bit operations on s390 architecture. According to BPF semantics, operation `w1 += 1` is supposed to zero extend the upper half of the register `r1`. On s390 the JIT relies on the verifier emitting explicit zero extension before such operations. The verifier attempts to minimize the amount of zero extensions inserted by tracking whether upper halves of the 64-bit registers are ever used. Previously such tracking worked as follows: - bpf_reg_state->subreg_def field was set by do_check_insn() for each operation defining lower but not the upper halves of the register. - Whenever an operation reading the whole register was verified, the verifier checked register's subreg_def and set bpf_insn_aux_data->zext_dst flag as true via a call to mark_insn_zext() function. - After the verification was complete, a special pass bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations with bpf_insn_aux_data->zext_dst set as true by adding explicit zero extension. Note that the logic above relies on bpf_reg_state->subreg_def, which is a property of a current verifier state. Before the commit [2] two additional steps happened: - The verifier tracked upper and lower register halves' liveness as flags REG_LIVE_READ{32,64} in bpf_reg_state->live. - The function propagate_liveness() called mark_insn_zext() in order to transfer the knowledge about which registers have their upper halves alive (and thus might require zero extension). The commit [2] removed the two steps described above, hence making possible a situation like below: - The register's upper half is set and is used on some verification path P1 and the register happens not to be marked as precise. - The checkpoint C is created while processing some instruction between register initialization and usage. - On some other verification path P2 the register's upper half is not initialized and that path ends hitting the checkpoint C. - In such a case the register's initialization on path P2 would lack zext_dst mark, making it possible for the program to inject an arbitrary value in the register's upper half. This commit replaces subreg_def based logic with computing zext_dst statically, as a part of the bpf_compute_live_registers() analysis: - The analysis now tracks usage of upper and lower halves of the registers separately. - If some instruction defines a 32-bit subregister, but not the whole register, *and* the upper half of the register is alive after that instruction, the instruction is marked as zext_dst. There is one notable drop in precision: whenever a BPF subprogram is called, all 64 bits of parameter registers are presumed to be used. The assumption is that such a drop in precision would not inflict a noticeable performance penalty. [1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] commit 107e16979905 ("bpf: disable and remove registers chain based liveness")

View analysis

low

CVE-2026-104642

The Simple Shopping Cart WordPress plugin before 5.3.3 does not verify submitted product prices against a value only the site owner can set, allowing users with the Contributor role and above to register attacker-chosen prices for existing products, which any visitor can then use to add those products to the cart at that price.

View analysis

low

CVE-2026-114236

storage/pkg/archive.ApplyLayer and ApplyUncompressedLayer may, when processing corrupt or malicious inputs, leak a file descriptor; unbounded repeated calls can exhaust the process’ file descriptor limit

View analysis

low

CVE-2026-87096

Sensitive information disclosure and manipulation due to improper authorization checks. The following products are affected: Acronis Cyber Infrastructure (ACI) before build 6.0.1-112, Acronis Cyber Infrastructure (ACI) before build 6.1.1-64, Acronis Cyber Infrastructure (ACI) before build 6.2.1-71.

View analysis