第二のシャイ・フルード型サプライチェーン攻撃が生態系全体に波及してからわずか1日が経過したばかりだが、新たなユーザーや組織が今も毎時間侵害され続けている。影響の分析を進める中で、攻撃者がAsyncAPI、PostHog、Postmanといった主要プロジェクトを侵害するために利用した初期感染経路が明らかになりつつあり、この攻撃キャンペーンの全容はまだ見えていないことが明らかになりつつある。 GitHub Actionsワークフローの微妙だが強力な脆弱性を悪用することで、攻撃者はその攻撃手法において憂慮すべき進化を示した。これは、我々の防御策も同様に迅速に進化させねばならないこと、そしてオープンソースエコシステムのセキュリティは、我々がしばしば当然視しているインフラを継続的に強化することに依存していることを強く想起させる。
シャイ・フルード作戦の年表
- 8月27日 - npm上の複数のnxパッケージを標的としたS1ngularityキャンペーンの詳細を記した報告書を公開します。
- 9月16日 - 攻撃者が再び襲撃を開始し、シャイ・フルード攻撃の第一波を仕掛けた。
- 9月18日 - キャンペーンの技術的特徴と初期ペイロードの挙動についてさらに深く掘り下げた追跡分析を公開します。
- 11月24日- 攻撃者らが「再臨」と称する第二の攻撃が発生。これはnpmが古いトークンの失効期限を設定する直前にタイミングを合わせたものだった。
- 11月25日- AsyncAPI、PostHog、Postmanなどのプロジェクトにおける脆弱なGitHub Actionsワークフローを通じた攻撃者の初期侵入経路を明らかにする。
簡単な復習
Nx侵害とシャイ・フルード攻撃以来、攻撃者がGitHub Actionsワークフローを悪用し、webhook.siteリンクを介してデータを流出させていることが判明している。初期の事例では手法は単純明快だった。攻撃者はワークフローファイル内に意図的なバックドアを仕込み、そのバックドアが認証情報を含む機密データを攻撃者が制御するエンドポイントへ密かに送信していた。
最新のShai Hulud攻撃の波で見られる手法はより高度化している。攻撃者はバックドアを直接挿入する代わりに、既存のGitHub Actionsワークフローの脆弱性を悪用して攻撃を実行している。この手法の変化こそが、昨日のShai-Hulud攻撃においてAsyncAPI、PostHog、Postmanといったプロジェクトを侵害することを可能にした要因である。
調査は、NPMへの複数の不審なアップロードが「codespace」や「runner」といった予期せぬユーザー名に関連していることに気づいたことから始まりました。これらのアップロードは直ちに異常として目立ち、詳細な分析により、すべてが攻撃者によるGitHub Actionsの悪用を通じて手動でシードされた可能性が高いことが判明しました。 その後、第三者から同様の手口を用いた悪意のあるOpenVSX拡張機能に関する通報を受けました。この発見により、攻撃者が手法を進化させ、侵入チェーンの一環としてCIの誤設定を悪用していることが確認されました。
攻撃者がGitHub Actionsの脆弱性をどのように利用したか
GitHub Actionsワークフローは、リポジトリ内で実行される自動化されたスクリプトであり、テスト、ビルド、公開、プルリクエストの管理などのタスクを処理します。これらは強力で柔軟ですが、その力にはリスクが伴います。特に、ワークフローが信頼できないコードをどのように実行するかを完全に理解せずに設定された場合にはなおさらです。
特定のワークフロートリガーを含む プルリクエスト対象 そして ワークフローの実行誤設定すると危険になり得る。スクリーンショットに示されているように、PostHogの事例ではまさにこれが発生した。この問題は最初に アドナン・カーンセキュリティ研究者がXの投稿で脆弱なワークフローを指摘した。この攻撃は、内部の脆弱性が原因である可能性が高い。 .github/workflows/auto-assign-reviewers.yml ワークフロー。そのファイルは危険な プルリクエスト対象 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ワークフローの脆弱性が、自身のプロジェクトだけでなく、それに接続された全てのプロジェクトやユーザーを危険に晒す仕組みを理解することがますます重要になっています。たった一つの設定ミスが、リポジトリを急速に拡散する攻撃の起点（患者ゼロ）に変え、敵対者が日常的に依存する自動化されたパイプラインを通じて悪意のあるコードを押し込む能力を与える可能性があります。開発者は認識している脅威に対してのみ防御できるため、以下のような危険なワークフローパターンへの認識が不可欠です： プルリクエスト対象 そして ワークフローの実行 不可欠です。別の選択肢として、Aikido セキュリティプラットフォームを利用する方法がありますAikido リポジトリや送信されるプルリクエストを自動的にスキャンし、こうした種類の脆弱性を検出します。
インストールする依存関係における脆弱性への注意を怠らないことも同様に重要です。自身のワークフローが安全であっても、上流で侵害されたパッケージがリスクをもたらす可能性があります。ここで特に有用なのが、Aikido、Intel脆弱性データベース、およびパッケージ健全性インサイトです。これらはチームが問題を早期に発見し、依存しているライブラリに侵害の兆候や不審な活動がないかを把握するのに役立ちます。
最後に、マルウェアが出現した瞬間にリアルタイムで阻止できるツールがあれば、深刻な感染を防ぐことができます。Aikido Chainの考え方です。この無料ツールはnpmをラップし、AIと人間のマルウェア研究者の両方を活用して、最新のサプライチェーンリスクが環境に入る前に検知・ブロックします。
今すぐソフトウェアを保護しましょう
.avif)
