Findings

CVE-2026-100169

Prowler is a cloud security platform.

Published Jul 10, 2026 · updated Oct 15, 2026

## SAML Tenant Binding Enables Cross-Tenant Account Takeover ### Summary Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token. A malicious tenant with its own SAML configuration and a self-controlled IdP could complete a valid SAML flow for its own configured domain, while asserting an email address from another configured domain. In the vulnerable flow, the ACS finish logic later derived the tenant from the asserted email domain instead of binding token issuance to the tenant associated with the validated SAML configuration. This could cause a token to be issued for the wrong tenant. The attacker does not generally need to claim the victim's email domain. If the victim tenant already has SAML configured for that domain, another tenant cannot claim it because and are globally unique. ### Details The confirmed root cause is in the SAML ACS finish and token issuance flow. The flow selected a SAML configuration through the ACS route, but later recalculated the tenant from the asserted user email domain: This is unsafe because is derived from the SAML assertion. The tenant used for membership updates and token issuance must come from the SAML configuration validated for the current ACS route, not from the asserted email domain. The attack is made possible by several compounding weaknesses: 1. **No domain ownership proof** ( ): is validated for format and global uniqueness, but not for domain ownership. Any authenticated tenant admin can claim an unclaimed domain string, but cannot claim a domain already configured by another tenant. 2. **Global SAML domain index** ( ): maps each configured domain to its tenant. If token issuance later trusts the asserted email domain, it can resolve a tenant different from the one selected by the ACS route. 3. **Hardcoded auto-connect** ( ): and are hardcoded and cannot be disabled at runtime. 4. **IdP-initiated SSO enabled** ( ): allows the atta

Timeline

Detection, updates, and resolution for this record.

  1. Oct 14, 2026 · NIST NVD

    Detected

    Improper Authentication in the social account linking path of the Prowler API in Prowler from 5.4.0 before 5.35.0 allows a remote unauthenticated attacker to obtain persistent access to the account of a user who has not yet registered, because ProwlerSocialAccountAdapter.pre_social_login() in api/src/backend/api/adapters.py links a Google or GitHub login to any existing local account that has the

  2. Oct 15, 2026 · GitHub Advisory Database

    Fix available

    prowler-cloud fixed in 5.30.3

  3. Oct 15, 2026 · GitHub Advisory Database

    Fix available

    prowler-cloud fixed in 5.30.3

  4. Oct 15, 2026 · GitHub Advisory Database

    Updated

    Prowler is a cloud security platform. Prior to 5.30.3, Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token, and the ACS finish logic in api/src/backend/api/v1/views.py recalculated the tenant from user.email instead of binding token issuance to the validated SAML configuration. An authenticated attacker wi

Affected

  • PyPI prowler-cloud0 → 5.30.3

Sources

  • CVE.orgCVE-2026-100169

    Official CVE identifier

    cve.org
  • GitHub Advisory DatabaseGHSA-h8m9-jgf8-vwvp

    GitHub Advisory Database record mirrored by OSV.

    github.com
  • NIST NVDCVE-2026-100169

    Improper Authentication in the social account linking path of the Prowler API in Prowler from 5.4.0 before 5.35.0 allows a remote unauthenticated attacker to obtain persistent access to the account of a user who has not yet registered, because ProwlerSocialAccountAdapter.pre_soci

    nvd.nist.gov
  • OSV.devGHSA-h8m9-jgf8-vwvp

    Prowler: SAML Domain Claiming Enables Cross-Tenant Account Takeover

    osv.dev
  • OSV.devPYSEC-2026-3725
    osv.dev

References

CVE-2026-100169 · ZeroDay Findings