Apache Impala: Bearer token przechodzi SAML, choć jego podpis nie jest weryfikowany w ostatnim kroku — kiedy wcześniejsze poprawne etapy auth nie dowodzą integralności finalnej identity

Apache opublikował 8 września 2026 CVE-2026-56207 (Impala 4.0.0–4.5.1, fix 4.5.2). W interfejsie hs2-http, w końcowym kroku SAML2 authentication, Impala nie weryfikuje podpisu Bearer tokenu. Atakujący może zmodyfikować nazwę użytkownika i działać jako inny user. Severity: Critical.

CVE-2026-56207: brak signature verification finalnego Bearer tokenu w hs2-http SAML2 → zmiana username/claims → podszycie się pod innego usera.

Affected/fix: 4.0.0–4.5.1 / 4.5.2 (wspólny release z CVE-2026-65181 Data Source RCE).

Poprawne wcześniejsze etapy nie zamykają boundary

SAML/OAuth flows mają wiele etapów; można poprawnie wykonać część i złamać bezpieczeństwo w ostatnim kroku:

SAML flow → wcześniejsze elementy OK → powstaje Bearer token → aplikacja ufa finalnemu tokenowi → brak signature verification → identity może zostać zmieniona

Dla skanera endpoint wygląda jak „SAML enabled”; audyt widzi „SSO configured / IdP trusted / TLS enabled” — a finalna identity boundary jest otwarta. Weryfikuj nie „czy SAML działa”, lecz: czy każdy artefakt bezpieczeństwa wpływający na finalną tożsamość jest kryptograficznie i semantycznie zweryfikowany przed użyciem? Test: próba manipulacji username w Bearer tokenie po przejściu wcześniejszej części logowania.

Configuration-aware affectedness i blast radius

Jeśli Impala nie korzysta z SAML na hs2-http, package/version matching daje finding, którego vulnerable path nie jest reachable:

component_affected: true hs2_http_enabled: true/false saml_enabled: true/false exploit_path_reachable: conditional

Lokalny impact zależy od uprawnień podszywanego usera — podszycie pod administratora/konto techniczne to odczyt wrażliwych datasetów, zapytania w cudzym kontekście, pivot do Hadoop. VE wzbogaca finding o privilege graph Impala.

Weryfikacja i compromise assessment

Po upgrade do 4.5.2: runtime version, aktywny hs2-http, konfiguracja SAML, negatywny test token tampering (zmiana username/claims unieważnia authentication). Brak potwierdzonej active exploitation — nie pisz „atakowano”; przy szerokiej ekspozycji i SAML warto przejrzeć nietypowe identities, logowania z nowych źródeł i zapytania kont uprzywilejowanych (risk-based hunting).

Wniosek

CVE-2026-56207 pokazuje, że identity pipeline trzeba analizować end-to-end. Naprawa/weryfikacja jednego pola (podpis) nie wystarczy, jeśli issuer, audience, expiry, nonce i semantyka claims nie są spójnie sprawdzane — valid signature ≠ valid identity for this relying party.

Powiązane na blogu

Jenkins + Entra ID: kolizja nazw grup — identity accepted, ale nie na tym privilege
Airflow: signature ≠ identity — issuer/audience w walidacji tokenu

Źródła

Apache Impala / oss-security — CVE-2026-56207 (08.09.2026) — seclists.org
Apache Impala — impala.apache.org

Nota redakcyjna: stan informacji 9 września 2026. CVE-2026-56207 (Apache Impala 4.0.0–4.5.1, fix 4.5.2): brak weryfikacji podpisu finalnego Bearer tokenu w SAML2 (hs2-http). Artykuł koncentruje się na integralności finalnej tożsamości i configuration-aware affectedness.