A critical misconfiguration within Amazon Web Services (AWS) CodeBuild, dubbed “CodeBreach” by cloud security firm Wiz, could have potentially led to a complete takeover of AWS’s own GitHub repositories, including its vital AWS JavaScript SDK. This vulnerability, disclosed responsibly on August 25, 2025, and fixed by AWS in September 2025, threatened to compromise every AWS environment by allowing attackers to inject malicious code. Researchers Yuval Avrahami and Nir Ohfeld from Wiz highlighted in a report that such an exploit could have led to a platform-wide compromise, impacting countless applications dependent on the SDK and potentially the AWS Console itself, thereby jeopardizing every AWS account.
The security lapse stemmed from a weakness in AWS’s continuous integration (CI) pipelines, specifically with webhook filters designed to trigger builds only from authorized events. These filters are intended to prevent unauthorized access, such as by ensuring that code changes originate from a specific branch or that a GitHub user ID (ACTOR_ID) matches a predefined pattern. However, the identified misconfiguration bypassed these crucial security measures, creating a pathway for supply chain attacks.
Understanding the CodeBreach Vulnerability in AWS CodeBuild
The flaw exploited a fundamental oversight in how AWS CodeBuild handled webhook filters, particularly concerning regular expression (regex) patterns used to validate GitHub user IDs. AWS CodeBuild can be configured to initiate builds based on specific events, such as code commits to a designated branch or when the ACTOR_ID aligns with a particular regex pattern. These filters are a key defense mechanism against exploitation through untrusted pull requests.
Wiz identified that four key AWS-managed open-source GitHub repositories were impacted by this misconfiguration. These repositories, which were set up to automatically run builds on pull requests, included: aws-sdk-js-v3, aws-lc, amazon-corretto-crypto-provider, and awslabs/open-data-registry. The common thread among these projects was the implementation of an ACTOR_ID filter that contained a critical oversight.
The Fatal Flaw in Regex Filtering
The vulnerability in the ACTOR_ID filters of these affected repositories lay in the omission of essential regex anchors. Specifically, the start (^) and end ($) anchors were not included in the patterns. Without these anchors, the regex match was not exact. Instead of requiring a precise match against an approved ID, the pattern allowed any GitHub user ID that was a “superstring” of a legitimate ID to bypass the filter and trigger a build. For instance, an approved ID like “755743” could be bypassed by a user ID such as “226755743”.
This oversight proved significant because GitHub assigns numeric user IDs sequentially. Wiz demonstrated that by leveraging GitHub Apps to automate bot user registrations, attackers could predictably generate new user IDs that would eventually “eclipse” a trusted maintainer’s existing six-digit ID. This prediction, occurring approximately every five days according to Wiz’s analysis, enabled attackers to craft a spoofed ACTOR_ID.
Exploiting the Vulnerability for Repository Control
Armed with a valid, albeit spoofed, ACTOR_ID, an attacker could then trigger a CodeBuild build. This process would grant them access to the GitHub credentials associated with the aws-sdk-js-v3 CodeBuild project. Crucially, this included a Personal Access Token (PAT) belonging to the “aws-sdk-js-automation” user, a token that possessed full administrative privileges over the repository.
With these elevated privileges, an attacker could directly push code to the main branch, approve malicious pull requests, and exfiltrate sensitive repository secrets. This scenario effectively lays the groundwork for a sophisticated supply chain attack, where compromised code could be distributed to countless downstream users of the AWS SDK and other affected projects.
AWS acknowledged the issue, stating in an advisory that the regular expressions used in the webhook actor ID filters for these specific repositories were insufficient. The company clarified that this was a project-specific misconfiguration and not an issue with the AWS CodeBuild service itself. AWS confirmed that all identified issues have been remediated, and additional security measures, such as credential rotation and enhanced in-memory credential protection for GitHub tokens, have been implemented.
No evidence of the CodeBreach vulnerability being exploited in the wild has been found. However, the incident serves as a stark reminder of the persistent security challenges within CI/CD environments. Researchers from Wiz commented that this vulnerability exemplifies why adversaries target CI/CD systems: a seemingly minor oversight with the potential for significant impact, requiring no prior access to exploit.
This incident is not an isolated case highlighting vulnerabilities in CI/CD pipelines. Similar security concerns have been raised previously. Research from Sysdig last year detailed how insecure GitHub Actions workflows, particularly those using the `pull_request_target` trigger, could be exploited to leak the privileged `GITHUB_TOKEN`. This could grant unauthorized access to numerous open-source projects through a single pull request from a forked repository.
Orca Security also published findings detailing insecure `pull_request_target` configurations in projects from major technology companies, which could have led to arbitrary code execution, sensitive data exfiltration, and the injection of malicious code or dependencies into trusted branches. This phenomenon was termed “pull_request_nightmare.” Security researcher Roi Nisimi noted that abusing misconfigured workflows triggered via `pull_request_target` allows adversaries to escalate from an untrusted pull request to remote code execution on GitHub-hosted or even self-hosted runners, emphasizing that untrusted code should never be checked out without proper validation.
Looking ahead, cloud security remains a dynamic landscape. While AWS has patched the CodeBreach vulnerability and implemented enhanced security protocols, the potential for similar misconfigurations in complex CI/CD systems persists. Organizations leveraging cloud services and automated build processes are urged to review their webhook filters, regex patterns, and credential management practices to prevent future supply chain attacks. The ongoing focus on CI/CD security underscores the critical need for continuous vigilance and proactive security measures to safeguard software development pipelines.