Prowler SAML Bug Could Let One Tenant Hijack Another's Account (CVE-2026-59151)

What happened

A GitHub Security Advisory (GHSA-h8m9-jgf8-vwvp, CVE-2026-59151, CVSS 9.6) discloses a cross-tenant account takeover vulnerability in Prowler, the open-source cloud security assessment tool, affecting its SAML single sign-on flow. According to the advisory, Prowler's SAML assertion-consumer-service (ACS) "finish" logic derived the tenant to issue a token for from the email domain asserted inside the SAML response, rather than from the SAML configuration that was actually validated for that ACS route. A tenant that configures its own SAML identity provider could, in theory, complete a valid SAML login for its own domain while asserting an email address belonging to a different, victim tenant's domain — potentially causing Prowler to issue a token scoped to the victim's tenant. The advisory notes several compounding factors that increase the risk: SAMLConfiguration.email_domain is checked for format and global uniqueness but not for domain ownership, SAML-based social account auto-connect is hardcoded on, and IdP-initiated SSO is not rejected by default — meaning no victim interaction is required if the described conditions are met. A public PoC is included in the advisory, though the authors themselves note it demonstrates the account-linking step and does not fully prove the end-to-end token-issuance chain in a live environment.

Why it matters for defenders

Prowler is widely used for cloud security posture assessment across AWS, GCP, and Azure. If this flow is exploitable as described, a low-privilege attacker who can register a tenant with its own SAML configuration could potentially reach another tenant's cloud audit findings, compliance data, and integration secrets, and could pivot further using Prowler's tenant-switch endpoint. This is relevant to any organization self-hosting or running multi-tenant Prowler instances with SAML enabled, particularly where the target email domain already maps to another tenant's SAML configuration.

What defenders should watch for

• Check whether your Prowler deployment has SAML authentication enabled, and confirm you are running a patched version once one is available from the vendor.
• Review tenant and SAML configuration history for unexpected or unfamiliar SAMLConfiguration entries claiming domains you don't control.
• Audit authentication and tenant-switch logs for anomalies: token issuance events where the asserted email domain doesn't match the expected tenant, or membership/token-switch activity by accounts that shouldn't have cross-tenant access.
• Where possible, disable IdP-initiated SSO and review whether SAML auto-connect behavior can be constrained until a fix is confirmed.
• Treat this as an identity/authentication issue rather than a data-exfiltration issue in isolation — downstream impact depends heavily on what each tenant has connected (cloud accounts, secrets, findings).

Developing intel

This is a same-day disclosure and details may evolve as the vendor and researchers clarify remediation status and affected version ranges. Treat the technical specifics above as reported by the source, not independently verified by df00tech. Full advisory: GHSA-h8m9-jgf8-vwvp.