editorially independent. We may make money when you click on links
to our partners.
Learn More
A supply chain weakness in AWS build automation could have allowed attackers to hijack trusted GitHub repositories and push malicious code into widely used AWS software components.
Wiz researchers said the issue, dubbed CodeBreach, created a path from a single pull request into privileged CI/CD workflows — potentially impacting downstream applications at massive scale.
The researchers “… identified a configuration issue affecting the following AWS-managed open source GitHub repositories that could have resulted in the introduction of inappropriate code,” said AWS in its advisory.
They added, “No inappropriate code was introduced to any of the affected repositories during this security research activity and these activities had no impact to any AWS customer environments and did not impact any AWS services or infrastructure.”
Inside the CodeBreach Supply Chain Risk
Wiz reported that CodeBreach exposed a supply chain risk across four AWS repositories: aws/aws-sdk-js-v3, aws/aws-lc, corretto/amazon-corretto-crypto-provider, and awslabs/open-data-registry.
The concern wasn’t limited to a single project — it was the possibility that attackers could abuse trusted CI/CD automation to inject malicious code upstream, then let that compromise cascade downstream through routine builds and releases.
The most serious impact scenario involved the AWS JavaScript SDK, which is widely used across cloud environments and frequently pulled into applications through package managers like npm.
If attackers could tamper with that SDK, they could potentially poison updates that developers and production systems consume automatically, turning normal dependency upgrades into a silent distribution channel for malicious code.
At the technical level, Wiz traced the root cause to an access control weakness in AWS CodeBuild webhook filters tied to the ACTOR_ID parameter.
These filters are meant to ensure that only trusted GitHub identities can trigger privileged builds, particularly in workflows that run with elevated permissions or have access to sensitive secrets.
However, Wiz found that the regular expressions used in these filters were unanchored, meaning they were missing the ^ and $ anchors required for strict, exact matching.
That detail mattered because an unanchored pattern can match more than intended.
Instead of allowing builds only when the ACTOR_ID matched a specific approved user ID, the filter could also match any GitHub user ID that contained an approved substring.
The researchers showed how attackers could exploit this through what they called eclipse events — cases where a newly created, longer GitHub numeric ID eventually contains an older maintainer’s short six to seven digit ID as a substring.
Since GitHub assigns IDs sequentially and issues roughly 200,000 new IDs per day, Wiz said these overlaps happen often enough to be practical, with eclipse conditions appearing roughly every five days for the targeted IDs.
Proof-of-Concept (PoC)
In a proof-of-concept targeting aws/aws-sdk-js-v3, Wiz demonstrated how a malicious pull request could trigger a privileged build and execute hidden payload logic inside the build environment.
The payload then dumped process memory to extract a GitHub Personal Access Token (PAT) associated with the aws-sdk-js-automation account — despite prior hardening introduced after the 2025 Amazon Q incident.
Wiz stopped short of full escalation after confirming the impact and responsibly disclosed the issue on Aug. 25, 2025 to AWS.
The researchers reported that the recovered PAT carried high-impact scopes, including repo and admin:repo_hook, which could allow an attacker to invite collaborators, escalate privileges, and push directly to protected branches.
The same token also provided access to related private repositories, expanding the potential blast radius beyond a single open-source project and creating the conditions for a broader, ecosystem-level supply chain compromise.
AWS addressed the issue, rotated exposed credentials, and implemented additional safeguards to prevent recurrence.
Hardening CI/CD Pipelines
Supply chain incidents like CodeBreach show how small CI/CD trust gaps can quickly become high-impact compromise paths.
When build systems run with elevated permissions, even a single bypass can expose automation credentials and enable unauthorized code changes upstream.
The goal is to reduce implicit trust in build triggers, limit what untrusted workflows can access, and improve visibility into abnormal pipeline behavior.
- Anchor webhook filters regex patterns (using ^ and $) to enforce exact identity matches and prevent actor ID bypasses.
- Use short-lived, fine-grained credentials (OIDC where possible) and avoid broad, long-lived PAT scopes in CI/CD workflows.
- Require explicit approval gates for pull requests and ensure untrusted PR builds run without access to secrets or privileged variables.
- Separate trusted release pipelines from untrusted contribution workflows and run builds on isolated, ephemeral runners to limit blast radius.
- Monitor build logs and runner telemetry for unusual execution, memory scraping, token misuse, and unauthorized repo changes (e.g., hooks, invites, pushes).
- Strengthen supply chain integrity with protected branches, required reviews, signed commits, and artifact provenance/signing to reduce downstream risk.
- Test and rehearse CI/CD incident response playbooks (e.g., token revocation, runner isolation, key rotation, and rebuild procedures) to ensure rapid containment if automation credentials are compromised.
These controls help prevent CI/CD abuse, protect automation credentials, and limit the blast radius of supply chain attacks.
When Build Automation Becomes an Attack Path
CodeBreach is a reminder that supply chain security often hinges on small trust assumptions inside CI/CD pipelines, where automation, identity controls, and secrets converge.
Even when no customer impact is confirmed, the scenario highlights how quickly a misconfigured build gate can turn routine pull request activity into credential exposure and upstream compromise risk.
Organizations should use this as a prompt to validate webhook filtering logic, reduce token privileges, isolate untrusted builds, and strengthen release integrity controls end-to-end.
That same principle of minimizing implicit trust and enforcing strict verification is why organizations are adopting zero-trust solutions.
