CVE-2026-76186
KrytyczneCVSS 9.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 42 - wyżej niż 42% wszystkich znanych CVE
Streszczenie
W Apache Airflow Keycloak provider od wersji 3.3 tożsamość użytkownika jest pobierana z podpisanego tokena sesji Airflow, ale tokeny dostępu i odświeżania Keycloak używane do autoryzacji pochodzą z oddzielnych, nieuwierzytelnionych ciasteczek i nie są weryfikowane pod kątem zgodności z tożsamością. Pozwala to na sparowanie cudzych tokenów z własną sesją.
Ocena ryzyka
Atakujący może użyć cudzych tokenów Keycloak do autoryzacji, podczas gdy logi i audyt wskazują na jego własne konto, co może prowadzić do nieautoryzowanego dostępu i ukrycia działań.
Rekomendacja
Zaleca się aktualizację apache-airflow-providers-keycloak do wersji 0.10.0 lub nowszej, która wiąże tokeny z ciasteczek z tożsamością sesji.
Inne podatności w Apache Airflow Keycloak provider
Zobacz wszystkie- CVE-2026-76187Krytyczne
W Apache Airflow Keycloak provider nieuwierzytelniony endpoint tokenów akceptuje grant client-credentials dla dowolnego poufnego klienta zarejestrowanego w realmie Keycloak, nie tylko dla klienta skonfigurowanego dla Airflow. Brak listy dozwolonych klientów pozwala na użycie poświadczeń innej aplikacji jako ważnych poświadczeń logowania do Airflow.
- CVE-2026-92228Średnie
W providerze Keycloak dla Apache Airflow funkcja wielozespołowego provisioningu (`_attach_team_permissions`) przyznawała każdej roli zespołu globalny dostęp do odczytu dzienników audytu. Wdrożenia z włączonym trybem wielozespołowym i menedżerem uwierzytelniania Keycloak są narażone — każdy uwierzytelniony członek jednego zespołu mógł odczytywać zdarzenia audytu innych zespołów przez UI lub API dziennika zdarzeń.
Oryginalny opis (angielski, źródło NVD)
Apache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, and never checks that the two describe the same subject. A user who holds any valid Airflow login of their own, together with another subject's Keycloak access or refresh token obtained out of band, can pair the two: Airflow then authorizes requests with the foreign token's privileges while the session identity, audit log and cache keys continue to name the attacker's own account. The refresh path re-issues an Airflow session token for the original identity carrying the foreign tokens, so the mismatched pairing survives across sessions. Affects deployments running Airflow 3.3 or later with the Keycloak auth manager. Earlier versions carried the Keycloak tokens inside the signed session token, so the binding existed and was lost when they moved into separate cookies. Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which binds the cookie-supplied tokens to the session identity.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

