Unbound jest w podatnym zakresie wersji, ale CVE działa tylko przy buildzie z DoQ i aktywnym quic-port: kiedy SCA musi znać jednocześnie compile-time feature i runtime configuration

CVE-2026-14586 w Unbound (rekursywny resolver DNS) to DoS: w deploymentach DNS-over-QUIC pod obciążeniem Unbound błędnie używał czasu realtime zamiast monotonic przy wywołaniu libngtcp2, co wyzwalało assert dla timestampu QUIC i kończyło pracę serwera. Podatne wersje: 1.22.0 do 1.25.1 włącznie, fix w 1.25.2. Ale scanner, który zatrzyma się na wersji, wygeneruje finding także tam, gdzie realnie nie da się go wykorzystać — bo exploitability zależy od dwóch warunków, których w numerze wersji nie ma.

Dwa niezależne warunki, oba wymagane

To rzadszy, ale ważny wzorzec: exploitability wymaga jednocześnie właściwości builda i właściwości konfiguracji runtime. Unbound zbudowany bez DoQ nie ma podatnego kodu w ogóle. Unbound zbudowany z DoQ, ale bez skonfigurowanego quic-port, ma kod, ale nie nasłuchuje QUIC — ścieżka nie jest osiągalna. Dopiero build z DoQ + aktywny quic-port daje realny attack path.

Package inventory to za mało

Typowy SCA zna nazwę i wersję. Tutaj potrzebuje dwóch dodatkowych źródeł: build features (czy pakiet skompilowano z libngtcp2 — to zależy od dystrybucji/opcji builda) oraz runtime configuration (czy w unbound.conf jest quic-port). To dane, których nie ma w feedzie CVE — trzeba je pobrać z pakietu i z konfiguracji hosta.

Nie „False Positive”, tylko warunkowa nieosiągalność

Host z Unbound 1.24 bez DoQ nie jest false positive — scanner poprawnie wykrył podatną wersję. Właściwy status to NOT_EXPLOITABLE_CURRENT_BUILD_CONFIG z jawnym powodem (brak DoQ lub brak quic-port) i triggerem re-oceny: recheck_on: rebuild_with_doq, quic_port_added. Bo jutro ktoś może włączyć QUIC — i wtedy finding wraca.

Priorytet: publiczne resolvery z DoQ na czele

Realny priorytet dostaje wąska populacja: Unbound w podatnym zakresie, zbudowany z DoQ i nasłuchujący QUIC — zwłaszcza wystawiony na ruch, gdzie „pod obciążeniem” jest realne. To zwykle publiczne/współdzielone resolvery, nie każdy lokalny cache. Reszta populacji: patch w normalnym trybie, bez emergency.

Co powinien zrobić Vulnerability Engineer?

1. Zinwentaryzuj hosty z Unbound i wersje (1.22.0–1.25.1 = w zakresie).
2. Dla każdego ustal, czy build ma DoQ (--with-libngtcp2) — z metadanych pakietu/dystrybucji.
3. Sprawdź konfigurację: czy quic-port jest ustawiony i interfejs nasłuchuje QUIC.
4. Priorytetyzuj hosty spełniające oba warunki (zwłaszcza wystawione); podnieś do 1.25.2.
5. Dla pozostałych oznacz warunkową nieosiągalność z triggerami, nie „False Positive”; docelowo i tak patchuj.

Wniosek

CVE-2026-14586 to modelowy przykład, że „podatna wersja” bywa dopiero pierwszym z kilku warunków. Tu potrzebne są trzy naraz: wersja w zakresie, build z DoQ i skonfigurowany quic-port. SCA oparte tylko na wersji zawyża priorytet dla całej populacji Unbound; dojrzały proces łączy package inventory z build features i runtime config. Pytanie brzmi nie „czy mamy podatną wersję Unbound?”, tylko: czy ten Unbound zbudowano z DoQ i czy naprawdę nasłuchuje QUIC — bo dopiero to czyni go osiągalnym?

Powiązane na blogu

• UDisks: root, ale tylko przy wpisie fstab — konfiguracja jako warunek exploitability
• libssh podatny tylko z backendem OpenSSL — compile-time variant decyduje

Źródła

• NLnet Labs — CVE-2026-14586 (Unbound) — nlnetlabs.nl
• CVE-2026-14586 — cve.org

Nota redakcyjna: stan informacji 31 sierpnia 2026. CVE-2026-14586 dotyczy Unbound 1.22.0–1.25.1 (fix 1.25.2); DoS w DNS-over-QUIC wynika z użycia realtime zamiast monotonic i wymaga builda z --with-libngtcp2 oraz skonfigurowanego quic-port. Artykuł koncentruje się na łączeniu inwentarza z build features i konfiguracją.