# Tampering User Attributes In AWS Cognito User Pools

Cognito app clients default to writable user attributes, letting any authenticated user rewrite custom:X_platform_user_id and hijack another user's third-party account data.

- Payout: Research
- Severity: high
- Program: Amazon
- Write-up by: Doyensec
- Disclosed: 2023-01-23
- Write-up quality: 6/10
- Original: https://blog.doyensec.com/2023/01/24/tampering-unrestricted-user-attributes-aws-cognito.html
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-doyensec-com-2023-01-24-tampering-unrestricted-user-attributes-aws-cognito-html
- Tags: area:cloud domain:cloud impact:ato impact:data-leak kind:research platform:research sev:high tech:aws tech:jwt technique:source-review vuln:access-control vuln:account-takeover vuln:business-logic

**Target:** Cognito user pool app client / UpdateUserAttributes API
**Root cause:** Cognito app integrations grant read/write on user attributes by default, so users can modify their own custom attributes via access token; the platform trusted custom:X_platform_user_id as immutable and used it as a DB lookup key.
**Steps:**
1. Obtain a Cognito access token JWT (scope aws.cognito.signin.user.admin) for your own user.
2. Enumerate attributes: `aws cognito-idp get-user --region us-east-1 --access-token eyJra..[REDACTED SESSION JWT]` reveals `custom:X_platform_user_id`.
3. Rewrite it: `aws --region us-east-1 cognito-idp update-user-attributes --user-attributes "Name=custom:X_platform_user_id,Value=[ANOTHER REDACTED ID]" --access-token eyJra..[REDACTED SESSION JWT]`.
4. Reload the platform UI; backend queries refresh_token by the spoofed ID and returns the victim's X_platform data.
**How found:** Noticed a custom:X_platform_user_id attribute in get-user output, deduced it was used as a lookup key for stored refresh tokens, then tested whether the access token could write it.
**Exploitation:** Attacker with any valid Cognito session rewrites their own custom:X_platform_user_id to a victim's ID; the platform uses that attribute as primary key to fetch the victim's stored refresh_token and displays their third-party data in the attacker's account.
**Insight:** Cognito app clients default to read/write on all attributes; any custom attribute used as an identity/lookup key in backend logic is attacker-controllable unless write_attributes is explicitly restricted.

## Proof of concept (copied exactly from the original report)

**AWS CLI update-user-attributes spoofing custom attribute**

```
$ aws --region us-east-1 cognito-idp update-user-attributes --user-attributes "Name=custom:X_platform_user_id,Value=[ANOTHER REDACTED ID]" --access-token eyJra..[REDACTED SESSION JWT]
```

**AWS CLI get-user to read attributes**

```
$ aws cognito-idp get-user --region us-east-1--access-token eyJra..[REDACTED SESSION JWT]
```