CVE-2026-19550 świetnie pokazuje, że nazwa permission nie opisuje rzeczywistego blast radiusu. Red Hat opisuje flaw w FreeIPA/IdM: komenda trust-fetch-domains jest chroniona uprawnieniem read-only do obiektu trust zamiast administracyjnym. W efekcie zwykły uwierzytelniony użytkownik może uruchomić uprzywilejowany Active Directory trust refresh, wskazując serwer i credentials kontrolowane przez atakującego. CVSS 8.2 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N), ale affectedness i pełny impact zależą od konfiguracji.
ipa-adtrust-install + ipa trust-add); bez trustu komponent ADTRUST i obiekt nie istnieją.Configuration-aware affectedness
Bez aktywnego AD trust wymagany obiekt i komponent nie istnieją — version-only scanning daje szeroką populację, ale exploitable population jest węższa. Enrichment: FreeIPA version, AD trust configured (yes/no), trust object exists, vulnerable permission exposure, network reachability do niezaufanych systemów. Stan: software affected / environment not exploitable because AD trust absent — nie zamykaj jako „false positive”, bo utworzenie trustu za miesiąc zmieni affectedness.
Primitive vs full impersonation chain
Exploitation wymaga zwykłego, nieadministracyjnego konta IdM — nie trzeba delegowanego trust-admin privilege. Atakujący wymusza uruchomienie privileged helpera i połączenie do swojej infrastruktury; to już naruszenie granicy uprawnień (permission opisane jako odczytowe wykonuje uprzywilejowaną operację modyfikującą dane trust/ID-range). Pełny scenariusz impersonation ma dodatkowe warunki (intercept/relay Kerberos, downgrade do słabszego encrypted-timestamp pre-auth, odzyskanie interrealm secret). Nie sprowadzaj advisora do low-priv user instantly takes over AD — publiczne dane tego nie mówią. Lepszy model: primitive A (unauthorized privileged trust refresh — potwierdzony), primitive B (attacker-controlled trust/ID data modification — opisany), full impersonation chain (wymaga dodatkowych warunków).
Capability name ≠ capability effect
Jeśli access model mówi System: Read Trust Information, operator uzna to za niskie ryzyko — a permission daje możliwość uruchomienia działania o wysokim side effect. Podobny problem: cloud IAM, Kubernetes, MCP tools, CI/CD roles, backup/restore. Uprawnienie klasyfikuj według efektów: read data, trigger privileged computation, initiate network connection, mutate identity state, rotate/refresh trust, assume identity — jedno permission może należeć do kilku klas.
Mitigation trade-off i weryfikacja
Red Hat: ogranicz System: Read Trust Information, by nie było domyślnie dostępne wszystkim authenticated users — ale to może wpłynąć na SSSD subdomain support, które polega na szerokim dostępie. Mitigation nie jest darmowa, więc ticket powinien zawierać: control, expected security effect, funkcjonalny side effect, ownera decyzji, test po wdrożeniu, revalidation trigger. Weryfikacja: sprawdź ACL/ACI przed zmianą, potwierdź, że zwykły user nie może już uruchomić trust-fetch-domains, a trust-admin nadal może, przetestuj SSSD subdomain discovery, monitoruj błędy auth, zachowaj rollback. mitigated ≠ fixed. Red Hat: issue fixed upstream — wdrażaj fix, gdy będzie dla platformy; nie wymyślaj numeru pakietu per dystrybucja (numer upstream nie mapuje 1:1 na RPM). Prowadź stany: upstream fixed → vendor package pending → available → deployed → behavior verified. Compromise assessment nie automatycznie — najpierw exposure (aktywny AD trust, permission u zwykłych userów, logi użycia trust-fetch-domains, nietypowe refresh requests, nieznane AD servers, zmiany trusted-domain/ID-range).
Powiązane na blogu
- Parse Server: puste hasło, ważny token — semantyka operacji vs właściwość bezpieczeństwa
- mysql-mcp: komentarz omija read-only — capability nazwane „read-only” vs efekt
Źródła
- Red Hat — CVE-2026-19550 — access.redhat.com
Nota redakcyjna: stan informacji 11 września 2026. CVE-2026-19550 (FreeIPA/IdM, CVSS 8.2): read-only ACI bramkuje uprzywilejowany trust refresh; affectedness zależy od aktywnego AD trust, a mitigacja ma trade-off z SSSD. Brak potwierdzenia active exploitation; pełny impersonation chain wymaga dodatkowych warunków.