Missing sts:ExternalId Enables Confused Deputy Attacks

The Trap

Cross-account IAM trust policies that authorise sts:AssumeRole from a fixed vendor or partner AWS account without a Condition block requiring sts:ExternalId. This is the textbook confused deputy setup: the trust policy correctly restricts the Principal to a known account, but places no constraint on which specific customer relationship that account is allowed to exercise.

The Default State

SaaS vendors provisioning monitoring, backup or CI/CD integrations typically generate a CloudFormation or Terraform template with a trust policy such as {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:root"},"Action":"sts:AssumeRole"}. The vendor’s own internal service then stores every customer’s RoleArn in a shared database and calls AssumeRole on demand. Because ExternalId was treated as optional boilerplate rather than a mandatory tenant discriminator, it is either omitted entirely or set to a static, non-unique placeholder value shared across all customers.

The Blast Radius

When the vendor’s backend is itself compromised, misconfigured, or exposed to parameter injection, an attacker who can influence which RoleArn or SessionName is passed to AssumeRole can pivot from one customer’s granted permissions into another tenant’s AWS account. Because the trust policy only checks the calling principal, not a per-customer secret, the vendor’s compromised credentials become a universal skeleton key across the entire customer base. CloudTrail records these as legitimate AssumeRole calls from the authorised vendor account, so SIEM correlation rules built on principal identity alone will not flag the lateral movement. The blast radius is every customer sharing that vendor integration, not just the one initially breached.

The Lead Mechanic Fix

Mandate a unique, high-entropy ExternalId per customer relationship and enforce it in the trust policy condition block: "Condition":{"StringEquals":{"sts:ExternalId":"cust-8f21-unique-uuid"}}. The vendor must store this value alongside the RoleArn and pass it explicitly on every AssumeRole call; never derive it from predictable customer metadata such as account ID or company name. On the customer side, validate incoming vendor role assumptions with aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole and alert on any session where the ExternalId claim in the event does not match the provisioned value. Rotate the ExternalId on offboarding, since a stale value with an active trust relationship is a re-entry path.