Two Missing Characters Nearly Compromised the AWS Supply Chain

Netflix. Twitch. iCloud. The servers of the CIA and NSA. 30% of all cloud infrastructure worldwide runs on Amazon Web Services. Two missing characters in a regex filter nearly compromised all of it. 😬

A ^ at the start and a $ at the end. That’s what was missing from a security filter, and that’s all it would have taken for attackers to inject malicious code into the AWS JavaScript SDK.

That SDK powers the AWS Console itself, the control panel that administrators use to manage entire cloud infrastructures. According to Wiz Research, it runs in 66% of all cloud environments worldwide. Wiz researchers told The Register this could have been bigger than SolarWinds.

When you look at the numbers, that comparison makes sense. SolarWinds Orion was installed on 18,000 systems. The AWS JavaScript SDK runs in millions of cloud environments. The AWS Console bundles recent versions of it, and Wiz showed a console request using an SDK version that was only 18 days old. Malicious code could have reached the console within three weeks of injection.

Wiz Research disclosed CodeBreach this week after finding it in August 2025. AWS fixed the core issue within 48 hours, but needed months to complete hardening and audits before the public disclosure.

The vulnerability came down to how AWS CodeBuild determined who could trigger builds on their GitHub repositories.

They used an ACTOR_ID filter with a list of approved GitHub user IDs, written as a regex pattern with pipe characters separating each ID. The problem was that the pattern wasn’t anchored. Without ^ and $ to require exact matches, the regex engine doesn’t look for IDs that match perfectly. It looks for IDs that contain the approved numbers anywhere inside them.

So if a maintainer ID was 755743, any new ID containing that sequence would also pass the filter. Like 226755743 or 175574312.

GitHub assigns user IDs one after another, and they create around 200,000 new IDs every day. The Wiz researchers calculated that for any 6-digit maintainer ID, a new 9-digit ID containing it becomes available approximately every five days. They called these moments “eclipses” because the new ID shadows the trusted one.

Here’s how the attack worked:

• → Normal GitHub account creation is protected by reCAPTCHA
• → But GitHub Apps have a manifest flow that lets you automate app creation
• → Each app gets a bot user that can open pull requests
• → Researchers prepared 200 GitHub App creations
• → Waited until the live ID count was about 100 away from target
• → Triggered all 200 simultaneously
• → Captured an ID that passed the ACTOR_ID filter

They submitted a pull request against the AWS JavaScript SDK repository that looked like a legitimate bug fix but contained a hidden payload designed to extract credentials during the build. Minutes later they had the GitHub credentials for the aws-sdk-js-v3 CodeBuild project.

The token belonged to aws-sdk-js-automation and had full admin privileges over the repository. They could push code to the main branch, approve pull requests, and steal repository secrets.

The AWS JavaScript SDK releases weekly to GitHub and NPM. An attacker with this access could inject malicious code right before a release, and it would spread to everyone who updates.

The list of organizations running on AWS is massive:

• → Netflix with over 100,000 server instances
• → Apple reportedly spending more than $30 million monthly on AWS for iCloud
• → CIA with a $600 million cloud contract signed in 2013
• → NSA with a $10 billion contract codenamed “WildandStormy”
• → Pentagon, NASA, Medicare and Medicaid Services
• → National Cancer Institute, Customs and Border Protection
• → GCHQ, MI5, MI6, Ministry of Defence in the UK
• → 17 US intelligence agencies sharing AWS infrastructure

Disney, Comcast, Johnson and Johnson, Capital One, McDonald’s, BMW, Adobe, Pfizer, Samsung, Siemens, Coinbase, Slack, Reddit, Twitch, Airbnb, Epic Games hosting Fortnite multiplayer. Hospitals storing patient data. Drug companies running drug research. Energy companies managing power grids. Financial institutions processing transactions.

The same vulnerability existed in three other AWS GitHub repositories: aws-lc, amazon-corretto-crypto-provider, and open-data-registry. One of them was connected to a personal GitHub account of an AWS employee.

This wasn’t even the first time. In July 2025, an attacker used a similar CodeBuild misconfiguration to compromise the Amazon Q VS Code extension. That attacker successfully injected malicious code into the main branch. It was included in a release that users downloaded, and the payload actually executed on end users’ machines. The only reason it failed was a typo in the malware code.

AWS responded within 48 hours of disclosure:

• → Fixed the regex filters
• → Revoked compromised tokens
• → Added hardening to prevent builds from dumping credentials
• → Audited all public build environments and CloudTrail logs
• → Found no evidence anyone else had exploited this
• → Introduced a new “Pull Request Comment Approval” build gate so untrusted code can’t trigger builds without manual approval

The pattern of CI/CD misconfigurations leading to supply chain attacks is becoming more common. Attackers target CI/CD systems because they’re complex enough to have subtle misconfigurations, they process untrusted data from external contributors, and they require powerful credentials. That combination creates ideal conditions for high-impact breaches.

This is why ethical hackers exist. Wiz found CodeBreach, reported it, AWS fixed it, and nobody got hacked. This time…

Hacking is not a hobby but a way of life. 🎯