A critical misconfiguration in Amazon Web Services (AWS) CodeBuild could result in a complete takeover of a cloud service provider’s own GitHub repository containing the AWS JavaScript SDK, potentially putting all AWS environments at risk.
The vulnerability has been codenamed “CodeBreach” by cloud security company Wiz. This issue was fixed by AWS in September 2025 following a responsible disclosure on August 25, 2025.
“By exploiting CodeBreach, an attacker could inject malicious code and begin a platform-wide compromise, potentially impacting not only the countless applications that rely on the SDK, but also the console itself, threatening all AWS accounts,” researchers Yuval Avrahami and Nir Ohfeld said in a report shared with The Hacker News.
Wiz pointed out that this flaw is the result of a vulnerability in the continuous integration (CI) pipeline. This vulnerability could allow an unauthenticated attacker to compromise the build environment, divulge privileged credentials, such as a GitHub admin token, and use them to push malicious changes to a compromised repository, potentially creating a supply chain attack vector.
In other words, this issue weakens the webhook filter introduced by AWS to ensure that only certain events trigger CI builds. For example, you can configure AWS CodeBuild to trigger a build only when code changes are committed to a specific branch, or when your GitHub or GitHub Enterprise Server account ID (also known as ACTOR_ID or actor ID) matches a regular expression pattern. These filters work to protect against untrusted pull requests.
This misconfiguration affected the following AWS managed open source GitHub repositories that are configured to run builds with pull requests.
aws-sdk-js-v3 aws-lc amazon-corretto-crypto-provider awslabs/open-data-registry
The four projects that implemented the ACTOR_ID filter suffered from a “fatal flaw” in which they were unable to reliably include the two characters needed to generate an exact regular expression (regex) match: the starting ^ anchor and the ending $ anchor. Instead, the regular expression pattern now allows GitHub user IDs that are superstrings of authorized IDs (e.g. 755743) to bypass the filter and trigger a build.
Because GitHub assigns numeric user IDs sequentially, Wiz said a new user ID (currently nine digits long) will “whitewash” a trusted maintainer’s six-digit ID approximately every five days. Combining this insight with the use of GitHub Apps to automate app creation (which creates corresponding bot users), we were able to trigger hundreds of new bot user registrations and generate target IDs (e.g. 226755743).
An attacker with an actor ID can trigger a build and obtain GitHub credentials for an aws-sdk-js-v3 CodeBuild project, a personal access token (PAT) belonging to the aws-sdk-js-automation user with full administrative rights to the repository.
Armed with this elevated access, attackers can push code directly to the main branch, approve pull requests, compromise repository secrets, and ultimately set up supply chain attacks.
“The regular expression configured on the above repository for the AWS CodeBuild webhook filter intended to limit trusted actor IDs was insufficient, allowing the actor IDs retrieved as expected to gain administrative privileges on the affected repositories,” AWS said in an advisory released today.
“We have confirmed that these are project-specific misconfigurations in the webhook actor ID filters for these repositories and not an issue with the CodeBuild service itself.”
Amazon also said it has implemented additional mitigation measures, including credential rotation and steps to protect build processes that include GitHub tokens and other credentials in memory, as well as fixed the identified issues. The company also stressed that it had found no evidence that CodeBreach was being exploited in the wild.
To mitigate such risks, enable the new pull request comment approval build gate to prevent untrusted posts from triggering privileged CI/CD pipelines, use CodeBuild-hosted runners to manage build triggers via GitHub workflows, ensure that regular expression patterns in webhook filters are anchored, generate a unique PAT for each CodeBuild project, and PAT It’s important to limit GitHub permissions to the minimum necessary and consider using a dedicated, unprivileged GitHub account. For CodeBuild integration.
“This vulnerability is a textbook example of why attackers target CI/CD environments. It’s a subtle and easily overlooked flaw, but when exploited, it can have a huge impact,” Wiz researchers noted. “This combination of complexity, untrusted data, and privileged credentials creates a perfect storm for high-impact breaches that do not require prior access.”
This isn’t the first time CI/CD pipeline security has been in the spotlight. Last year, an investigation by Sysdig detailed how an insecure GitHub Actions workflow associated with the pull_request_target trigger could be exploited to leak privileged GITHUB_TOKENs and gain unauthorized access to dozens of open source projects using a single pull request from a fork.
A similar two-part analysis by Orca Security found that projects at Google, Microsoft, NVIDIA, and other Fortune 500 companies had insecure pull_request_targets that could allow attackers to execute arbitrary code, leak sensitive information, or push malicious code or dependencies to trusted branches. This phenomenon is called pull_request_nightmare.
“By exploiting a misconfigured workflow triggered by pull_request_target, an attacker could escalate from an untrusted forked pull request to remote code execution (RCE) on a GitHub-hosted runner or even a self-hosted runner,” said security researcher Roi Nisimi.
“GitHub Actions workflows that use pull_request_target must not check out untrusted code without proper validation; doing so risks complete compromise.”
Source link
