CodeBreach: How a CodeBuild Regex Misconfiguration Nearly Opened AWS's GitHub Supply Chain

---

What Happened: The Technical Breakdown of the CodeBuild Webhook Bypass

At the center of CodeBreach is a detail many teams treat as "just plumbing": webhook filters that decide when CodeBuild should run a build for a GitHub event. CodeBuild supports filter groups that can restrict builds to certain branches, event types, file paths, and critically, to a trusted actor account ID (ACTOR_ACCOUNT_ID / ACTOR_ID) using a regular expression pattern. The intent is straightforward: do not run privileged builds for untrusted pull requests, because builds can access secrets, tokens, and elevated roles.

Wiz researchers found that several AWS-managed repositories used an ACTOR_ID regex that was missing two anchoring characters (^ for start and $ for end). In regex terms, that converts an exact match into a substring match, which is the difference between "only this maintainer ID is trusted" and "any ID containing this sequence is trusted." The affected repositories were configured such that a malicious actor could obtain an account ID that contains the trusted ID and thereby pass the filter check. The Hacker News summary explains the bypass in plain terms: any GitHub numeric ID that is a superstring of an approved ID could satisfy the filter.

The exploit chain was not about hacking GitHub authentication. It was about manipulating the conditions under which CodeBuild decides to execute a build. Because GitHub user IDs are numeric and assigned sequentially, Wiz argued a determined attacker could manufacture an ID that embeds a shorter trusted ID as the sequence grows over time. In their reporting, they described a cadence where the larger, newer ID space would "eclipse" a six-digit trusted ID at a predictable interval. In other words, an attacker does not need to guess passwords; they need to engineer a numeric property that tricks a regex.

Once a build triggers under trusted conditions, the risk shifts from "untrusted code ran" to "what credentials were present in the build environment." That is the supply chain crux. If a CI project uses a GitHub Personal Access Token (PAT) or similar credential for automation, and that token has admin-level privileges, then triggering the build can lead to token exposure and repository takeover. That is the scenario AWS acknowledged in its bulletin: the insufficient regex allowed a predictably acquired actor ID to gain administrative permissions for the repositories.

Why These Four Repositories Matter: When "Just Open Source" Becomes Control Plane Risk

AWS confirmed the configuration issue affected four AWS-managed open source GitHub repositories: aws-sdk-js-v3, aws-lc, amazon-corretto-crypto-provider, and awslabs/open-data-registry. On paper, that list can look like "just code." In reality, these projects sit in critical dependency paths. The AWS JavaScript SDK is not a fringe library; it appears in enterprise workloads, automation pipelines, and tooling, and Wiz framed it as a core library for the AWS Console supply chain.

Cybersecurity Dive's coverage, citing Wiz, goes further on ecosystem implications: the AWS JavaScript SDK is described as being installed in roughly two-thirds of cloud environments. Even if you treat that figure as an estimate tied to one research team's visibility, the directional risk is unambiguous. A malicious commit to a widely used SDK can propagate via routine dependency updates and CI-driven builds in thousands of organizations, often without the consuming teams ever reviewing the upstream code changes line-by-line.

The uncomfortable lesson is that "upstream" is not just your vendor. It is also your vendor's build and release machinery, your vendor's GitHub automation, and every place where untrusted events can influence trusted pipelines. AWS stated the researchers demonstrated the potential through an empty code commit to one repository and that no inappropriate code was introduced that impacted customers. That detail matters, because it indicates responsible disclosure and controlled proof, not exploitation. Yet the same mechanism would look identical to a defender until after the fact, once malicious code lands and downstream consumers update.

This is also why discussions that focus purely on "Was it exploited?" miss the main operational takeaway. Most of the most damaging supply chain compromises are detected after propagation because defenders are watching their own perimeter. CodeBreach is valuable precisely because it reveals a realistic takeover route that many organizations unintentionally leave open when they over-trust CI triggers and over-scope automation tokens.

Misconfiguration as a Class of Supply Chain Vulnerability in CI/CD Pipelines

AWS was explicit that this was not a CodeBuild service flaw, but a project-specific misconfiguration. Wiz also published an update to correct early reporting that mislabeled it as a service vulnerability, while still warning CodeBuild customers that they can reproduce the same misconfiguration in their own projects. That nuance is not PR spin; it is a blueprint for a broader threat model.

Modern CI/CD pipelines frequently combine three risky ingredients. First, builds can be triggered by events sourced from outside the organization, especially for public repositories and open-source projects. Second, build environments often contain credentials to publish artifacts, tag releases, access private dependencies, or perform infrastructure actions. Third, the policies controlling when builds run are often expressed in brittle patterns, including regex filters that are easy to implement incorrectly.

AWS documentation reinforces how powerful webhook filters are, and how much they depend on correct regex patterns. CodeBuild's webhook configuration allows filter groups where every filter must evaluate to true for an event to trigger a build, and patterns are regular expressions. The feature is flexible, but flexibility increases the blast radius of "small mistakes." One missing anchor in a regex can invert a security boundary.

The downstream impact is not limited to open-source repositories. Private enterprises can experience the same failure mode when they accept external pull requests, use forks, allow contributions from contractors, or automate builds that run with privileged roles. Attackers target these workflows because they offer a shortcut. If you can make the pipeline run your code with the pipeline's privileges, you can often pivot into secrets, signing keys, internal packages, or cloud credentials.

This is why DevSecOps hardening is increasingly about policy guardrails, not just vulnerability scanning. Code scanning tools do not flag a missing ^ in your webhook regex by default. Yet that single character can become the difference between "untrusted PR is inert" and "untrusted PR can force a privileged build."

How Organizations Can Respond: Hardening CodeBuild and GitHub Integration Without Breaking Velocity

AWS's bulletin states the core issue was mitigated within 48 hours of initial disclosure, and that AWS implemented additional mitigations including credential rotations and protections for build processes that contain GitHub tokens or other credentials in memory. Those steps are what you would expect from a mature incident response. The more useful question for most organizations is what to do inside their own environments, because your repos and build projects will not inherit AWS's remediations automatically.

The most direct control is to prevent untrusted pull requests from triggering privileged builds. AWS provides pull request build policies and a comment-based approval gate designed specifically for this. When enabled, CodeBuild can require approval before running builds for contributors who are not trusted, reducing the chance that a random external account can cause a privileged build to execute. Wiz highlighted this feature as a practical mitigation and noted AWS implemented broader hardening measures to reduce similar issues.

Second, treat webhook filter regex as production security controls. If you use ACTOR_ACCOUNT_ID filters, ensure your regex patterns are anchored so they match exactly what you intend. AWS's own documentation makes clear that webhook filtering is regex-based and that these patterns control whether builds run. In practice, this means you should also implement testing and peer review for CI policy changes, similar to how you review infrastructure-as-code.

Third, tighten credential posture in CI. If a build does not need admin-level GitHub permissions, it should not have them. If an automation token is required, consider unique tokens per project with minimal scopes, and rotate them on a schedule. Wiz's research emphasized that once privileged credentials are exposed, repository takeover becomes a straightforward operational step for the attacker. This is also where secrets management matters, because the goal is to reduce the chance that a triggered build can dump or exfiltrate sensitive values.

Finally, segment build permissions. CI roles should not have access to everything by default, and builds that run for untrusted events should run in low-privilege contexts that cannot publish releases or write to protected branches. Even if an attacker can trigger the build, the damage is contained.

Lessons Learned and Industry Implications: The Shadow Cost of "Convenient" CI Defaults

CodeBreach lands in a broader trend line: attackers are increasingly hunting the seams where automation meets trust assumptions. Wiz referenced parallels to supply-chain incidents driven by CI/CD weaknesses, and Cybersecurity Dive notes researchers investigated this issue in the wake of an attempted supply chain attack on the Amazon Q Developer VS Code extension, which AWS addressed in a July 2025 advisory. AWS's bulletin for that incident assigns CVE-2025-8217 and underscores how quickly open-source and developer tooling can become a distribution vector.

The uncomfortable point is that CI/CD security is often treated as "engineering hygiene" instead of "security architecture." Regex filters, webhook policies, token scopes, and build triggers are usually owned by dev teams, not security teams. Yet they function as enforcement points, and failures can have organization-wide consequences. In many enterprises, the first time security reviews CI design is after a breach.

There is also a governance implication. If your organization must comply with frameworks that emphasize supply chain controls, such as requirements for controlled build environments and restricted change paths, then incidents like CodeBreach should trigger internal audits. Even if AWS customers were not directly impacted here, the scenario demonstrates how supplier build pipelines can become part of your risk register.

For defenders, the most valuable outcome is turning this into a concrete checklist: inventory which repos accept untrusted contributions, identify which builds run with privileged tokens, and map the trigger logic that decides whether those builds execute. In most environments, you will find at least one "legacy" pipeline where someone solved a reliability problem years ago by granting broad permissions, and it never got reined in.

Prevention and Detection Strategies: What to Audit This Week

If you run CodeBuild, the first audit is mechanical. Review all webhook filter groups and look for ACTOR_ACCOUNT_ID patterns that are not anchored. AWS's documentation on webhooks explains that CodeBuild filters webhooks based on the regex pattern provided, and these filters can be used to specify which users are allowed to trigger builds. Your objective is to ensure your matching logic cannot be satisfied by substring tricks.

The second audit is about build privilege boundaries. Identify which CodeBuild projects have access to GitHub tokens, signing keys, package publishing credentials, or cloud roles that can modify infrastructure. If those builds can be triggered by PRs from outside your trust boundary, you have a high-risk condition. Enforce pull request build policies and comment-based approvals for any repository that accepts external contributions or uses forks.

The third audit is monitoring. You want visibility into unusual build triggers and actor IDs. Log and alert when builds are started by new actors, when pull requests from new accounts trigger builds, or when buildspec commands access credential material unexpectedly. CodeBreach's underlying logic is a reminder that attackers may aim to trigger builds, not just push code. That means "build started by unexpected actor" is a meaningful signal.

Finally, fold this into developer training. Regex is deceptively dangerous when it controls access. Treat CI trigger logic as security policy that needs peer review, tests, and a change management process. Most supply chain compromises succeed because they exploit the fact that the "policy" was never treated like policy.

Closing Perspective

CodeBreach is not a "regex gotcha" story, it is a reminder that CI trigger logic is security policy. When builds are allowed to run based on patterns that are easy to mis-specify, and when those builds can access privileged credentials, you are effectively turning convenience into a supply chain attack surface. AWS's response suggests the immediate risk was contained quickly and responsibly, but the broader lesson is for everyone running CodeBuild or any CI service: audit trigger conditions as if they were IAM policies, because functionally, they are.