GHSA-5pq3-h73f-66hr

What it actually does

The advisory describes an IAM trust-boundary weakness in AWS CDK-generated CodePipeline resources where trusted entities for pipeline-related roles are broader than intended. If deployed, the resulting IAM role trust policy may allow an AWS principal outside the intended service, account, pipeline, or deployment context to call STS AssumeRole and obtain the permissions attached to that role. The impact depends on the role permissions, but commonly includes access to pipeline artifacts, build/deploy actions, CloudFormation deployment privileges, KMS/S3 access used by the pipeline, and the ability to influence software delivery workflows. The provided affected-product metadata lists python/cpython (GIT) with fixed commit 29f348e232e82938ba2165843c448c2b291504c5, which appears inconsistent with the AWS CDK CodePipeline advisory title; validate the authoritative package mapping before closing remediation.

Why it matters to the business

This issue can weaken separation between trusted and untrusted cloud identities and may allow unauthorized access to CI/CD deployment roles. In practical terms, an attacker who can assume an overly trusted pipeline role could tamper with releases, access build artifacts, push unauthorized infrastructure changes, or disrupt deployment operations. The CVSS score is low and no public exploitation or CISA KEV listing is indicated, so this is not currently a mass-exploitation emergency; however, CI/CD roles often hold high-value deployment privileges, so exposed production pipeline roles should be treated as higher operational risk than the base score suggests.

How an attack unfolds

An attacker first identifies an AWS account, role ARN, or deployed pipeline role created from vulnerable infrastructure-as-code. They inspect or infer the role trust policy and determine that the Principal or trust conditions are too permissive, such as trusting a broader account, service principal, or wildcard-like entity rather than the exact CodePipeline context intended. Using an AWS principal that falls within the overly broad trust relationship, the attacker calls sts:AssumeRole against the affected role. If the assume-role request succeeds, the attacker receives temporary AWS credentials scoped to that role. They then enumerate the granted permissions and pivot through CodePipeline, CodeBuild, S3 artifact buckets, KMS keys, CloudFormation, or deployment targets as allowed. Depending on permissions, they may read or replace artifacts, start or modify pipeline executions, alter deployment configuration, or use the CI/CD system as a path to unauthorized application or infrastructure changes.

How to fix it

Upgrade or patch the component that generates the affected IAM trust policies, then redeploy the impacted AWS CDK stacks so that IAM roles are updated in AWS, not merely in source code. Review generated IAM trust policies for CodePipeline-related roles and restrict principals and conditions to the minimum required services, accounts, roles, external IDs, source ARNs, and source accounts. Where possible, add aws:SourceArn and aws:SourceAccount conditions for service-role assumptions, remove wildcard or account-wide trust unless explicitly required, and separate deployment roles by environment. Revoke any unnecessary cross-account trust and rotate credentials or secrets that may have been accessible through the affected roles. The supplied fixed-version data states python/cpython (GIT) is fixed at commit 29f348e232e82938ba2165843c448c2b291504c5, but this does not align with the AWS CDK CodePipeline description; verify the authoritative advisory and package ecosystem before relying on that commit as remediation.

How to confirm the fix worked

Confirm remediation by inspecting the deployed IAM role trust policies, not only the IaC source. For each CodePipeline, CodeBuild, CloudFormation, and deployment role created by the affected templates, verify that the trust policy allows only the intended service principal or exact AWS principals and includes appropriate conditions such as aws:SourceArn and aws:SourceAccount where applicable. Attempt controlled AssumeRole tests from principals that should not be trusted and confirm they fail. Re-synthesize and redeploy the CDK stacks using the patched generator, then compare the resulting CloudFormation templates and IAM policies against the previous versions. Use IAM Access Analyzer to identify roles with broad or external trust and confirm there are no unintended findings for pipeline roles.

Typical attack path

1. Discover an AWS CDK-created CodePipeline role or related deployment role ARN.
2. Review, infer, or test the role trust policy for overly broad trusted entities.
3. Authenticate as an AWS principal that is unintentionally included in the broad trust relationship.
4. Call AWS STS AssumeRole against the affected pipeline or deployment role.
5. Use the temporary role credentials to enumerate CodePipeline, S3 artifact buckets, KMS keys, CodeBuild projects, CloudFormation stacks, and deployment permissions.
6. Access artifacts, trigger pipeline activity, alter deployment inputs, or attempt to push unauthorized application or infrastructure changes within the role's permission scope.
7. Cover tracks by relying on short-lived STS credentials and normal-looking CI/CD API activity.

How to detect it

To determine whether exploitation already occurred, review AWS CloudTrail management events for sts:AssumeRole targeting CodePipeline, CodeBuild, CloudFormation, and deployment roles generated by the vulnerable templates. Focus on AssumeRole events where the source principal account, role, user agent, source IP address, session name, or geography differs from expected CI/CD automation. Correlate successful AssumeRole events with subsequent API calls made by the assumed-role session, including codepipeline:StartPipelineExecution, codepipeline:UpdatePipeline, codepipeline:PutApprovalResult, s3:GetObject or s3:PutObject against artifact buckets, kms:Decrypt, codebuild:StartBuild, cloudformation:UpdateStack, iam:PassRole, lambda:UpdateFunctionCode, ecs:UpdateService, and eks or deployment-related changes. Review IAM Access Analyzer findings for external or broad trust on pipeline roles. Examine CloudFormation stack drift and recent changes to pipeline definitions, artifact buckets, buildspecs, deployment templates, and KMS key policies. Because this is a trust-policy weakness, there may be no exploit payload or malware artifact; the strongest evidence is an unexpected successful STS role assumption followed by deployment or artifact activity.

• eventSource=sts.amazonaws.com eventName=AssumeRole
• eventName=AssumeRole errorCode=AccessDenied
• eventSource=codepipeline.amazonaws.com eventName=StartPipelineExecution
• eventSource=codepipeline.amazonaws.com eventName=UpdatePipeline
• eventSource=codepipeline.amazonaws.com eventName=PutApprovalResult
• eventSource=codebuild.amazonaws.com eventName=StartBuild
• eventSource=cloudformation.amazonaws.com eventName=UpdateStack
• eventSource=iam.amazonaws.com eventName=PassRole
• eventSource=kms.amazonaws.com eventName=Decrypt
• eventSource=s3.amazonaws.com eventName=PutObject
• eventSource=s3.amazonaws.com eventName=GetObject
• assumed-role/
• codepipeline.amazonaws.com
• codebuild.amazonaws.com
• cloudformation.amazonaws.com
• "Principal":{"AWS":"*"}
• "AWS":"arn:aws:iam::*:root"
• "Action":"sts:AssumeRole"
• "Condition":{}
• AWSReservedSSO
• Access Analyzer findingType=ExternalAccess

What your security team should do

• Prioritize review of production and cross-account CI/CD roles because successful abuse can lead to release tampering or infrastructure changes even when the advisory score is low.
• Inventory AWS CDK-created CodePipeline roles and related CodeBuild, CloudFormation, artifact, and deployment roles across accounts.
• Upgrade the affected IaC dependency according to the authoritative AWS CDK advisory and redeploy stacks so fixed trust policies are applied.
• Audit IAM trust policies for broad principals, wildcard trust, account-root trust, missing source conditions, or unintended cross-account access.
• Run IAM Access Analyzer and review external-access findings for all pipeline and deployment roles.
• Search CloudTrail for historical AssumeRole activity against affected roles, especially from unexpected accounts, users, roles, IP addresses, user agents, or geographies.
• If suspicious role assumption is found, review subsequent activity performed with the assumed-role session, including pipeline changes, artifact reads/writes, KMS decrypts, CloudFormation updates, and CodeBuild project changes.
• Reduce permissions on CI/CD roles to least privilege and separate roles by environment and deployment stage.
• Enable alerts for future AssumeRole events against high-privilege CI/CD roles from non-approved principals.
• Validate the apparent package mismatch in vulnerability-management data before marking the issue fixed or not applicable.