CVE-2026-44687 Affecting unbound-debuginfo package, versions <0:1.17.1-1.amzn2023.0.13


Severity

Recommended
high

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.22% (13th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-AMZN2023-UNBOUNDDEBUGINFO-18532565
  • published5 Aug 2026
  • disclosed22 Jul 2026

Introduced: 22 Jul 2026

NewCVE-2026-44687  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 unbound-debuginfo to version 0:1.17.1-1.amzn2023.0.13 or higher.
This issue was patched in ALAS2023-2026-2033.

NVD Description

Note: Versions mentioned in the description apply only to the upstream unbound-debuginfo package and not the unbound-debuginfo package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.

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