CodeBreach: How AWS CodeBuild Webhook Regex Flaws Enable Supply Chain Attacks

In January 2026, Wiz Research published a disclosure they named CodeBreach: a subtle misconfiguration in AWS CodeBuild’s own webhook filter configuration that could have allowed an unauthenticated attacker to compromise AWS’s JavaScript SDK GitHub repository and potentially inject malicious code into the SDK used by millions of developers. The flaw was fixed before exploitation, but the attack chain it exposed is a template for a class of CI/CD misconfiguration that security teams routinely miss.

The Vulnerability: Two Missing Characters

AWS CodeBuild integrates with GitHub through webhook triggers. When a pull request is opened or a commit is pushed, GitHub sends a webhook event to CodeBuild, which evaluates filter rules to decide whether to trigger a build. Those filter rules use regular expressions to match actor IDs, branch names, and file paths.

In the affected AWS repositories, the actor ID allow-list regex was not anchored. An unanchored regex org/team matches any string containing org/team — including evil-org/team-real-actors or legitimate-org/team-evil. A predictably formatted actor ID containing the unanchored substring would pass the filter.

The consequence: an external contributor with a carefully chosen GitHub username or organisation name could trigger a privileged CodeBuild build. That build inherits the CodeBuild project’s GitHub integration credentials — in this case, a Personal Access Token with admin-level access to the AWS SDK repository.

From there, the attacker could:

Push code directly to the main branch (bypassing branch protection)
Approve pull requests using the compromised PAT
Modify CI/CD pipeline definitions
Exfiltrate all repository secrets stored in GitHub Actions secrets and CodeBuild environment variables

AWS fixed the issue in September 2025 following responsible disclosure in August 2025, by anchoring the regex patterns and enabling the PR Comment Approval gate.

The Broader Pattern: CodeBuild Privilege Escalation Paths

The CodeBreach disclosure brought attention to a wider class of CodeBuild privilege escalation. Thomas Preece’s March 2026 research documented privilege escalation via AWS CodeConnections — the service that manages OAuth integrations between CodeBuild and source code repositories.

The attack chain: a principal with codeconnections:PassConnection permission can associate an existing connection (already authenticated to GitHub or Bitbucket) with a new CodeBuild project they control. When that project runs, it executes in the context of the OAuth connection’s permissions — potentially gaining push access to repositories the attacker shouldn’t touch.

Additionally, undocumented CodeBuild endpoints that expose build environment metadata (including credential tokens passed as environment variables) have been documented. These endpoints are accessible from within the build environment, meaning a malicious dependency or build script step can exfiltrate credentials to an attacker-controlled location.

Attack Surface Summary

Vector	Precondition	Impact
Unanchored webhook regex	External contributor triggers build	Admin GitHub PAT theft, repo compromise
CodeConnections PassConnection	`codeconnections:PassConnection` IAM permission	OAuth token abuse across repositories
Env var credential exfiltration	Code execution within build environment	All secrets available to the build
CodePipeline cross-account role	`iam:PassRole` to CodePipeline	Lateral movement to other AWS accounts

Auditing Your CodeBuild Configuration

Review webhook filter regex patterns in all CodeBuild projects connected to external source providers:

# List all CodeBuild projects
aws codebuild list-projects --output text

# Get project details including webhook configuration
aws codebuild batch-get-projects \
  --names "project-name-1" "project-name-2" \
  --query 'projects[*].{Name:name,Webhook:webhook}' \
  --output json

# Check specific project webhook filter groups
aws codebuild batch-get-projects \
  --names "your-project-name" \
  --query 'projects[0].webhook.filterGroups' \
  --output json

For any regex filter patterns in the output, verify they are anchored with ^ at the start and $ at the end. An actor ID filter should look like ^ACTOR_ORG/ACTOR_TEAM$, not ACTOR_ORG/ACTOR_TEAM.

Review CodeConnections permissions:

# Find principals with codeconnections:PassConnection
aws iam get-account-authorization-details \
  --filter User Role \
  --query '
    [
      UserDetailList[?contains(to_string(UserPolicyList), '"'"'PassConnection'"'"')].UserName,
      RoleDetailList[?contains(to_string(RolePolicyList), '"'"'PassConnection'"'"')].RoleName
    ]
  '

# List all CodeConnections and their status
aws codeconnections list-connections --output table

Hardening Recommendations

Anchor all webhook filter regexes. Every actor ID, branch name, and file path filter in a CodeBuild webhook should use anchored patterns (^pattern$). Unanchored substring matches are the root cause of the CodeBreach class of vulnerability.

Enable the PR Comment Approval gate. AWS released this feature specifically to require human approval before external pull requests trigger builds. It prevents any unreviewed contribution from executing in your build environment.

# Enable PR Comment Approval requirement on an existing project
aws codebuild update-project \
  --name "your-project-name" \
  --build-batch-config '{"restrictions": {"computeTypesAllowed": ["BUILD_GENERAL1_SMALL"]}}' \
  --source '{"buildStatusConfig": {"context": "ci/codebuild"}}'

Use CodeBuild-hosted runners instead of GitHub Actions runners for builds triggered by external repositories. CodeBuild provides more granular control over build trigger authorization and separate IAM execution roles per project.

Generate a dedicated PAT per CodeBuild project with minimum required permissions. A PAT used for CodeBuild integration should have only the specific repository scopes it needs (repo:status for status checks, nothing more).

Scope CodeBuild project IAM roles tightly. The execution role for each CodeBuild project should have permission only to read secrets it needs for that specific build — not a shared role with access to all build secrets. Use IAM role conditions to restrict the role to the specific project:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": "arn:aws:secretsmanager:*:*:secret:codebuild/project-specific-*",
      "Condition": {
        "StringEquals": {
          "secretsmanager:ResourceTag/CodeBuildProject": "your-project-name"
        }
      }
    }
  ]
}

Monitor for credential exfiltration from build environments. Any outbound HTTP request from a CodeBuild build environment to a non-AWS, non-GitHub IP deserves scrutiny. AWS CloudTrail logs the build invocation; VPC Flow Logs capture outbound network activity from the build environment if you configure VPC for the project.