Strona główna / Blog / Keycloak: CVE a konfiguracja

Blog · analiza

Keycloak CVE istnieje tylko przy jawnie niebezpiecznej konfiguracji. Czy scanner powinien raportować ją wszystkim?

CVE-2026-18569 dotyczy backchannel logout w Keycloak. Problem pojawia się, gdy administrator skonfiguruje OIDC Identity Provider tak, aby pomijał walidację podpisu. W takim ustawieniu Keycloak może zaakceptować niesygnowany logout token, a atakujący, który zna odpowiednie identyfikatory sesji, może wymusić logout konkretnego użytkownika. Red Hat ocenia problem jako Low, CVSS 3.7. Kluczowy warunek: podatność wymaga non-default insecure configuration.

CVE-2026-18569: backchannel logout; akceptacja niesygnowanego logout tokenu → forced logout.
Warunek: OIDC IdP z pominiętą walidacją podpisu (non-default insecure config).
Red Hat: Low, CVSS 3.7.

Co ma zrobić SCA?

SCA widzi wersję keycloak-services i generuje CVE. Nie zna jednak konfiguracji konkretnego IdP. Rzeczywista exploitable state wymaga:

OIDC IdP configured? skip signature validation enabled? brokered users present? required session identifiers obtainable?

Jeśli podpisy są weryfikowane, attack path nie istnieje.

Not affected czy not exploitable?

Na poziomie komponentu wersja może być affected. Na poziomie wdrożenia bardziej precyzyjne jest state: not_exploitable / reason: vulnerable_configuration_not_present. To ma znaczenie, bo konfiguracja może się zmienić.

Configuration drift może ponownie otworzyć attack path

Dziś podpisy są weryfikowane i finding zostaje zamknięty. Za miesiąc administrator wyłącza walidację podczas troubleshooting. Jeśli status był zwykłym false positive, system VM nie wie, że warunek bezpieczeństwa właśnie zniknął. Lepszy model:

state: not_exploitable condition: signature_validation: enabled revalidate_on: configuration_change

To praktyczna forma conditional VEX.

Low CVE może ujawniać ważniejszy problem konfiguracyjny

Impact samego CVE jest ograniczony do forced logout i wymaga dodatkowych warunków — niska ocena jest logiczna. Ale pojawia się ważniejsze pytanie architektoniczne: dlaczego IdP działa z wyłączoną walidacją podpisu? VE może potraktować to dwutorowo: CVE remediation + configuration hardening. Drugi finding może być ważniejszy od pierwszego.

Risk acceptance powinien być warunkowy

Jeżeli biznes wymaga pozostawienia insecure setting, wyjątek powinien określać: którego IdP dotyczy, dlaczego walidacja jest wyłączona, kto zatwierdził decyzję, jakie controls ograniczają exposure, kiedy wyjątek wygasa i czy monitorowane są nietypowe logout events. Bez tego „accepted” staje się trwałym długiem.

Wniosek

CVE-2026-18569 pokazuje, że wersja może być affected, a konkretne wdrożenie może nie mieć aktywnego attack path. Scanner powinien wykryć CVE, ale Vulnerability Engineering powinno powiązać status z konfiguracją i automatycznie rewalidować go po zmianach.

Powiązane na blogu

Źródła

Nota redakcyjna: stan informacji 1 września 2026. CVE-2026-18569 (Red Hat Low, CVSS 3.7) dotyczy backchannel logout w Keycloak i wymaga OIDC IdP skonfigurowanego tak, by pomijał walidację podpisu (non-default insecure configuration). Artykuł koncentruje się na configuration-aware VM i conditional VEX, nie na eksploatacji.

Zapamiętaj jedno

Wersja może być affected, a konkretne wdrożenie może nie mieć aktywnego attack path. Scanner powinien wykryć CVE, ale VE powiązać status z konfiguracją i automatycznie go rewalidować po zmianach — false positive forever to zły model.