悪意あるnpmパッケージがGitHub・クラウド・CI/CDの認証情報を窃取、他パッケージへも拡散

人気のnpmパッケージ「@7nohe/openapi-react-query-codegen」を狙ったサプライチェーン攻撃が発生し、開発者のワークステーションやCI/CDランナーが認証情報窃取型かつ自己拡散型のペイロードにさらされています。

2026年8月28日、攻撃者はOpenAPIからTanStack Queryへのコード生成ツールとして週間ダウンロード数約15万件を誇るこのパッケージについて、メンテナンス対象の全リリースブランチにわたり10個の悪意あるバージョンを公開しました。

公開は約20分間隔で2回の波に分かれて行われました。Socketが分析結果を公開した時点で、npmのlatestタグは侵害済みのバージョン3.0.4を指していたため、通常のインストールでも悪意あるパッケージが取得されてしまう状態でした。

影響を受けるバージョンは0.5.4、0.5.5、1.6.3、1.6.4、2.2.1、2.2.2、3.0.3、3.0.4、および悪意ある0.0.0-*プレリリース2件です。安全性が確認されているバージョンは0.5.3、1.6.2、2.2.0、3.0.2です。

安定版として汚染されたパッケージには、インストール中に実行されるよう設計された大規模な難読化JavaScriptローダー「3FWCvzduYZg.js」が含まれています。

第1波のリリースは、ネイティブビルド設定ファイルであるbinding.gypを悪用し、node-gypのビルド経路を通じてローダーを実行していました。

第2波のパッケージでは、明示的なpreinstallスクリプトが第二の実行手段として追加され、開発者のエンドポイントや自動化されたビルドシステム上でマルウェアが実行される可能性がさらに高まっていました。

このローダーは、埋め込まれた第2段階のペイロードを復号し、ランダムに生成した一時ファイル名で書き出したうえで実行し、その後にドロップしたファイルの削除を試みます。

研究者らは、このペイロードが実行チェーンの一部としてBunをダウンロードできることを確認しており、これは以前のMini Shai-Hulud活動でも見られた挙動です。

活動を開始したマルウェアは、ソースツリー、環境変数、プロセスメモリ、クラウドメタデータサービス、CI/CD環境を探索し、価値の高い認証情報を探します。

その標的には、GitHubの個人アクセストークン、npmの認証情報、PyPIおよびRubyGemsのトークン、JFrogの認証情報、AWSキー、Azure ID、Google Cloudの認証情報、HashiCorp Vaultのトークン、Kubernetes関連情報、GitHub Actionsのシークレットが含まれます。

今回の事案が従来のnpmトークン窃取ツールより深刻なのは、このペイロードが窃取した認証情報の有効性を検証し、それを再利用して他のソフトウェアサプライチェーン資産を侵害できる点にあります。

Socketが追跡しているこの悪意あるnpmパッケージは、Mini Shai-Hulud関連の事案として位置づけられており、GitHub Actionsの公開ワークフローを悪用して、有効なnpmプロベナンス証明を伴う攻撃者制御下のビルドを公開していました。

このマルウェアは、公開権限を持つnpm、JFrog、RubyGemsの認証情報を特定し、パッケージのアーティファクトを取得したうえで悪意あるコードを注入し、被害者が管理する名前空間やレジストリの下で汚染済みバージョンを再公開できます。

また、オプション機能としてPyPIでのタイポスクワッティング能力も備えており、このキャンペーンが他のエコシステムにも波及する可能性を高めています。

npmサプライチェーン攻撃

このマルウェアはさらに、窃取したトークンによって書き込みアクセスが可能なGitHubリポジトリも標的にしています。

研究者らによると、GitHub Actionsのワークフローを改変できるとされ、その中にはリポジトリのシークレットをシリアライズしてビルドアーティファクトとしてアップロードするよう設計された、デプロイトリガー型ワークフローも含まれます。

このペイロードはまた、到達可能なホストへのSSH経由の拡散にも対応しており、侵害された開発環境が横方向移動の起点となり得る状態を作り出します。

macOSおよびLinux向けの永続化メカニズムも備えており、LaunchAgentsやユーザーレベルのsystemdサービスが含まれます。

Socketはさらに、AI開発ツールやModel Context Protocolの設定箇所を改変するコードも確認しており、Claude、Codex、Copilot、Cursor、Windsurf、Cline、Aider、Geminiをはじめとする開発支援製品・関連ファイルが標的とされています。

重要な発見として、悪意ある10個のパッケージすべてが、GitHub Actionsの信頼済みパブリッシングを通じて作成された有効なnpmプロベナンス証明を持っていたことが挙げられます。

このことは、リリースワークフロー自体が信頼できないコードをビルドできてしまう場合には、署名付きプロベナンスだけでは不十分であることを示す警告となっています。

脆弱性を抱えていたrelease.ymlワークフローは、issue_commentイベントで実行され、「npm publish」という文言を含むプルリクエストのコメントを公開条件として受け付ける仕様でした。

その後、フォークからプルリクエストのHEADをチェックアウトし、id-token: write権限のもとで「pnpm publish –no-git-checks」を実行していました。

このワークフローはコメント投稿者とリポジトリとの関連性を検証していなかったため、信頼されていないGitHubユーザーでも、プロジェクトの正規のOIDC IDのもとでフォーク管理下のコンテンツの公開をトリガーできる状態にありました。

生成されたプロベナンス証明が有効に見えたのは、GitHubがコメントイベントに対してデフォルトブランチの参照を記録するためであり、アーティファクトがレビュー済みの信頼できるリポジトリコンテンツのみに由来することを証明するものではありませんでした。

その結果、npm auditの署名チェックでは、この悪意あるパッケージを検知できない可能性があります。

組織は、影響を受けるバージョンをインストールしたワークステーションやCIランナーについて、侵害済みとして扱う必要があります。

まずシステムをネットワークから隔離し、可能であれば既知のクリーンなイメージから再構築したうえで、別の安全な環境から、アクセス可能なすべてのGitHub、npm、クラウド、レジストリ、SSH、CI/CDの認証情報を失効・更新してください。

各チームは、該当する依存関係を削除し、パッケージマネージャーのキャッシュとnode_modulesをクリアしたうえでロックファイルを再生成し、既知の安全なバージョンのみを固定して使用する必要があります。

防御側は、ロックファイルやSBOMを確認して直接的・間接的なインストールの有無を調べるとともに、binding.gypおよび3FWCvzduYZg.jsの痕跡を探索し、リポジトリのコミット、npmの公開履歴、CIワークフロー、デプロイ、新規作成された公開GitHubリポジトリについても不正な活動がないか確認する必要があります。

侵害指標(IOC)

注: IPアドレスおよびドメインは、誤った名前解決やハイパーリンク化を防ぐため意図的に無害化されています（例: [.]）。再有効化はMISP、VirusTotal、SIEMなど管理された脅威インテリジェンス環境内でのみ行ってください。

★ どのセキュリティツールを削るべきか?1ページでスコア化 – 継承したセキュリティスタックガイドをダウンロード

比較セキュリティシステム