CVE-2026-59151 to jeden z lepszych przykładów podatności, w której klasyczne pytanie „czy SAML został poprawnie zweryfikowany?” prowadzi do fałszywego poczucia bezpieczeństwa. W Prowlerze problem nie polegał na podrobieniu podpisu assertion — atakujący mógł użyć własnego, poprawnie skonfigurowanego IdP i przejść prawidłowy flow, a mimo to doprowadzić do wydania tokenu dla innego tenanta. Identity może być prawdziwe, ale security binding między identity a tenantem może być błędny (CVSS 9.6).
Gdzie pękała granica zaufania
Prowler miał wybraną konfigurację SAML związaną z tenantem — to ona powinna być źródłem prawdy przy issuance tokenu. Zamiast tego dalsza część flow ponownie wyliczała tenant z domeny e-mail w assertion, a e-mail jest atrybutem dostarczanym przez IdP. Jeśli atakujący kontroluje własny IdP, generuje poprawnie podpisane assertion z adresem domeny innego, już skonfigurowanego tenanta; kod kończący ACS lookupował tenant po tej domenie i mógł wydać token w kontekście niewłaściwej organizacji. To nie „zwykły błąd SSO” — konsekwencją jest cross-tenant account takeover, a Prowler agreguje dane cloud-security z AWS/Azure/GCP, więc tenant boundary jest granicą między organizacjami, ich findings, integracjami i sekretami.
Preconditions, MFA, model trust boundaries
Preconditions: atakujący uwierzytelniony w swojej przestrzeni, kontroluje skonfigurowany IdP, target ma domenę powiązaną z własnym SAML tenantem, flow prowadzi przez affected ACS logic. Mocny attack path, ale nie identyczny dla każdej instalacji. Typowy model SAML skupia się na „kto podpisał assertion, czy audience się zgadza, czy nie wygasło” — te kontrole mogą działać poprawnie, a problem powstaje krok później: zweryfikowane dane są używane do ponownego wyznaczenia security context. MFA nie naprawia tenant-binding buga — może podnieść wymagania logowania, ale problem dotyczy mapowania poprawnie uwierzytelnionej tożsamości do niewłaściwego tenanta.
Remediation i verification
Maintainer wskazuje 5.30.3. Verification to nie tylko version >= 5.30.3: sprawdź, czy wszystkie instancje API i workery są na poprawionym buildzie, czy token issuance używa tenant ID z validated SAML configuration, czy żadna dalsza ścieżka nie przelicza tenanta z e-maila/innych claims, czy IdP-initiated SSO jest potrzebne, czy logi z okresu podatności pokazują nietypowe powiązania domen, membership creation lub token switching. Jeśli instancja była dostępna dla wielu tenantów, upgrade połącz z oceną historycznego nadużycia — szukaj tokenów i membershipów powstałych w kontekście innego ACS configuration niż końcowy tenant.
Powiązane na blogu
- SuperTokens: cross-tenant — tenant isolation jako property
- Airflow: cross-tenant OAuth — binding tożsamości do kontekstu
Źródła
- GHSA-h8m9-jgf8-vwvp — github.com
- Release 5.30.3 — github.com
- CVE-2026-59151 — cve.org
Nota redakcyjna: stan informacji 12 września 2026. CVE-2026-59151 (Prowler <5.30.3, CVSS 9.6): flow SAML ponownie wylicza tenant z domeny e-mail zamiast z validated configuration → cross-tenant account takeover. Brak potwierdzenia active exploitation. Artykuł omawia anti-pattern re-derived authorization context.