Strona główna / Blog / NetworkManager: tylko z dhclient

Blog · analiza

NetworkManager podatny tylko przy niestandardowym backendzie dhclient: jak configuration-aware VM eliminuje false positives

CVE-2026-10805 dotyczy lokalnej eskalacji uprawnień w NetworkManagerze podczas przetwarzania spreparowanego Manufacturer Usage Description URL. Kluczowy warunek: problem występuje w dhclient backend. Administrator musi jawnie skonfigurować NetworkManager, aby używał dhclient — default configuration nie jest affected. To bardzo dobry przykład różnicy między package vulnerable a system exploitable.

CVE-2026-10805: LPE przez spreparowany MUD URL.
Warunek: backend dhclient (jawnie skonfigurowany; default nie jest affected).
CVSS: 6.7; EPSS: ~0,152%.

Dlaczego scanner będzie miał problem?

Scanner pakietowy może poprawnie wykryć podatną wersję NetworkManagera, ale nie zna runtime configuration. W dużej flocie może powstać tysiące findings mimo że tylko niewielka część hostów używa niestandardowego backendu. To klasyczny przypadek, w którym drugi etap triage powinien wykonać prostą kontrolę konfiguracyjną.

Configuration query jako enrichment

Zamiast ręcznej analizy można zebrać NetworkManager backend, dhclient presence, relevant config directive i zbudować regułę:

affected version AND dhclient backend enabled → actionable affected version AND default backend → not exploitable / suppress with evidence

Takie podejście może zmienić tysiące package findings w małą, realną populację remediation.

Suppression musi być warunkowe

Jeżeli host jest dziś bezpieczny dlatego, że używa default backendu, status powinien zależeć od tej konfiguracji. Zmiana na dhclient powinna wywołać revalidation. False positive forever jest złym modelem — lepsze: Not exploitable while backend != dhclient.

EPSS dodatkowo pokazuje kontekst

GitHub Advisory Database wskazuje CVSS 6.7 i bardzo niskie EPSS, około 0,152%. To spójne z wieloma preconditions: lokalny użytkownik, niskie uprawnienia, user interaction i niestandardowy backend. Nie oznacza to, że podatność jest nieważna na hostach spełniających te warunki — oznacza jedynie, że globalny attack surface jest ograniczony.

Co powinien zrobić Vulnerability Engineer?

  1. Wykryć podatne wersje.
  2. Zebrać konfigurację backendu.
  3. Zidentyfikować rzeczywistą affected population.
  4. Patchować ją w pierwszej kolejności.
  5. Dla pozostałych zachować machine-readable evidence.
  6. Rewalidować po zmianach konfiguracji.

Wniosek

CVE-2026-10805 jest dobrym argumentem za tym, aby Vulnerability Management wychodził poza inventory pakietów. Wersja mówi, czy kod może być podatny. Konfiguracja mówi, czy attack path istnieje. Dopiero połączenie obu daje praktyczny finding.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 1 września 2026. CVE-2026-10805 (CVSS 6.7, EPSS ~0,152%) to LPE w NetworkManagerze przez spreparowany MUD URL, występujące tylko w backendzie dhclient, który administrator musi jawnie skonfigurować; default nie jest affected. Artykuł koncentruje się na configuration-aware VM i warunkowej suppression.

Zapamiętaj jedno

Wersja mówi, czy kod może być podatny; konfiguracja mówi, czy attack path istnieje. Configuration query jako drugi etap triage zamienia tysiące package findings w małą, realną populację remediation — a suppression powinno być warunkowe, nie „false positive forever”.