TanStack Query向けnpmにサプライチェーン攻撃 10個の悪性バージョン公開、認証情報を窃取する自己増殖型ワーム

セキュリティニュース

投稿日時: 更新日時:

TanStack Query向けnpmにサプライチェーン攻撃 10個の悪性バージョン公開、認証情報を窃取する自己増殖型ワーム

TanStack Query向けのコードジェネレーター「@7nohe/openapi-react-query-codegen」で2026年8月28日、サプライチェーン攻撃が発生し、npmへ10個の悪性バージョンが公開されました。

プロジェクト管理者が公開したGitHub Security Advisoryによると、攻撃者はGitHub Actionsのリリースワークフローに存在した認可不備を悪用し、20:00〜20:21 UTCの約21分間に悪性バージョンを相次いで公開しました。影響バージョンを開発端末やCI/CD環境でインストールした場合、インストールプロセスの権限で攻撃者コードが実行されたとしています。

JFrogやEndor Labsなどの解析では、マルウェアはGitHub、npm、PyPI、RubyGems、AWS、Azure、Google Cloud、HashiCorp Vault、Kubernetes、SSHなどの認証情報を収集し、窃取したパッケージ公開権限を使って別のパッケージへ感染を広げる自己増殖機能を備えていることが確認されています。

ただし、今回侵害されたのはTanStack Query本体ではありません。「@7nohe/openapi-react-query-codegen」はOpenAPIスキーマからTanStack Query向けのTypeScriptクライアントやReact hooksを生成する第三者製npmパッケージです。2026年5月に発生したTanStack公式npmパッケージ群へのサプライチェーン攻撃とは別のインシデントです。

@7nohe/openapi-react-query-codegenサプライチェーン攻撃のサマリー

  • 2026年8月28日、npmパッケージ「@7nohe/openapi-react-query-codegen」の10個の悪性バージョンが公開されました。
  • GitHub Security Advisory「GHSA-9pvf-vcx3-x239」はCritical、CVSS v3.1 9.6と評価しています。
  • CVE番号は本稿執筆時点で割り当てられていません。
  • 悪性バージョンは20:00〜20:21 UTCの約21分間に公開されました。
  • latest dist-tagは20:19:29 UTCから悪性3.0.4を指し、約22:51 UTCに正常な3.0.2へ戻されました。
  • 影響バージョンは0.5.4、0.5.5、1.6.3、1.6.4、2.2.1、2.2.2、3.0.3、3.0.4と、2個の0.0.0系プレリリースです。
  • 3.0.2以前の既存正常リリースは影響を受けていないと管理者は説明しています。
  • 影響バージョンをインストールした端末やCI runnerでは、攻撃者コードが実行された可能性があります。
  • マルウェアはGitHub、npm、PyPI、RubyGems、クラウド、Vault、Kubernetes、SSHなどの認証情報を収集します。
  • 研究者は、窃取したパッケージ公開権限を使ってnpm、RubyGems、PyPIへ感染を広げる自己増殖機能を確認しています。
  • 攻撃者はメンテナーの長期npmトークンを盗んだのではなく、正規のGitHub Actions OIDC Trusted Publishing経路を悪用しました。
  • このため、悪性バージョンにも有効なprovenance attestationが付与されていました。
  • プロジェクト側は問題のワークフロートリガーを削除し、npm Trusted Publisherの無効化、認証情報ローテーション、dist-tag復旧などを実施しました。
  • JFrogは今回のマルウェアをMini Shai-Hulud系の「Trinitite」と分析しています。
  • AikidoはTeamPCP関連活動との類似を指摘していますが、攻撃主体の帰属は確定していません。
  • npm公式ページでは現在3.0.2が表示されています。週間ダウンロード数は約15万5,000件ですが、これは悪性バージョンの感染件数ではありません。
項目 内容
公表日 2026年8月28日
対象 @7nohe/openapi-react-query-codegen
パッケージ種別 OpenAPIからTanStack Query向けコードを生成するnpmパッケージ
Advisory GHSA-9pvf-vcx3-x239
深刻度 Critical
CVSS 9.6(CVSS v3.1)
CVE 割り当てなし
悪性バージョン 10個
公開時間帯 2026年8月28日20:00〜20:21 UTC
影響 インストール端末・CI上で攻撃者コード実行
主な標的 GitHub、npm、PyPI、RubyGems、クラウド、Vault、Kubernetes、SSH等の認証情報
自己増殖 npm・RubyGems・PyPIへの再公開機能を研究者が確認
根本原因 GitHub Actionsリリースワークフローの認可不備
provenance 悪性バージョンにも正規ワークフロー由来のattestationあり
TanStack Query本体 今回事案の直接侵害対象ではない
攻撃者 未確定
対応 悪性版deprecated、削除申請、latestを3.0.2へ復旧、workflow修正、認証情報ローテーション

影響を受ける10個のバージョン

GitHub Security Advisoryで確認されている影響バージョンは次の通りです。

系列 悪性バージョン 正常とされる直前バージョン
0.5.x 0.5.4、0.5.5 0.5.3
1.6.x 1.6.3、1.6.4 1.6.2
2.2.x 2.2.1、2.2.2 2.2.0
3.0.x 3.0.3、3.0.4 3.0.2
プレリリース 0.0.0-365d4eb738d3146583431948d3ba6e27a32556be
プレリリース 0.0.0-ec7876d6c917dad516ba69bbfafc948b834bf0ab

GitHub Advisoryでは、2026年8月28日より前に公開されたバージョンは影響を受けず、3.0.2以前は正常としています。

npm公式ページでも現在3.0.2が表示されています。

npm上の週間ダウンロード数は本稿確認時点で約15万5,000件です。ただし、この数字はパッケージ全体のダウンロード数であり、悪性バージョンのインストール件数や感染端末数を示すものではありません。

TanStack Query本体ではなく第三者製コードジェネレーターが侵害

今回の対象を「TanStack Queryが侵害された」と表現するのは正確ではありません。

「@7nohe/openapi-react-query-codegen」は、OpenAPIスキーマをもとにTanStack Queryで利用するTypeScriptクライアントやReact hooksを生成する第三者製OSSです。

TanStack Query本体のnpmパッケージである「@tanstack/react-query」とは管理主体が異なります。

TanStack公式エコシステムでは2026年5月11日にも別のサプライチェーン攻撃が発生し、Router関連を中心とする42個の@tanstack/*パッケージへ84個の悪性バージョンが公開されました。

セキュリティ対策Labでは、この事案を「TanStackのnpmパッケージ42件にサイバー攻撃でマルウェアが混入、GitHub Actions経由で認証情報窃取の恐れ」で整理しています。

今回の8月28日の事案は、5月のTanStack公式パッケージ侵害とは別のパッケージ、別のリリースワークフローで発生しました。

GitHub Actionsのリリースワークフロー認可不備を悪用

GitHub Security Advisoryによると、根本原因はプロジェクトのリリースワークフローにありました。

このワークフローはPull Request上の特定コメントをトリガーとしてnpm公開処理を開始できる構成でしたが、コメントした利用者がメンテナーや信頼済みコントリビューターかを確認するauthor associationのチェックがありませんでした。

さらに、ジョブはPull Request側のコードをチェックアウトして依存関係をインストールした後、npm Trusted Publishingに利用できるid-token: write権限を持った状態で公開処理を実行していました。

結果として外部ユーザーが、メンテナーのnpmパスワードや長期間有効なnpmトークンを直接盗むことなく、正規のGitHub Actions公開経路から悪性バージョンをnpmへ公開できる状態になっていました。

プロジェクト管理者はインシデント後、問題のコメント起点トリガーを削除し、リリースをタグのpush起点へ変更しています。

悪性バージョンにも正規のprovenanceが付与

今回の事案で特に重要なのが、悪性npmパッケージにも有効なprovenance attestationが付与されていた点です。

npmのprovenanceは、パッケージがどのソースリポジトリ、どのCI/CDワークフローから生成されたかを検証するための仕組みです。

しかし今回、攻撃者は正規のGitHub Actionsワークフローそのものを悪用しました。

そのため、悪性バージョンも「正規ワークフローから公開された」という事実自体は正しく、有効なSLSA provenance attestationを持っていました。

GitHub Advisoryも、provenanceだけでは当該ビルドが信頼できることを意味しないと注意しています。

サプライチェーン対策では、成果物の署名だけでなく、公開ジョブを誰が起動できるか、ジョブがどのコードを実行するか、OIDCトークンの発行前に信頼できないコードが動かないかまで確認する必要があります。

インストール時に攻撃者コードを実行

悪性バージョンには、正常リリースには存在しない難読化JavaScriptと、インストール時に実行させるための仕組みが追加されていました。

GitHub Advisoryでは、安定版8件のうち一部はbinding.gyp経由、一部はpreinstall処理を併用してペイロードを起動したと説明しています。

影響バージョンをインストールすると、開発端末またはCI runner上で、インストールプロセスと同じ権限で攻撃者コードが実行される可能性があります。

本稿では悪用可能な具体的コードや実行手順は掲載しません。

なお、2個の0.0.0系プレリリースについては悪性preinstall設定が存在したものの、パッケージング設定の影響で参照先ペイロードがtarballに含まれていなかったとGitHub Advisoryは説明しています。

このため、10個の悪性バージョンがすべて同じ実行経路・実行結果だったわけではありません。

GitHub・npm・クラウド・SSHなどの認証情報を収集

JFrogとEndor Labsの解析では、実行されたマルウェアは開発環境やCI/CD環境に保存された幅広い認証情報を探索します。

対象として確認されているのは、GitHub、npm、PyPI、RubyGemsの認証情報、AWS・Azure・Google Cloudの認証情報、HashiCorp Vault、Kubernetes、SSH秘密鍵、各種環境変数などです。

開発端末やCI runnerは、通常の社員端末よりもソースコード、パッケージレジストリ、クラウド、デプロイ環境へ強い権限を持っている場合があります。

そのため、悪性依存関係を1回インストールしただけでも、影響が開発端末だけにとどまらず、GitHubリポジトリ、クラウド環境、他のパッケージへ広がる可能性があります。

npm・RubyGems・PyPIへ自己増殖するワーム

今回のマルウェアは、認証情報を盗んで終わるCredential Stealerではありません。

JFrogとEndor Labsは、窃取したパッケージレジストリの認証情報を利用し、被害者が公開権限を持つ別のパッケージに悪性コードを追加して再公開する自己増殖機能を確認しています。

Endor Labsによると、今回の亜種ではnpm、RubyGemsに加えPyPIへの伝播機能も実装されています。

つまり、直接「@7nohe/openapi-react-query-codegen」を利用していた環境だけでなく、その環境に別パッケージを公開できる認証情報が存在した場合、別のパッケージ利用者へ二次感染する可能性があります。

この自己伝播性から、各セキュリティ企業は今回のマルウェアをサプライチェーン「ワーム」と位置づけています。

JFrogはMini Shai-Hulud系「Trinitite」と分析

JFrog Security Researchは今回のマルウェアを、過去に確認されたMini Shai-Hulud系サプライチェーンワームの新たな波と分析し、「Trinitite」と呼んでいます。

認証情報収集、GitHubを利用したデータ外部送信、パッケージ公開権限による自己増殖など、過去のMini Shai-Hulud系マルウェアとの共通点が確認されています。

Aikido SecurityはTeamPCPに関連した過去の活動との類似性を指摘しています。

ただし、Aikido自身も、模倣者、残存メンバー、別の攻撃者など複数の可能性を挙げており、帰属は確定していません。

JFrogも、使用されたマルウェアだけでは攻撃主体を確定できないとしています。

したがって、本件を「TeamPCPによる攻撃」と断定することはできません。

セキュリティ対策Labでは、2026年5月に発生したMini Shai-Huludの大規模なサプライチェーン攻撃について「TanStack・Mistral AI・UiPath・npm・PyPIを狙うサイバー攻撃」でも整理しています。

latestは一時3.0.4を指し、その後3.0.2へ復旧

GitHub Security Advisoryによると、npmのlatest dist-tagは8月28日20:19:29 UTCから悪性バージョン3.0.4を指していました。

その後、約22:51 UTCに正常な3.0.2へ戻されました。

プロジェクト管理者は対応として、問題のissue_commentトリガーを削除し、npm Trusted Publisherを無効化、長期認証情報をローテーションしました。

さらに、latestを3.0.2へ戻し、不要なdist-tagを削除、10個の悪性バージョンをdeprecated化し、npm Securityへ削除を申請しています。

現在正常バージョンへ戻っていても、8月28日の影響時間帯に悪性バージョンを取得した開発端末やCI runnerは別途調査が必要です。

package.jsonだけでなくlockfile・CIログを確認

GitHub Advisoryは、影響バージョンを直接または推移的にインストールした環境を、攻撃者コードが実行された可能性のある環境として扱うよう求めています。

確認対象はpackage.jsonだけではありません。

package-lock.jsonpnpm-lock.yamlyarn.lock、CI/CDの実行ログ、依存関係キャッシュ、SBOM、コンテナビルド履歴、開発端末のインストール履歴などを確認する必要があります。

現在package.jsonが3.0.2を指していても、8月28日の一時的なlatest変更中にCIが3.0.4を解決して実行していた可能性は残ります。

特にlatestや広いSemVer範囲で依存関係を取得していた場合、lockfileとビルドログの確認が重要です。

影響環境ではシークレットローテーションを検討

GitHub Security Advisoryは、8月28日20:00 UTC以降に影響バージョンをインストールした場合、その端末またはCI runnerからアクセス可能だった認証情報をローテーションするよう求めています。

対象にはnpmトークン、GitHubトークン、SSH鍵、クラウド認証情報、環境変数内のシークレットなどが含まれます。

また、自社のnpmアカウントについて、自身が公開していないバージョンが存在しないか、GitHubに身に覚えのないリポジトリ、workflow run、SSH鍵などが追加されていないかも確認する必要があります。

感染が疑われる開発端末やCI runnerは、単に依存パッケージを削除するだけでなく、侵害端末として隔離・調査したうえで、正常な別端末から認証情報を変更するのが安全です。

主なIOC

GitHub Advisoryや研究各社は調査に利用できるIOCを公開しています。

IOC 内容
@7nohe/openapi-react-query-codegen 0.5.4 / 0.5.5 悪性バージョン
1.6.3 / 1.6.4 悪性バージョン
2.2.1 / 2.2.2 悪性バージョン
3.0.3 / 3.0.4 悪性バージョン
2個の0.0.0系プレリリース 悪性バージョン
3FWCvzduYZg.js 悪性安定版で確認された難読化JavaScript
binding.gyp 正常リリースには存在しない実行トリガーとして利用

IOCは調査の手掛かりです。

GitHub Advisoryは、バージョンごとにペイロードのビルドが異なるため、単一ファイルのハッシュだけではすべての影響バージョンを検知できないとしています。

悪性バージョンの存在、追加ファイル、install hook、CIログなど複数の情報を組み合わせて確認する必要があります。

情報システム・開発部門への示唆

今回の事案は、OSSサプライチェーン対策を「npmトークンを守る」「成果物へ署名する」だけでは完結できないことを示しています。

第一に、GitHub Actionsなどのリリースワークフロー自体を本番システムとして扱う必要があります。

Pull Request、Issue、コメントなど外部ユーザーが操作できるイベントから、id-token: write、パッケージ公開、クラウドデプロイなどの高権限ジョブへ到達できないかを確認してください。

第二に、OIDC Trusted Publishingを利用していても安全が自動的に保証されるわけではありません。

長期npmトークンを廃止することは有効ですが、信頼されていないコードを実行した後にOIDCトークンを発行できる設計では、正規の公開経路そのものが悪用されます。

第三に、依存関係はバージョン固定とlockfileを基本にします。

latestや広いSemVer範囲をCIで毎回解決している場合、今回のように短時間だけ公開された悪性バージョンを自動的に取り込む可能性があります。

第四に、CI/CDのシークレットを最小化する必要があります。

1つのビルドジョブからnpm、GitHub、AWS、GCP、Azure、Kubernetesなど多数のシークレットへアクセスできる場合、悪性依存関係1個から影響が横断的に広がります。ジョブ単位で短命な認証情報を発行し、必要な権限だけを与える設計が重要です。

第五に、provenanceは「安全証明」ではなく複数ある信頼シグナルの一つとして利用します。

今回の悪性バージョンは正規GitHub Actions経由だったため、有効なprovenanceを持っていました。署名・attestationの確認に加え、ソース差分、ライフサイクルスクリプトの追加、パッケージサイズの急増、CI/CDワークフロー変更なども監視する必要があります。

最後に、開発端末とCI runnerをエンドポイントセキュリティの対象外にしないことです。

ソフトウェアサプライチェーン攻撃では開発環境そのものが本番侵害の入口になります。EDR、ネットワーク監視、SBOM、依存関係スキャン、CIログ監査などを組み合わせ、パッケージインストール時の不審なコード実行や外部通信を検知できる体制が求められます。

出典