Incorrect IAM privilege assignment in AWS CICD-toolchain-for-serverless-applications enables same-account resource access

Incorrect privilege assignment in the IAM policy of AWS CICD-toolchain-for-serverless-applications 1.0.7 through 1.0.10 allows remote authenticated users with push access to the application source repository to escalate privileges and access or modify resources outside the application stack in the same AWS account via application templates deployed by the toolchain pipeline. To remediate this issue, users should upgrade existing toolchain stacks to version 1.0.11 or later.

• AWS CICD-toolchain-for-serverless-applications is confirmed affected from version 1.0.7 through 1.0.10, inclusive.
• The GitHub advisory describes affected versions as < 1.0.11, while the AWS bulletin explicitly lists the impacted range as =1.0.7 and <=1.0.10. This entry retains the CNA's explicit range and does not extend the conclusion to versions below 1.0.7.
• The confirmed fixed release is 1.0.11. The status of unverified parallel branches or later versions is not independently established here.

The affected component is the CloudFormation deployment role provisioned by the toolchain. Before version 1.0.11, its permissions for IAM, AWS Secrets Manager, and AWS Systems Manager (SSM) Parameter Store were broader than the application's own resources. A user with push access to the managed application source repository could commit an application template that referenced IAM identities, Secrets Manager secrets, or SSM parameters outside the application stack; when the pipeline deployed that template, the role could act on those resources in the same AWS account. This is a remote network-reachable path that requires an authenticated user with repository push access; the record does not describe additional end-user interaction. The record does not enumerate every IAM action and resource pattern in each deployed stack, so the blast radius for a particular resource remains deployment-specific. The version 1.0.11 fix gates IAM role-policy write actions behind a permissions boundary condition and scopes Secrets Manager and SSM Parameter Store write actions to the application's own resources.

• Reachability: Remote access through the toolchain's CI/CD pipeline.
• Required privilege: The attacker must be authenticated and have push access to the application source repository.
• Complexity and interaction: The record characterizes attack complexity as low and describes no additional user interaction.
• Exploitation status: The available evidence does not establish that this vulnerability has been exploited in the wild or that a public exploit is available.

Successful exploitation can allow an attacker to use the deployment role to escalate privileges and access or modify IAM identities, Secrets Manager secrets, SSM parameters, and other resources outside the application stack in the same AWS account. The technical consequences may include loss of confidentiality, integrity, or availability for resources reachable by the role. The described scope is limited to the account that deploys the toolchain and does not include cross-account or cross-customer impact. The actual blast radius depends on the deployed policy and the resources present in the account.

Organizations using affected stacks may face unauthorized changes to IAM identities, secrets, or parameters outside the application boundary, with possible data exposure or disruption within the same AWS account. The flaw weakens separation between one serverless application stack and other account resources, increasing the governance and incident-response burden. The actual consequence depends on the permissions granted to the deployment role and the resources present in the account. The record does not identify a breach, a specific victim, or cross-account impact.

1. Upgrade existing toolchain stacks to version 1.0.11.
2. Review all forked or derivative code and apply the corresponding fixes, then redeploy the stack.
3. Verify the deployed CloudFormation role after upgrading: IAM role-policy write actions should be gated by a permissions boundary condition, while Secrets Manager and SSM Parameter Store write actions should be scoped to the application's own resources.
4. Review push access to repositories used by the pipeline and remove unnecessary access. This reduces exposure but does not replace the upgrade.
5. AWS states that no workaround is available; repository access restrictions and monitoring should not be treated as complete remediation.

1. Inventory existing toolchain stacks and identify the deployed version of CICD-toolchain-for-serverless-applications, with priority for stacks using versions 1.0.7 through 1.0.10.
2. Inspect the actual CloudFormation deployment role in each account, including its IAM policy, permissions boundary, and resource scope for IAM, Secrets Manager, and SSM Parameter Store.
3. Identify source repositories connected to the pipelines and review which users have push access to those repositories.
4. Review pipeline templates and deployment history for references to IAM identities, secrets, or parameters outside the application stack.
5. If suitable audit records are available, check for deployment-role activity against out-of-stack resources during the period when affected versions were deployed. The absence of matching log evidence does not prove that a stack was safe or unaffected.