{"id":6575,"date":"2026-01-15T22:27:18","date_gmt":"2026-01-15T22:27:18","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=6575"},"modified":"2026-01-15T22:27:18","modified_gmt":"2026-01-15T22:27:18","slug":"possible-software-supply-chain-attack-through-aws-codebuild-service-blunted","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=6575","title":{"rendered":"Possible software supply chain attack through AWS CodeBuild service blunted"},"content":{"rendered":"<div>\n<div class=\"grid grid--cols-10@md grid--cols-8@lg article-column\">\n<div class=\"col-12 col-10@md col-6@lg col-start-3@lg\">\n<div class=\"article-column__content\">\n<div class=\"container\"><\/div>\n<p>An AWS misconfiguration in its code building service could have led to a massive number of compromised key AWS GitHub code repositories and applications, say researchers at Wiz who discovered the problem.<\/p>\n<p>The vulnerability stemmed from a subtle flaw in how the repositories\u2019\u00a0<a href=\"https:\/\/aws.amazon.com\/codebuild\/\" target=\"_blank\" rel=\"noopener\">AWS CodeBuild<\/a>\u00a0CI (continuous integration) pipelines handled build triggers. \u201cJust two missing characters in a regex filter allowed unauthenticated attackers to infiltrate the build environment and leak privileged credentials,\u201d the researchers<a href=\"https:\/\/www.wiz.io\/blog\/wiz-research-codebreach-vulnerability-aws-codebuild\" target=\"_blank\" rel=\"noopener\"> said in a Thursday blog.<\/a> \u00a0<\/p>\n<p>The regex (regular expression) filter at the center of the issue is an automated pattern-matching rule that scans log output for secrets and hides them to prevent leakage.<\/p>\n<p>The issue allowed a complete takeover of key AWS GitHub repositories, particularly the AWS JavaScript SDK, a core library that powers the AWS Console.<\/p>\n<p>\u201cThis shows the power and risk of supply chain vulnerabilities,\u201d Yuval Avrahami, co-author of the report about the bug, told CSO, \u201cwhich is exactly why supply chain attacks are on the rise: one small flaw can lead to an insanely impactful attack.\u201d<\/p>\n<p>After being warned of the vulnerability last August, AWS quickly plugged the hole and implemented global hardening within the CodeBuild service to prevent the possibility of similar attacks. Details of the problem are only being revealed now by Wiz <a href=\"https:\/\/aws.amazon.com\/security\/security-bulletins\/2026-002-AWS\/\" target=\"_blank\" rel=\"noopener\">and AWS<\/a>.<\/p>\n<p>AWS told CSO that it \u201cfound that there was no impact on the confidentiality or integrity of any customer environment or AWS service.\u201d It also advised developers <a href=\"https:\/\/docs.aws.amazon.com\/codebuild\/latest\/userguide\/webhooks.html#webhook-best-practices%EF%BF%BC%EF%BF%BC%5B3%5D\" target=\"_blank\" rel=\"noopener\">to follow best practices in using AWS CodeBuild.<\/a><\/p>\n<p>But the Wiz researchers warned developers using the product to take steps to protect their projects from similar issues.<\/p>\n<h2 class=\"wp-block-heading\">Discovery<\/h2>\n<p>Wiz discovered the problem last August after an attempted supply chain attack on the Amazon Q VS Code extension.\u00a0An attacker exploited a misconfigured CodeBuild project to compromise the extension\u2019s GitHub repository and inject malicious code into the main branch. This code was then included in a release which users downloaded. Although the attacker\u2019s payload ultimately failed due to a typo, it did execute on end users\u2019 machines \u2013 clearly demonstrating the risk of misconfigured CodeBuild pipelines.\u00a0<\/p>\n<p>Wiz researchers investigated and found the core of the flaw, a threat actor ID bypass due to unanchored regexes, and notified AWS. Within 48 hours, that hole was plugged, AWS said in a statement accompanying the Wiz blog.<\/p>\n<p>It also performed additional hardening, including adding further protections to all build processes that contain Github tokens or any other credentials in memory. AWS said it also audited all other public build environments to ensure that no such issues exist across the AWS open source estate.<\/p>\n<p>In addition, it examined the logs of all public build repositories, as well as associated CloudTrail logs, \u201cand determined that no other actor had taken advantage of the unanchored regex issue demonstrated by the Wiz research team. AWS determined there was no impact of the identified issue on the confidentiality or integrity of any customer environment or any AWS service.\u201d\u00a0<\/p>\n<p><a href=\"https:\/\/www.linkedin.com\/in\/kellman\/?originalSubdomain=ca\" target=\"_blank\" rel=\"noopener\">Kellman Meghu<\/a>, chief technology officer at Deepcove Cybersecurity, a Canadian-based risk management firm, said it wouldn\u2019t be a huge issue for developers who don\u2019t publicly expose CodeBuild. \u201cBut,\u201d he added, \u201cif people are not diligent, I see how it could be used. It\u2019s slick.\u201d\u00a0<\/p>\n<h2 class=\"wp-block-heading\">Developers shouldn\u2019t expose build environments<\/h2>\n<p>CSOs should ensure developers don\u2019t expose build environments, Meghu said. \u201cUsing public hosted services like GitHub is not appropriate for enterprise code management and deployment,\u201d he added. \u201cHaving a private GitLab\/GitHub, service, or even your own git repository server, should be the default for business, making this attack impossible if [the threat actors] can\u2019t see the repository to begin with. The business should be the one that owns the repository; [it should] not be something you just let your developers set up as needed.\u201d In fact, he said, IT or infosec leaders should set up the code repositories. Developers \u201cshould be users of the system, not the ultimate owners.\u201d\u00a0<\/p>\n<p>Wiz strongly recommends that all AWS CodeBuild users implement the following safeguards to protect their own projects against possible compromise.\u201d<\/p>\n<p>Prevent untrusted Pull Requests from triggering privileged builds by:enabling the new\u00a0<a href=\"https:\/\/docs.aws.amazon.com\/codebuild\/latest\/userguide\/pull-request-build-policy.html\">Pull Request Comment Approval<\/a>\u00a0build gate;alternatively, using\u00a0<a href=\"https:\/\/docs.aws.amazon.com\/codebuild\/latest\/userguide\/action-runner.html\">CodeBuild-hosted runners<\/a>\u00a0to manage build triggers via GitHub workflows;<\/p>\n<p>if you must rely on\u00a0<a href=\"https:\/\/docs.aws.amazon.com\/codebuild\/latest\/userguide\/webhooks.html\">webhook filters<\/a>, ensure their regex patterns are anchored.<\/p>\n<p>Secure the CodeBuild-GitHub connection by:generating a\u00a0unique, fine-grained Personal Access Token (PAT)\u00a0for each CodeBuild project;<a href=\"https:\/\/docs.aws.amazon.com\/codebuild\/latest\/userguide\/access-tokens-github.html\">strictly limiting the PAT\u2019s permissions<\/a> to the\u00a0minimum\u00a0required.<\/p>\n<p>considering using a dedicated unprivileged GitHub account for the CodeBuild integration.<\/p>\n<p><em>This article originally appeared on <a href=\"https:\/\/www.infoworld.com\/article\/4117662\/possible-software-supply-chain-attack-through-aws-codebuild-service-blunted.html\" target=\"_blank\" rel=\"noopener\">InfoWorld<\/a>.<\/em><\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>An AWS misconfiguration in its code building service could have led to a massive number of compromised key AWS GitHub code repositories and applications, say researchers at Wiz who discovered the problem. The vulnerability stemmed from a subtle flaw in how the repositories\u2019\u00a0AWS CodeBuild\u00a0CI (continuous integration) pipelines handled build triggers. \u201cJust two missing characters in [&hellip;]<\/p>\n","protected":false},"author":0,"featured_media":6576,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-6575","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6575"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6575"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6575\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/6576"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6575"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6575"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6575"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}