2回目のShai Huludサプライチェーン攻撃がエコシステム全体に波及してからわずか1日しか経っておらず、新たなユーザーや組織が毎時間侵害され続けています。その余波を精査する中で、攻撃者がAsyncAPI、PostHog、Postmanのような主要プロジェクトを侵害するために使用した初期感染経路が明らかになり始めており、このキャンペーンの全容はまだ明らかになっていないことが判明しつつあります。攻撃者はGitHub Actionsワークフローにおける巧妙かつ強力な脆弱性をエクスプロイトすることで、その攻撃手法における憂慮すべき進化を示しました。これは、防御策も同様に迅速に進化しなければならず、オープンソースエコシステムのセキュリティは、私たちが当然と見なしているインフラストラクチャを継続的に強化することにかかっているという強い警告です。
Shai-Huludキャンペーンのタイムライン
- 8月27日 - npm上の複数のnxパッケージを標的としたS1ngularityキャンペーンを詳述するレポートを公開しました。
- 9月16日 - 攻撃者が再び攻撃を仕掛け、Shai-Hulud攻撃の第一波を開始しました。
- 9月18日 - キャンペーンの技術的な特異性と初期ペイロードの挙動についてさらに深く掘り下げた追跡分析を公開しました。
- 11月24日 - npmの古いトークン失効期限の直前に、攻撃者によって「Second Coming」と名付けられた2回目の攻撃が発生しました。
- 11月25日 - AsyncAPI、PostHog、Postmanなどのプロジェクトにおける脆弱なGitHub Actionsワークフローを介した攻撃者の初期侵入経路を特定しました。
簡単な復習
Nxの侵害とShai Hulud攻撃以来、攻撃者がGitHub Actionsワークフローを悪用して、webhook.siteのリンクを通じてデータを外部に送信していることが判明しています。以前のインシデントでは、その手法は単純でした。攻撃者はワークフローファイル内に意図的なバックドアを仕込み、そのバックドアは認証情報を含む機密情報を攻撃者が制御するエンドポイントに密かに送信していました。
Shai Huludキャンペーンの最新の波で見られるのは、より高度な手法です。攻撃者はバックドアを直接挿入する代わりに、既存のGitHub Actionsワークフローの脆弱性をエクスプロイトして攻撃を実行しています。この手法の変化により、昨日のShai-Hulud攻撃でAsyncAPI、PostHog、Postmanのようなプロジェクトが侵害されることになりました。
調査は、「codespace」や「runner」といった予期せぬユーザー名に関連付けられた、NPMへの複数の不審なアップロードを検知したことから始まりました。これらのアップロードはすぐに異常として際立ち、詳細な分析により、これらはすべて攻撃者によってGitHub Actionsの悪用を通じて手動で仕込まれた可能性が高いことが示されました。その後、同様のパターンを持つ関連する悪意のあるOpenVSX拡張機能について第三者から通知を受けました。この発見により、攻撃者が手法を進化させ、侵入チェーンの一部としてCIの設定ミスを悪用していることが確認されました。
攻撃者がGitHub Actionsの脆弱性をどのように悪用したか
GitHub Actionsのワークフローは、テスト、ビルド、公開、プルリクエストの管理などのタスクを処理するためにリポジトリ内で実行される自動化されたスクリプトです。これらは強力で柔軟ですが、その力にはリスクが伴います。特に、信頼できないコードをどのように実行するかを完全に理解せずにワークフローが設定されている場合はなおさらです。
特定のワークフロートリガー、例えば pull_request_target そして workflow_runは、設定を誤ると危険になる可能性があります。これは、スクリーンショットに示されているPostHogのケースでまさに発生したことです。この問題は、最初に広く注目されたのは Adnan Khan、Xの投稿で脆弱なワークフローを指摘したセキュリティ研究者です。この攻撃は、～内の脆弱性によって引き起こされた可能性が高いです。 .github/workflows/auto-assign-reviewers.yml ワークフローです。そのファイルは危険な pull_request_target 新しいプルリクエストによって提供されたコードがCI実行中に実行されることを許可する方法でトリガーされます。この脆弱性は、2025年9月11日にマージされたプルリクエストを通じて初めて導入され、Shai Hulud攻撃まで利用可能な状態でした。攻撃者がエクスプロイトするまで、この問題は合計74日間存在していました。
同様のパターンがAsyncAPIリポジトリにも見られます。彼らの .github/workflows/auto-changeset.yml ファイルには、2025年9月9日に追加された脆弱な設定が含まれていました。AsyncAPIチームはその後、我々の推奨に従ってファイルを削除しましたが、この設定は攻撃者がこのプロジェクトをキャンペーンに含めるのに十分な期間利用可能でした。
これらのプロジェクトの1つはすでにPRスキャンツールを使用していたにもかかわらず、GitHub Actionsワークフロー内に隠された脆弱性を検出できませんでした。PostHogのケースでは、GitHubが脆弱性について警告しましたが、その警告は対処されませんでした。これは、CI設定の脆弱性を含む、幅広いシステムと言語にわたる問題を理解し、フラグ付けできるセキュリティツールの必要性を浮き彫りにしています。攻撃者がプロジェクト内でエクスプロイト可能なワークフローを特定すると、その単一の弱点が、Shai Huludワームによって示されたように、これまで見たことのない規模で広がる攻撃の足がかりとなる可能性があります。
知っておくべきことと取るべき対策
これらの脅威が進化し続けるにつれて、GitHub Actionsワークフローの脆弱性が自身のプロジェクトだけでなく、それに接続されているすべてのプロジェクトとユーザーをどのように危険にさらすかを理解することがますます重要になります。単一の設定ミスが、リポジトリを急速に広がる攻撃の最初の感染源に変え、攻撃者に毎日依存している自動化されたパイプラインを通じて悪意のあるコードをプッシュする能力を与える可能性があります。開発者は知っていることに対してのみ防御できるため、危険なワークフローパターン、例えば pull_request_target そして workflow_run 不可欠です。もう1つの選択肢は、これらの種類の脆弱性に対してリポジトリや受信プルリクエストを自動的にスキャンするAikidoのようなセキュリティプラットフォームを使用することです。
インストールする依存関係の脆弱性を認識しておくことも同様に重要です。自身のワークフローが安全であっても、上流の侵害されたパッケージがリスクをもたらす可能性があります。ここで、AikidoのSCA機能、Intel Vulnerability Database、およびPackage Healthのインサイトが特に役立ちます。これらは、チームが問題を早期に発見し、依存するライブラリが侵害や疑わしい活動の兆候を示しているかどうかを理解するのに役立ちます。
最後に、マルウェアが出現した際にリアルタイムで阻止できるツールがあれば、深刻な感染を防ぐことができます。これがAikido Safe Chainの背後にある考え方です。これはnpmをラップする無料ツールで、AIと人間のマルウェア研究者の両方を利用して、最新のサプライチェーンリスクが環境に侵入する前に検出・ブロックします。
