概要：進化するサプライチェーン攻撃「Shai Hulud v2」
数百ものnpmパッケージが侵害され、数万ものGitHubリポジトリから機密情報が流出するという、高度なサプライチェーン攻撃が発生しました。サイバーセキュリティ研究者らは、攻撃者がGitHub Actionsワークフローをどのように悪用し、近年最も攻撃的な自己増殖型ワームキャンペーンの一つである「Shai Hulud v2」を拡散させたかを詳細に報告しています。
2025年11月24日午前4時11分（UTC）、PostHogの複数のJavaScript SDK（posthog-node、posthog-js、posthog-react-native）の悪意あるバージョンがnpmに公開され、「Shai Hulud v2」と名付けられた自己増殖型ワームが含まれていました。この攻撃はnpmの範囲を超え、Java/Mavenエコシステムにも拡大し、Maven Centralでも侵害されたアーティファクトが発見されましたが、セキュリティチームによってすぐに削除されました。
GitHub Actionsの脆弱性を突いた初期侵入
PostHogが公開した詳細な事後分析によると、この攻撃は認証情報の漏洩からではなく、GitHub Actionsワークフロー設定における微妙な脆弱性の悪用から始まったことが明らかになりました。11月18日、現在削除されているユーザーが悪意のあるプルリクエスト（PR）を作成し、`pull_request_target`トリガーを介して実行されるスクリプトを改変しました。このトリガーは、信頼できないフォークではなく、ターゲットリポジトリのセキュリティコンテキストでワークフローを実行するという開発者の誤解を悪用したものです。
この悪意あるPRは、自動割り当てスクリプトを変更し、PostHogのGitHub組織全体に広範な書き込み権限を持つボットの個人アクセストークン（PAT）を外部に持ち出しました。PRは1分以内に開かれ、ワークフローが実行され、その後すぐにクローズおよび削除されました。
Shai Hulud v2の巧妙なメカニズムと拡散
数日後の11月23日、攻撃者は窃取した認証情報を検証し、リンティングワークフローを変更するデタッチされたコミットをプッシュしました。これにより、PostHogのnpmパッケージ公開トークンを含むすべてのGitHubシークレットが収集されました。この攻撃は、`pull_request_target`がターゲットブランチからのコード実行を保証するという開発者の危険な誤解を悪用したものです。実際には、ワークフロー定義はターゲットから取得されますが、このケースで実行されたコード（PRのヘッドからチェックアウトされたJavaScriptファイル）は完全に攻撃者によって制御されていました。
悪意のあるnpmパッケージは、2段階ローダーシステムを採用しています。プリインストールスクリプトがBunランタイムをサイレントにダウンロードし、10MBの難読化されたペイロードを実行します。このペイロードは、複数のベクトルで積極的な認証情報収集を実行します。具体的には、環境内のトークンをスキャンし、すべてのAWS Secrets Manager、GCP、Azureからシークレットを列挙および抽出し、TruffleHogをホームディレクトリ全体で実行してハードコードされた認証情報を見つけ出します。
さらに、マルウェアはDockerベースのsudoers操作を通じて権限昇格を試み、パスワードなしのルートアクセスを付与し、DNSおよびファイアウォールルールを操作して中間者攻撃を可能にします。流出したデータ（環境変数、クラウドシークレット、GitHub Actions認証情報）は、検出を回避するためにトリプルBase64エンコードされ、被害者のアカウント内のランダムな名前のリポジトリに「Sha1-Hulud: The Second Coming」というキャンペーン署名とともにアップロードされます。
ワームは、窃取したnpmトークンを検証し、メンテナーごとに最大100個のパッケージを取得し、ペイロードが注入された悪意のあるパッチバージョンを公開することで伝播します。有効なトークンが見つからない場合、ペイロードはユーザーディレクトリ全体で破壊的なファイル消去操作を実行します。
PostHogの対応と推奨される対策
PostHogは数時間以内に対応し、午前9時30分（UTC）までにトークンを失効させ、既知の安全なバージョンを公開しました。同社はその後、抜本的なセキュリティ改革を実施しています。これには、npmの信頼されたパブリッシャーモデルへの移行、ワークフロー変更時のセキュリティチームによるレビュー必須化、インストールスクリプト保護を備えたpnpm 10の採用、そしてシークレット管理の再構築が含まれます。
セキュリティ研究者は、この種の攻撃から身を守るために以下の緊急対策を推奨しています。
- GitHubアカウント内の悪意のあるリポジトリを確認する。
- 露出した可能性のあるすべての認証情報をローテーションする。
- 依存関係を既知の安全なバージョンに固定する。
- パッケージマネージャーで`minimumReleaseAge`設定を実装し、新しいリリースの採用前にバッファを作成する。
この攻撃は、CI/CD設定の些細な選択が、信頼できない貢献からエコシステム全体に及ぶサプライチェーン侵害への経路を生み出す可能性を浮き彫りにしました。