Attack on the AWS Build Console: When CI/CD Pipeline Becomes a Weak Link

An article published on January 16, 2026, on CyberPress.org details a sophisticated attack targeting AWS build consoles via compromised GitHub accounts. For the uninitiated, this type of supply chain attack might seem complex, but understanding its mechanisms is crucial to better protect against it.

---

How did hackers exfiltrate AWS credentials?

Here is the breakdown, step by step:

Phase 0: The Technical Vulnerability — The Poorly Anchored Regex 🔍

The central problem lay in a subtle misconfiguration of AWS CodeBuild pipelines. These pipelines use webhook filters to prevent untrusted pull requests (PRs) from triggering builds. These filters rely on the ACTOR_ID parameter to authorize only a list of approved GitHub IDs.

The bug? The regular expressions (regex) used lacked start and end anchors (^ and $). This means a GitHub ID containing the ID of an approved maintainer as a substring could bypass the filter.

Concrete example:

• Approved maintainer ID: 12345
• Created attacker ID: 123456789 (contains 12345)
• The regex filter validates 123456789 because it finds 12345 inside it! ✅❌

Phase 1: Exploiting GitHub’s Sequential ID System 🎯

Researchers exploited the fact that GitHub assigns user IDs sequentially. By automating the creation of bot accounts via the GitHub Apps manifest flow, they were able to “reserve” a target ID containing a trusted AWS maintainer’s ID.

Concretely:

1. Automated creation of multiple GitHub Apps
2. Retrieval of sequential IDs until obtaining an ID containing that of an AWS maintainer
3. Result: an attacker account that “passes” the security filters

Phase 2: The Malicious Pull Request 💣

Once the target ID was obtained, the researchers submitted a malicious pull request to the aws-sdk-js-v3 repository. This PR contained code designed to execute during the build phase.

Phase 3: Triggering the Build and Exfiltration 🔑

The CodeBuild system, fooled by the flawed regex filter, automatically triggered a build from the malicious PR. The injected code then:

1. Dumped the memory of the build process
2. Stole the GitHub credentials of the aws-sdk-js-automation account
3. Exfiltrated this information to a server controlled by the researchers

These credentials offered:

• ✅ Full administrative rights on the JavaScript SDK repository
• ✅ Access to several associated private repositories
• ✅ Ability to push code directly to the main branch
• ✅ Power to approve compromised PRs
• ✅ Possibility to inject backdoors into weekly releases distributed to millions of applications

Phase 4: The Scope of the Compromise 🌐

The vulnerability affected at least three other AWS repositories, potentially exposing:

• Other automation accounts
• Personal GitHub credentials of AWS employees

Potential Impact:

• Millions of applications using the AWS JS SDK compromised
• AWS Console itself vulnerable
• Global supply chain at risk

Important Note: This attack echoes a similar incident that occurred in July 2025 with the Amazon Q extension for VS Code, where a similar CodeBuild misconfiguration allowed the injection of malicious code into production releases.

Phase 5: Remediation by AWS 🛡️

Following responsible disclosure by Wiz Research, AWS:

1. ✅ Immediately remediated all identified vulnerabilities
2. ✅ Implemented hardening measures across the CodeBuild platform
3. ✅ Introduced a new approval gate: “Pull Request Comment Approval”
   • Requires manual approval before executing builds for untrusted PRs
4. ✅ Confirmed no impact on the confidentiality or integrity of customer environments

---

🛡️ Best Practices: Fortify Your Defenses

Faced with such a scenario, one should not panic, but act! Here is a list of best practices to transform your supply chain into a fortress, inspired by OWASP recommendations and field experience:

Principle of Least Privilege (IAM)!

This is the golden rule! Every user, every role, every service (including your CI/CD build system) should have only the permissions strictly necessary to accomplish its task, and nothing more.

• Why it helps: If your build system only needs to write to a specific S3 bucket, do not give it administrator rights! If an attacker steals these credentials, their scope of action will be very limited.

Multi-Factor Authentication (MFA)!

Enable MFA wherever possible: for your GitHub accounts, your root AWS accounts, your IAM users, and any other critical service. A simple password is no longer enough.

• Why it helps: Even if an attacker manages to steal your GitHub password, they won’t be able to log in without the second factor (code on your phone, U2F key, etc.).

Secure Secrets Management!

Never, ever store credentials (API keys, database passwords, AWS keys) in plain text in your code or GitHub repositories. Use dedicated secrets managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, or environment secrets secured by your CI/CD).

• Why it helps: If your GitHub repository is compromised, it won’t contain the secrets, thus limiting the damage.
• OWASP Cheat Sheet: The Secrets Management Cheat Sheet section is a goldmine of information!

Static Application Security Testing (SAST) and Dependency Scanning

Integrate Static Application Security Testing (SAST) tools and Software Composition Analysis (SCA) for dependency scanning into your CI/CD pipeline. These tools can detect known vulnerabilities in your code, exposed secrets, or third-party libraries containing security flaws.

• Why it helps: They can potentially detect injected malicious code before it causes havoc, or at least alert on anomalies.

  And by analyzing your WebHook or build code, they can spot missing regex ‘anchors’ as in this attack. We often underestimate/forget to analyze this type of code…

Hardening the CI/CD Environment!

• Ephemeral “Runners”: Use build machines (runners) that are created on demand for each build and destroyed afterward.

• Network Isolation: Isolate your build environments in restricted networks (VPCs, Security Groups) so they can only communicate with necessary AWS services and nothing else.

• Build Image: Use minimalist build container images that are updated regularly.

• Webhook Validation with Parameters: Following what we have seen, it is critical to ensure your parameterized webhooks are correctly written. For example, ensure that your regular expressions in webhook filters have ^ (start) and $ (end). Example:
  • ❌ Bad: 12345 (accepts 123456789, 9912345, etc.)
  • ✅ Good: ^12345$ (accepts only 12345)
• Critical PR Approval: * Enable the new “Pull Request Comment Approval” feature introduced by AWS if you use CodeBuild. This security gate requires explicit manual approval (comment on the PR) before an untrusted PR build executes. This prevents automated attacks via malicious PRs.
  • If you use GitHub, implement Required reviews (https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/approving-a-pull-request-with-required-reviews).
  • If you use gitlab.com, implement Merge Request Approvals (https://docs.gitlab.com/ee/user/project/merge_requests/approvals/).
  • If you have other CI/CD systems, look for similar manual approval features before executing untrusted PR builds.

• 🔑 Minimal Privilege Personal Access Tokens (PAT): Use Fine-Grained Personal Access Tokens with the minimum permissions necessary rather than classic tokens with full access. Limit the scope to only strictly required repositories and actions.

• Why it helps: * An ephemeral runner cannot be persistently infected.
  • Strict network isolation prevents malicious code from communicating with external servers.
  • Regular SAST analysis of build and webhook codes helps detect ‘hidden’ vulnerabilities.
  • The PR approval gate introduces a critical human control before executing potentially malicious code.
  • Minimal privilege PATs limit the impact of a compromise.

Monitoring and Alerting: Have eyes everywhere and a good alarm system.

Set up rigorous monitoring of your Cloud logs, GitHub (audit logs), and your CI/CD system. Configure alerts for suspicious activities: multiple failed login attempts, unexpected IAM role changes, access to unusual resources, data exfiltration.

• Why it helps: Detecting abnormal activity quickly is crucial to minimizing damage.

Regular Audits and Code Reviews: The human eye remains irreplaceable.

Have your code, CI/CD configurations, and IAM policies reviewed by a third party. Regular security reviews can uncover flaws that automated tools might miss.

• Why it helps: Two pairs of eyes are better than one, especially in security.

Training and Awareness: The human factor, your first line of defense.

Regularly train your developers and CI/CD/ops teams on security best practices, phishing risks, and the importance of strong passwords and MFA.

• Why it helps: Most attacks start by exploiting human error. A well-trained team is a resilient team.

---

Conclusion:

The attack on AWS build consoles via GitHub is a stark reminder that security is not an option, but an absolute necessity.

It also reminds us that the software supply chain is only as strong as its weakest link, and that attackers are always on the lookout for the slightest flaw.

It also highlights the importance of analyzing and hardening the code of your CI/CD pipelines, including webhooks and build scripts.

---