Cross-Account Access Misconfigured
Your IAM trust policy uses a wildcard principal or allows unknown AWS accounts to assume your roles, letting external accounts access your resources.
How It Works
Cross-account IAM roles let another AWS account's principals assume a role in your account. This is legitimate for multi-account architectures, but a wildcard Principal ('*') means ANY AWS account in the world can assume the role if they know its ARN. Even a specific account ID that belongs to a former vendor or contractor becomes a backdoor after the business relationship ends.
// BAD: trust policy with wildcard principal (Terraform)
resource "aws_iam_role" "data_access" {
assume_role_policy = jsonencode({
Statement = [{
Effect = "Allow"
Principal = { AWS = "*" } // ANY AWS account can assume this role
Action = "sts:AssumeRole"
}]
})
}// GOOD: restrict to specific, trusted AWS account IDs
resource "aws_iam_role" "data_access" {
assume_role_policy = jsonencode({
Statement = [{
Effect = "Allow"
Principal = { AWS = "arn:aws:iam::123456789012:root" } // specific account
Action = "sts:AssumeRole"
Condition = { StringEquals = { "sts:ExternalId" = var.external_id } }
}]
})
}Real-World Example
The 'confused deputy' problem in AWS occurs when a wildcard trust policy lets any AWS service or account assume your role. Several AWS customers found that old vendor integrations left IAM roles with broad trust policies — after the vendor relationship ended, those roles remained as persistent backdoors. AWS IAM Access Analyzer now specifically detects cross-account access risks.
How to Prevent It
- Always specify exact AWS account ARNs in Principal — never use '*'
- Add an ExternalId condition to prevent confused deputy attacks when granting cross-account access
- Audit all IAM roles with cross-account trust policies using AWS IAM Access Analyzer
- Review and revoke cross-account access when vendor or partner relationships end
- Use AWS Organizations SCPs to enforce that cross-account roles require ExternalId conditions
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
S3 Bucket Public Access
criticalYour S3 bucket is publicly readable due to a public ACL, disabled Block Public Access settings, or a wildcard bucket policy — anyone on the internet can list and download your files.
Cloud Metadata SSRF
criticalYour app fetches user-supplied URLs without blocking cloud metadata endpoints like 169.254.169.254, letting attackers steal your cloud credentials via SSRF.
AWS Credentials Hardcoded
criticalAWS access keys (starting with AKIA) or secret access keys are hardcoded in your source code, giving anyone who reads the code full access to your AWS account.
IAM Overly Permissive Policy
highYour IAM policy uses Action: '*' or Resource: '*', granting far more permissions than needed and turning any credential leak into a full account takeover.