2026年1月15日、クラウドセキュリティ企業Wiz Researchは、AWS CodeBuildにおける重大なサプライチェーンの脆弱性「CodeBreach」を公表し、サイバーセキュリティ業界に衝撃を与えました。この問題は、AWSコンソールを支えるJavaScript SDKを含む、AWSの主要なGitHubリポジトリが完全に掌握される可能性を秘めていました。Wizの研究チーム、Yuval Avrahami氏とNir Ohfeld氏らは、この脆弱性を悪用すれば、攻撃者が悪意のあるコードを注入し、プラットフォーム全体に及ぶ侵害を引き起こす恐れがあったと指摘しています。
この脆弱性の根源は、リポジトリのAWS CodeBuild CIパイプラインがビルドトリガーを処理する方法における、微妙な設定ミスにありました。具体的には、正規表現フィルターにわずか2文字の欠落があったことで、認証されていない攻撃者がビルド環境に侵入し、特権的な認証情報を漏洩させることが可能になっていたのです。Wizは、この発見をAWSに責任を持って開示し、AWSは迅速に問題を修正しました。さらに、AWSは同様の攻撃を防ぐためのグローバルな強化策も実施し、特に新しいプルリクエストコメント承認ビルドゲートの導入は、信頼できないビルドを阻止するシンプルかつ安全な手段を提供しています。
この事件は、近年増加しているサプライチェーン攻撃、例えばNx S1ngularity事件などと共通のパターンを示しています。これらの事例では、CI/CDの設定における些細な見落としが、計り知れないほど大きな影響を及ぼす攻撃へとつながっています。昨年7月には、Amazon Q VS Code拡張機能のユーザーを標的としたサプライチェーン攻撃でも、同様のCodeBuildの問題が悪用されました。このような傾向は、組織がCI/CDパイプラインのセキュリティを強化することの緊急性を浮き彫りにしています。
巧妙な正規表現の盲点：脆弱性の深層
CodeBreachの核心にあったのは、AWS CodeBuildのウェブフックフィルターにおける、一見すると些細な正規表現の欠陥でした。CodeBuildは、GitHubリポジトリと連携し、新しいプルリクエストなどのイベントに基づいてビルドをトリガーするマネージドCIサービスです。この連携にはGitHub認証情報が必要であり、デフォルトではビルド環境のメモリ内に存在します。そのため、もし攻撃者が単一のビルドを侵害できれば、メモリダンプによって、多くの場合強力な権限を持つ認証情報を窃取できるという重大なリスクを抱えていました。
この攻撃シナリオを防ぐため、CodeBuildはウェブフックフィルターを提供しており、特定のイベントのみがビルドをトリガーするように設定できます。以前は、信頼できないプルリクエストに対する主要な防御策として「ACTOR_ID」フィルターが推奨されていました。これは、承認されたGitHubユーザーIDの許可リストに基づいてビルドを制限するもので、一見すると堅牢な防御策に見えました。しかし、Wiz Researchの調査により、このフィルターの実装方法に致命的な欠陥があることが判明しました。
問題は、正規表現パターンが「アンカーされていない」ことにありました。正規表現において、文字列の先頭を示す「^」と末尾を示す「$」のアンカーがない場合、正規表現エンジンはパターンに完全に一致する文字列ではなく、パターンを「含む」文字列を探します。このため、承認されたIDのスーパー文字列であるGitHubユーザーIDであれば、フィルターを迂回してビルドをトリガーできてしまうという、単純ながらも極めて重大な脆弱性が存在したのです。Wizは、この欠陥が、`aws/aws-sdk-js-v3`、`aws/aws-lc`、`corretto/amazon-corretto-crypto-provider`、`awslabs/open-data-registry`といった、パブリックなCodeBuildページを持つAWS所有の4つのリポジトリで確認されたと報告しています。
GitHub IDの「蝕」：攻撃者はいかにして標的を捕捉したか
アンカーされていない正規表現の欠陥が判明したことで、次の課題は、承認されたIDのスーパー文字列となるGitHubユーザーIDを実際に登録できるかという実践的な問題でした。GitHubがユーザーIDをユニークかつシーケンシャルな数値で割り当てるという仕組みが、この攻撃の成功に不可欠な要素となりました。2008年からの古いアカウントは5桁のIDを持ち、近年では9桁のIDにまで増加しています。この数値のシーケンスが成長するにつれて、短い古いIDが、より長い新しいIDのサブ文字列として現れることは避けられません。
Wizのテストによると、GitHubでは毎日約20万件の新しいIDが作成されています。この速度で、特定の6桁のメンテナーIDに対して、それを含む新しいより長いIDが約5日ごとに登録可能になることが判明しました。Wizはこの定期的に訪れる機会を「蝕（eclipse）」と名付けました。これは、新しいより長いIDが、信頼されたメンテナーのIDを完全に「影で覆う」瞬間を指します。標的となったAWSの4つのリポジトリはすべて、6桁または7桁の短いメンテナーIDを使用しており、頻繁に「蝕」が発生するため、すべてが有効な標的となり得たのです。
特定のIDが利用可能になった瞬間にそれを取得するという課題に対し、Wizは複数のアプローチを試みました。当初はGitHub Enterprise APIを使用して組織を作成し、IDプールをサンプリングする方法を検討しましたが、組織アカウントではプルリクエストを開けないため、最終的なエクスプロイトには不向きでした。しかし、このAPIは現在のGitHub IDをサンプリングし、標的IDへの近さを確認するツールとして再利用されました。
真の突破口は、GitHub Appsの「マニフェストフロー」から生まれました。このフローを利用すると、対応するボットユーザー（例：app-name[bot]）を自動的に作成でき、プルリクエストと対話することが可能です。Wizは、このマニフェストフローを原子的に実行できることを発見しました。つまり、アプリとそのボットは、最終的な確認URLが訪問されたときにのみ作成されるのです。これにより、Wizは事前に数百ものアプリ作成リクエストを準備し、正確なタイミングでそれらすべての確認URLを同時に訪問することで、新しいボットユーザー登録の洪水を引き起こすことに成功しました。この戦略により、`aws/aws-sdk-js-v3`リポジトリの信頼されたメンテナーIDを含む標的ID「226755743」を捕捉し、ACTOR_IDフィルターを迂回するユーザーIDを確実に取得しました。
管理者権限奪取への道：攻撃実行の詳細
ボットユーザーがACTOR_IDフィルターを迂回できるようになったことで、Wiz Researchは概念実証（PoC）の実行に移りました。彼らは`aws/aws-sdk-js-v3`リポジトリを標的とし、正当な問題を修正するプルリクエストを準備しました。しかし、このプルリクエストの内部には、ビルド環境で実行され、GitHub認証情報を抽出するように設計された新しいNPMパッケージの依存関係という、真のペイロードが隠されていました。プルリクエストが提出されると、間もなくビルドがトリガーされたという通知が届き、数分後には`aws-sdk-js-v3` CodeBuildプロジェクトのGitHub認証情報が正常に取得されました。
Wizのペイロードは、ビルド環境内のプロセスのメモリをダンプすることでGitHubトークンを取得しました。以前、Amazon Q事件への対応としてAWSが実装したCodeBuildのメモリダンプ軽減策は、この特定のプロセスを見落としていました。Wizの開示後、CodeBuildはこのプロセスも保護するようになりましたが、これは完璧な対策ではありません。GitHub認証情報は依然としてビルドのメモリ内に存在し、Linuxの特権昇格エクスプロイトを持つ攻撃者はメモリ保護を回避できる可能性があります。そのため、最も堅牢な軽減策は、そもそも信頼できないビルドが実行されるのを防ぐためにビルドゲートを使用することであるとWizは強調しています。
取得された認証情報は、`aws-sdk-js-automation`ユーザーに属するGitHub Classic Personal Access Token（PAT）でした。攻撃者にとって、このユーザーはリポジトリと定期的にやり取りし、GitHubに新しいバージョンをリリースするため、侵害するのに最適なユーザーでした。Wizは、`aws-sdk-js-automation`ユーザーがリポジトリに対する完全な管理者権限を持っていることを迅速に確認しました。当初、アクセスはトークンの権限（`repo`と`admin:repo_hook`）によってスコープされていましたが、Wizはトークンの`repo`スコープを悪用し、リポジトリのコラボレーターを管理できる機能を利用して、自身のGitHubユーザーをリポジトリ管理者として招待することで特権を昇格させました。管理者として、Wizはメインブランチに直接コードをプッシュし、任意のプルリクエストを承認し、リポジトリのシークレットを外部に持ち出すことが可能になりました。このレベルの制御は、サプライチェーン攻撃への明確な道筋を提供するものでした。
広範な影響範囲：AWSコンソールとサプライチェーンへの脅威
Wiz Researchが取得した管理者権限は、単一のリポジトリに留まらない広範な影響を及ぼす可能性を秘めていました。JavaScript SDKは毎週GitHubにリリースされ、その後NPMに公開されるため、攻撃者はこの頻繁なリリーススケジュールを悪用し、リリースが公開される直前に悪意のあるペイロードを注入することで、下流のユーザーを侵害することができたでしょう。実際に、わずか1ヶ月前には、同様の手法を用いた脅威アクターがAmazon Q VS Code拡張機能の下流ユーザーを感染させることに成功しています。
Amazon Q事件も深刻でしたが、今回の潜在的な影響は桁違いに大きいものでした。Wizの分析によると、クラウド環境の実に66%がJavaScript SDKを含んでおり、これは3つの環境のうち2つがSDKをインストールしたインスタンスをホストしていることを意味します。これは非常に普及しているソフトウェアライブラリであり、そのユーザーの中には、おそらくクラウド上で最も重要なアプリケーションであるAWSコンソール自体が含まれています。さらに、コンソールは最新のSDKバージョンをバンドルしており、ユーザー認証情報を含むコンソールからのリクエストが、わずか18日前にリリースされたSDKバージョンを使用していることが確認されています。
`aws-sdk-js-v3`リポジトリを超えて、Wizが取得したトークンは、JavaScript SDKに関連する他のいくつかのリポジトリに対しても完全な管理者権限を持っていました。これらの中には、AWSのJavaScript SDKのプライベートミラーと思われる3つのプライベートリポジトリも含まれていました。この時点で、実証された乗っ取りとその潜在的な影響を考慮し、Wizはさらなる調査を中止し、直ちにAWSに問題を報告しました。さらに重要なのは、この脆弱性がSDKの範囲を超えていたことです。Wizは`aws-sdk-js-v3`リポジトリでのCI乗っ取りのみを実行しましたが、同じACTOR_IDフィルターバイパスは、少なくとも他の3つのAWS GitHubリポジトリにも存在していました。脅威アクターはこれらを悪用して、さらに3つのGitHubアカウント（2つは`aws-sdk-js-automation`のような自動化アカウント、1つはAWS従業員の個人GitHubアカウント）のGitHub認証情報を侵害することができたでしょう。
繰り返されるCI/CDの脆弱性：過去の事例と共通の教訓
CodeBreachの発見は、CI/CD（継続的インテグレーション/継続的デリバリー）環境が、現代のサイバー攻撃における新たな主要な標的となっているという、憂慮すべき傾向を改めて浮き彫りにしました。Wizの研究者たちは、この脆弱性を「敵対者がCI/CD環境を標的とする理由を示す典型的な例」と表現しています。つまり、見落とされがちな些細な欠陥が、甚大な影響をもたらす攻撃に悪用され得るというものです。Nx S1ngularity事件やAmazon Qサプライチェーン攻撃など、最近の事例でも全く同じパターンが確認されています。
この傾向は偶然ではありません。攻撃者はCI/CDシステムにますます注目しています。その理由は、これらのシステムが攻撃にとって理想的な標的となる特性を兼ね備えているからです。第一に、CI/CDシステムは複雑であり、微妙な設定ミスが発生しやすいという性質があります。第二に、外部の貢献者からのコードをテストするなど、信頼できないデータを扱うことが多いため、悪意のあるコードが混入するリスクが高まります。そして第三に、コードへのアクセス、成果物の公開、クラウドへのデプロイには強力な認証情報が必要とされるため、CI/CDシステムは高度な特権を持っています。この複雑性、信頼できないデータ、そして特権的な認証情報の組み合わせが、事前のアクセスなしに大きな影響をもたらす侵害の完璧な温床を作り出しているのです。
CodeBreach事件の約1年前には、Sysdigの研究が、`pull_request_target`トリガーに関連するGitHub Actionsワークフローの不備が悪用され、特権的な`GITHUB_TOKEN`が漏洩し、フォークからの単一のプルリクエストによって多数のオープンソースプロジェクトへの不正アクセスが可能になることを詳細に報告していました。また、2025年9月にはOrca Securityが、Google、Microsoft、NVIDIAなどのFortune 500企業が関わるプロジェクトにおいて、脆弱な`pull_request_target`ワークフローを発見し、攻撃者が任意のコードを実行したり、機密情報を外部に持ち出したり、悪意のあるコードや依存関係を信頼されたブランチにプッシュしたりする可能性があったと指摘しています。これらの現象は「pull_request_nightmare」と称され、CI/CDパイプラインのセキュリティに対する懸念を深めています。これらの成功した攻撃は、サイバー防御側にとって重要な警鐘であり、攻撃者がすでにCI/CDパイプラインに焦点を移していることを示しています。
AWSの迅速な対応と今後の防御策
Wiz Researchからの報告を受け、AWSは迅速かつ包括的な対応を講じました。2025年8月25日にWizが脆弱性を報告した後、AWSはわずか48時間以内に、特定されたリポジトリにおけるアンカーされていない正規表現によるACTOR IDバイパスという核心的な問題を修正しました。具体的には、脆弱なACTOR IDフィルターをアンカーし、`aws-sdk-js-automation`の個人アクセストークンを失効させました。さらに、2025年9月には、GitHubトークンやその他の認証情報がメモリ内に存在するすべてのビルドプロセスを保護するための追加の強化策が実施されました。
AWSはまた、すべてのパブリックビルド環境を監査し、同様の問題が存在しないことを確認しました。関連するCloudTrailログを含むすべてのパブリックビルドリポジトリのログも監査され、Wizの研究チームが実証したアンカーされていない正規表現の問題を他のアクターが悪用した証拠は見つからなかったと結論付けました。AWSは、特定された問題が顧客環境やAWSサービスの機密性または完全性に影響を与えた証拠はないと声明で述べており、Wizの研究チームに対し、この問題の特定と責任ある協力に感謝の意を表明しています。
今回のCodeBreach事件は、CI/CDパイプラインのセキュリティ強化の重要性を改めて浮き彫りにしました。Wiz ResearchとAWSは、CodeBuildユーザーが同様の問題から自身のプロジェクトを保護するための具体的な推奨事項を提示しています。最も重要なのは、信頼できないプルリクエストが特権的なビルドをトリガーするのを防ぐことです。これには、AWSが導入した新しい「プルリクエストコメント承認ビルドゲート」を有効にするか、GitHubワークフローを介してビルドトリガーを管理するためにCodeBuildホスト型ランナーを使用することが推奨されます。ウェブフックフィルターに依存する場合は、その正規表現パターンが必ずアンカーされていることを確認する必要があります。
さらに、CodeBuildとGitHubの接続を保護するために、各CodeBuildプロジェクトに対してユニークで細粒度の個人アクセストークン（PAT）を生成し、その権限を必要最小限に厳しく制限することが不可欠です。可能であれば、CodeBuild統合のために専用の非特権GitHubアカウントを使用することも検討すべきです。セキュリティチームにとっての第一歩は、「信頼できない貢献が特権的なパイプラインをトリガーしてはならない」というシンプルかつ強力な原則を徹底することです。これは、CI/CDプラットフォームが安全なベースラインを容易に採用できるようにすることと、組織がパイプラインの特権を削減し、より厳格なビルドゲートを実装することの両方を含む、共同の取り組みによって達成されるべき課題です。
参考情報
本記事は以下の情報源を参考に作成されました：
- -CodeBreach: Supply Chain Vuln & AWS CodeBuild Misconfig | Wiz Blog - https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild
- -CodeBuild Flaw Put AWS Console Supply Chain At Risk - Infosecurity Magazine - https://www.infosecurity-magazine.com/news/codebuild-flaw-aws-console-risk/
- -AWS CodeBuild Misconfiguration Exposed GitHub Repos to Potential Supply Chain Attacks - https://thehackernews.com/2026/01/aws-codebuild-misconfiguration-exposed.html