Security News How 2 Missing Characters Nearly Compromised AWS

[Brownie2019]

Content source

https://hackread.com/how-2-missing-chars-compromised-aws/

A massive security hole that could have given hackers total control over Amazon Web Services (AWS) was recently fixed before anyone could actually use it for harm. The discovery, made by Wiz Research, prevented what they called a “historic near miss” for the millions of businesses and people who rely on the cloud every day.

A Two-Character Mistake

Full Story:

How 2 Missing Characters Nearly Compromised AWS

Follow us on Bluesky, Twitter (X), Mastodon and Facebook at @Hackread

hackread.com

 

[Bot]

Full Story:

How 2 Missing Characters Nearly Compromised AWS

Follow us on Bluesky, Twitter (X), Mastodon and Facebook at @Hackread

hackread.com

The “two missing characters” angle refers to missing regex anchors (the start/end anchors) in AWS CodeBuild webhook filter patterns for trusted actor IDs, which made the filter match “contains” instead of “exact match.” In other words: it was a CI/CD configuration problem in certain AWS-owned GitHub repos, not a “CodeBuild service is broken for everyone” situation. ([aws.amazon.com](https://aws.amazon.com/security/security-bulletins/2026-002-AWS/))

What Wiz showed (high level)

• Some AWS-managed open-source GitHub repositories used CodeBuild webhook filters intended to only allow trusted GitHub actor IDs to trigger privileged builds.
• Because the regex wasn’t properly anchored, a newly-created GitHub actor ID that merely contained an approved maintainer’s ID could bypass the allow-list.
• That could allow an attacker-controlled PR to trigger a privileged build, then steal/abuse GitHub credentials present in the build environment, and escalate to repo takeover (supply-chain risk).

This is described in Wiz’s write-up and confirmed in AWS’s security bulletin. ([wiz.io](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild))

Impact vs. headlines
Some articles frame this as “total control of AWS.” The more precise risk is: a supply-chain compromise path via takeover of key AWS GitHub repositories (including the AWS JavaScript SDK that the AWS Console depends on), which could have enabled malicious code injection if an attacker had reached the right point in the release chain. That is a serious class of risk, but it is not the same as an attacker instantly gaining admin of AWS customer accounts directly from the bug alone. ([wiz.io](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild))

What AWS says about exploitation and customer action
AWS states:

• This was project-specific misconfiguration in webhook actor ID filters for certain repositories, not an issue in the CodeBuild service itself.
• No inappropriate code was introduced during the research activity.
• No customer action is required (per their bulletin), and they remediated within 48 hours plus additional hardening/rotations/audits. ([aws.amazon.com](https://aws.amazon.com/security/security-bulletins/2026-002-AWS/))

Practical takeaways for anyone using CodeBuild (defense-in-depth)
Even if you’re not using AWS’s repos, the pattern matters because many organizations repeat it in their own pipelines:

• Prevent untrusted PRs/forks from triggering privileged builds (use build gates such as “Pull Request Comment Approval” where applicable). ([wiz.io](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild))
• If you must use webhook filters, ensure regex patterns are properly anchored and tested (don’t rely on “contains” matching for identity controls). ([wiz.io](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild))
• Treat CI credentials as high risk: use least privilege tokens, isolate builds, and avoid exposing build configuration/logs publicly unless absolutely necessary.

Conclusion: this looks like a well-handled responsible disclosure with AWS confirmation that customers don’t need to take action, but it’s a good reminder to audit CI/CD trigger logic and secret exposure in any CodeBuild-connected GitHub workflow. ([aws.amazon.com](https://aws.amazon.com/security/security-bulletins/2026-002-AWS/))

Sources

• 
  [] Unanchored ACCOUNT_ID webhook filters for CodeBuild
  [] CodeBreach: Supply Chain Vuln & AWS CodeBuild Misconfig | Wiz Blog
  [] How 2 Missing Characters Nearly Compromised AWS

 

[Divergent]

The Exploit Path

Infiltration
Attackers could exploit the unanchored regex to inject malicious commands or code into the build environment.

Privilege Escalation
Once inside the build pipeline, the flaw allowed for the leakage of privileged credentials.

Supply Chain Compromise
With these credentials, an attacker could seize control of the software repository, injecting backdoor code into the AWS JavaScript SDK.

The Blast Radius
Since the AWS Console relies on this specific SDK to function, a compromised library would have effectively backdoored the management dashboard for all AWS users utilizing that version, eclipsing the scale of the SolarWinds breach.

Remediation & Mitigation

Status
Patched. AWS was notified by Wiz Research on August 25, 2025, and fixed the root cause within 48 hours. No user action is required for this specific vulnerability as it was a server-side infrastructure fix.

Recommendations for Developers
While AWS has secured their end, this incident highlights critical hygiene for CI/CD pipelines.

Anchor Your Regex
Ensure all security filters using Regular Expressions are explicitly anchored (e.g., using ^ for start and $ for end) to prevent bypasses.

Enforce Human Review
Wiz Research recommends implementing "Pull Request Comment Approval" gates. This ensures automated builds do not execute until a trusted human reviewer has authorized the change, preventing malicious code from automatically triggering a compromised build pipeline.

Principle of Least Privilege
Ensure build environments do not hold credentials with broader permissions than strictly necessary for the build process.