On September 30, 2025, AWS published Security Bulletin AWS-2025-004 disclosing CVE-2025-1969, an improper input validation vulnerability in Temporary Elevated Access Management (TEAM) for AWS IAM Identity Center. TEAM is the reference application AWS ships through the IAM Identity Center sample repository for time-bound, approval-based elevation into privileged permission sets — effectively AWS's answer to PAM-style just-in-time access. The flaw allowed an authenticated user to modify a valid request and spoof an approval, granting themselves elevated permissions without an approver in the loop. AWS recommends upgrading every TEAM deployment to version 1.2.2, and rebuilding any custom fork that branched from earlier releases. For organizations that rolled TEAM out as the cornerstone of their break-glass workflow, the bulletin lands as a meaningful trust regression — because the entire premise of TEAM is that approvals are tamper-evident.
What is TEAM and why does spoofed approval matter?
TEAM is a Cognito-fronted serverless application built on AppSync, DynamoDB, Step Functions, and Lambda. A requestor selects a permission set and account, an approver receives a notification, and once the approver signs off, TEAM brokers the elevation by writing a temporary assignment into IAM Identity Center via the sso-admin:CreateAccountAssignment API. Because the assignment lasts only for the requested window — typically 30 to 240 minutes — and is audit-logged to CloudTrail, regulated environments lean on TEAM as evidence of separation of duties. SOC 2 CC6.3, PCI-DSS Requirement 7, and FedRAMP AC-2(7) all require that elevated entitlements be granted through approver-mediated workflows. A vulnerability that bypasses the approver therefore collapses the assurance behind every audit artifact TEAM produced before version 1.2.2.
How did CVE-2025-1969 work?
According to the bulletin, the flaw lives in request handling between the TEAM front-end and the Step Functions state machine that orchestrates the approval flow. A requestor could intercept and modify the GraphQL mutation payload that transitioned a request from PENDING into APPROVED and embed a forged approver identity. Because input validation on the resolver did not bind the approver field to an authenticated session principal, the Step Functions execution accepted the manipulated state and called CreateAccountAssignment as though a legitimate approver had acted. The CVSS score has not been publicly assigned by AWS, but the impact maps cleanly to CWE-863 (Incorrect Authorization) with an attack vector of authenticated, low-complexity, no user interaction.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyTeamWritesUntilUpgraded",
"Effect": "Deny",
"Action": [
"sso:CreateAccountAssignment",
"sso:DeleteAccountAssignment"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalTag/team-version": "1.2.2"
}
}
}
]
}
How do you know if you were exploited?
CloudTrail is the primary forensic surface. Query the eventName = CreateAccountAssignment records for the Identity Center management account and join against the TEAM DynamoDB Requests table on request ID. For each elevation, confirm that the approver field in DynamoDB matches the userIdentity.principalId recorded on the original UpdateRequest mutation in CloudTrail. Mismatches — particularly cases where the approver and requestor are the same identity, or where the approver value is a string the user typed in — are strong indicators of exploitation. AWS published an updated CloudTrail Lake sample query alongside the bulletin that surfaces these mismatches across a 90-day window. Organizations should also pull AWS Config history for any permission set assignments created between the TEAM release notes (the issue traces back to changes shipped in v1.1.0 on January 17, 2025) and the upgrade to 1.2.2.
What does the upgrade actually change?
Version 1.2.2 binds the approver field server-side from the authenticated Cognito identity claim at the time of state transition, instead of trusting the client-supplied attribute. It also adds an HMAC over the request payload that is verified by the Step Functions integration before any IAM Identity Center API call is invoked. The release notes call out a second hardening: TEAM now rejects state transitions where the requestor and approver resolve to the same Identity Center user, closing the trivial self-approval path that the original bulletin highlighted. Customers who customized the TEAM React front end must rebase those changes onto the 1.2.2 branch — the schema for the UpdateRequestInput GraphQL type has changed and forks pinned to older minor versions will not pick up the validation logic.
How should you operate TEAM after the upgrade?
Six controls worth implementing this quarter. First, deploy TEAM from infrastructure-as-code with a pinned commit SHA — not the latest tag — and gate the pipeline on an SBOM diff that flags drift in the bundled Amplify and AppSync dependencies. Second, enforce SCPs at the AWS Organizations level that deny sso-admin:CreateAccountAssignment from any principal other than the TEAM Lambda execution role. Third, ship CloudTrail logs to a write-once S3 bucket with Object Lock in compliance mode for 365 days, so a future TEAM compromise cannot retroactively scrub elevation evidence. Fourth, wire EventBridge rules to alert on any CreateAccountAssignment whose target permission set is tagged Tier:Privileged and whose request was not preceded by a matching UpdateRequest mutation. Fifth, run a quarterly red team exercise specifically against the elevation workflow — TEAM is part of your control plane and deserves the same scrutiny as the IdP. Sixth, subscribe the TEAM GitHub repository to security advisories and treat new CVEs against it as P1 — the bulletin makes clear AWS will continue to ship fixes here, and a 60-day patch SLA is too slow when the vulnerability bypasses your separation-of-duties control.
How Safeguard Helps
Safeguard inventories deployed copies of TEAM across AWS Organizations by ingesting CloudFormation, CDK, and Terraform state, then maps the bundled application bill of materials against the AWS Security Bulletin feed so any TEAM instance below 1.2.2 surfaces as a P1 finding within minutes of AWS-2025-004 publication. Griffin AI correlates the affected TEAM Cognito user pool with CloudTrail elevation events, automatically flagging assignments where the approver attribute does not match a server-side authenticated principal — turning the manual forensic query into a continuous detection. Policy gates block CodePipeline and GitHub Actions deployments that embed TEAM versions below the bulletin baseline, and IaC scanning rejects pull requests that pin to vulnerable tags. For regulated tenants, Safeguard's compliance evidence engine maps TEAM upgrade status into SOC 2 CC6.3 and PCI-DSS 7.2 control narratives, so auditors see a real-time attestation rather than a screenshot from the day of the report.