AWS disclosed a security issue affecting four of its managed GitHub repositories that could have allowed attackers to introduce malicious code. The problem wasn’t a flaw in AWS CodeBuild itself—it was a configuration mistake in how webhook filters were set up.
Security researchers at Wiz found that regular expressions used to filter trusted actor IDs in CodeBuild webhooks weren’t properly anchored. This meant someone could create a GitHub account with a predictable ID and gain administrative access to affected repositories.
The issue affected aws-sdk-js-v3, aws-lc, amazon-corretto-crypto-provider, and awslabs/open-data-registry. AWS fixed the core problem within 48 hours of disclosure and confirmed no malicious code was introduced during the research.
How the Attack Worked
CodeBuild webhook filters are designed to limit which GitHub accounts can trigger builds. Organizations typically use the ACTOR_ID filter to specify which user accounts have permission to run builds on their repositories.
The problem was in how these filters were configured. The regular expressions used to match actor IDs weren’t anchored properly, allowing them to match partial strings rather than exact values.
Here’s a simplified example. If a filter is set to match the pattern “12345” without anchors, it will match “12345” but also “123456789” or “99912345”. An attacker who understands this pattern can create a GitHub account with an ID that matches the filter—even though it’s not the intended account.
The researchers demonstrated this by creating an account that satisfied the filter requirements and using it to commit code to one of the affected repositories. They immediately notified AWS Security rather than exploiting the access.
The Fix and Response
AWS moved quickly after the disclosure. Within 48 hours, they corrected the regex patterns in all four affected repositories. But they didn’t stop there.
The response included rotating credentials, adding protections to build processes that handle GitHub tokens or other sensitive data in memory, and auditing every AWS-managed open-source GitHub repository to identify similar misconfigurations.
AWS also reviewed CloudTrail logs and build repository logs to confirm no one else had exploited this issue. The audit showed that the researchers were the only ones to discover and demonstrate the vulnerability.
No customer environments were affected. No AWS services or infrastructure were compromised. The issue was isolated to the configuration of these specific repositories.
Why This Matters
This incident highlights a common issue in CI/CD security: access controls that appear sound but fail under scrutiny. Regular expressions are powerful but easy to misconfigure, especially when dealing with security boundaries.
The ACTOR_ID filter in CodeBuild is intended as a security control. When it’s misconfigured, it becomes a false sense of security—worse than no control at all because teams assume they’re protected.
“This incident shows how CI/CD risk often comes from configuration, not product defects. An unanchored regex effectively bypassed an access control, even though the tooling behaved as designed. As automation deepens inside delivery pipelines, security controls must be expressed with exact precision,” according to Mitch Ashley, VP and practice lead, software lifecycle engineering, The Futurum Group.
“Build systems should be treated as privileged infrastructure. They connect source code, credentials, and deployment authority, so small misconfigurations can scale quickly. The takeaway is to test security boundaries in practice, not by inspection, and to design CI/CD platforms with guardrails that assume configuration mistakes will happen.
Best Practices for CodeBuild Webhooks
AWS updated its documentation to emphasize proper webhook configuration. The key lessons apply to any CI/CD system, not just CodeBuild.
First, anchor your regular expressions. Use ^ at the start and $ at the end to ensure exact matches. The pattern should match the complete string, not just contain it somewhere.
Second, use CodeBuild’s pull request build policies as an additional layer of defense. This feature requires explicit approval before running builds from pull requests, even if the actor ID matches your filter.
Third, audit your existing configurations. Review all webhook filters and access controls in your build systems. Test them with accounts that shouldn’t have access to verify they’re properly restricted.
Fourth, treat build environments as privileged systems. They often have access to credentials, source code, and deployment pipelines. A compromise here can cascade through your entire infrastructure.
The Bigger Picture
This issue underscores the value of security researchers who practice responsible disclosure. Wiz demonstrated the problem, proved it was exploitable, and immediately worked with AWS to fix it. That’s how security research should work.
The incident also demonstrates that AWS’s response process is working correctly. Fast remediation, comprehensive audit, log review to confirm no other exploitation, and public disclosure with actionable guidance.
For development teams using CodeBuild or similar CI/CD tools, the takeaway is clear: review your webhook configurations now. Check your regex patterns. Verify they’re properly anchored. Test them with unintended inputs.
Security boundaries in automated systems must be precise. Close enough isn’t good enough when those systems have administrative access to your code repositories.
