UDisks CVSS 7.8 prowadzi do roota, ale tylko gdy fstab zawiera konkretne opcje: jak konfiguracja systemowa powinna wejść do findingu jako warunek exploitability

CVE-2026-7867 w UDisks (usługa zarządzania nośnikami przez D-Bus) to lokalna eskalacja do roota: handler metody Filesystem.Mount akceptował kontrolowaną przez wywołującego opcję as-user, nadpisując tożsamość bez weryfikacji autoryzacji (CWE-862 Missing Authorization, CWE-269). Nieuprzywilejowany użytkownik mógł montować systemy plików jako root bez uwierzytelnienia PolicyKit. CVSS 7.8, wektor AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Dotknięte UDisks ≥ 2.10.0, fix w 2.11.2. Ale realny attack path ma warunek konfiguracyjny.

Konfiguracja systemowa jako część powierzchni ataku

Bez odpowiedniego wpisu fstab podatny handler nie prowadzi do eskalacji — brakuje warunku, który czyni ścieżkę osiągalną. Ta konfiguracja (opcje user/users/x-udisks-auth dla nośników) jest typowa na desktopach Linux z wymiennymi mediami, a rzadka na utwardzonych serwerach. Czyli: dwa hosty z tą samą wersją UDisks mogą mieć różny realny priorytet — nie z powodu pakietu, lecz z powodu /etc/fstab.

CVSS 7.8 nie widzi fstab

CVSS opisuje skutek techniczny (lokalny → root, wysoki wpływ na CIA), ale nie mówi, czy warunek środowiskowy jest spełniony. Dla desktopu z wpisem fstab dla wymiennego dysku 7.8 jest realne i pilne. Dla serwera bez takiego wpisu — podatny kod jest, ale attack path nie. To klasyczne rozdzielenie severity od środowiskowego prawdopodobieństwa: ten sam score, różny realny priorytet.

Warunek fstab powinien być polem findingu

To pozwala odróżnić „obecna podatna wersja” od „obecny realny attack path” i automatycznie re-ocenić, gdy ktoś zmieni fstab albo politykę montowania nośników.

Nie zamykaj jako „False Positive”

Host bez pasującego wpisu fstab nie jest false positive — pakiet jest podatny. Właściwy status to warunkowa nieeksploatowalność z powodem (brak wpisu fstab z odpowiednią opcją) i triggerem. Zamknięcie jako „False Positive” spowoduje, że po dodaniu nośnika z user nikt nie wróci do findingu. Docelowo i tak należy podnieść UDisks do 2.11.2 — warunek fstab to kwestia kolejności i pilności, nie zwolnienie z patcha.

Co powinien zrobić Vulnerability Engineer?

1. Zinwentaryzuj hosty z UDisks ≥ 2.10.0.
2. Dla każdego sprawdź /etc/fstab pod kątem urządzeń widocznych przez udisks2 z opcją x-udisks-auth, user lub users.
3. Priorytetyzuj hosty z takim wpisem (typowo desktopy/stacje z wymiennymi mediami).
4. Podnieś do 2.11.2; dla hostów bez warunku oznacz niższy emergency priority z triggerem fstab_changed.
5. Rozważ przegląd polityki opcji user/users dla nośników jako trwałe zmniejszenie powierzchni ataku.

Wniosek

CVE-2026-7867 pokazuje, że konfiguracja systemowa potrafi być twardym warunkiem exploitability — a nie tylko tłem. Bez odpowiedniego wpisu fstab LPE do roota po prostu nie ma ścieżki. Dojrzały finding nosi ten warunek jako pole i re-ocenia się, gdy konfiguracja się zmienia, zamiast zamykać sprawę jako „False Positive”. Pytanie brzmi nie „czy mamy podatną wersję UDisks?”, tylko: czy /etc/fstab na tym hoście zawiera wpis, który w ogóle czyni ten exploit osiągalnym?

Powiązane na blogu

• Unbound: podatny tylko z DoQ i quic-port — build + runtime config jako warunek
• Sigma Forms: vulnerable by default — skąd pochodzi podatna konfiguracja

Źródła

• storaged-project/udisks — GHSA-j42g-v9jw-6ph3 (CVE-2026-7867) — github.com
• CVE-2026-7867 — cve.org

Nota redakcyjna: stan informacji 31 sierpnia 2026. CVE-2026-7867 (CVSS 7.8, CWE-862/269) dotyczy UDisks ≥ 2.10.0 (fix 2.11.2); Filesystem.Mount akceptował as-user bez autoryzacji, umożliwiając montowanie jako root. Exploit wymaga wpisu w fstab dla urządzenia widocznego przez udisks2 z opcją x-udisks-auth, user lub users.