TanStack 2026年 pull_request_target とキャッシュの汚染からの公開

保守者の誰も騙されず、npm のトークンも盗まれていない。フォークからの PR が基のリポジトリの文脈で走り、公開の CI が後で戻すキャッシュに悪いコードを置いた。正規のマージで走った公開の CI がそれを戻し、実行中の CI のメモリから OIDC のトークンを抜かれた。3つの既知の弱点が、それぞれの信頼の境界を1つずつ越えた。

CVE-2026-45321、GHSA-g7cv-rxg3-hmpx、CWE-506 埋め込まれた悪意あるコード[3]。悪い版は2026年5月11日 19:20 から 19:26 UTC に出た[1]。開発元は2026年5月15日に、Router と Start のリポジトリだけが影響を受け、今取れる版は全部安全だとする終息を出した[1]。GitHub は2026年6月26日に、外の人が起こせる契機のキャッシュを既定のブランチに対して読むだけに変えた[6]。2026年11月時点の公開資料で書いています。

何が起きたか

• 悪い版は、導入の時に optionalDependencies に足された依存を、フォークの網の中の孤立したコミットから取り、その準備のスクリプトで約2.3MBの難読化した JavaScript を走らせる[1]。
• 集める先は、AWS と GCP のメタデータ、Kubernetes、Vault、~/.npmrc、GitHub のトークン、SSH の秘密鍵。送る先は暗号化された伝言の網で、攻撃者の指令の機械を持たない。被害者が保守する他の包みを調べ、同じ仕掛けで公開し直して広がる[1][3]。

通った道筋

開発元は、3つの弱点のどれも単独では足りず、それぞれが他の弱点が前提にした信頼の境界を越えたと書く[1]。

仕組みを架空の作りで示す。example-org/example-lib の CI で、悪い形と直した形を並べる。

悪い例。外の人のコードを特権の文脈でビルドし、キャッシュを保存する

on:
  pull_request_target:          # 基のリポジトリの文脈で走る
jobs:
  size:
    permissions:
      contents: read             # キャッシュの保存は止めない
    steps:
      - uses: actions/checkout@...
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
      - uses: actions/cache@...  # 終わりに main の範囲へ保存
        with:
          path: ~/.pnpm-store
          key: pnpm-${{ hashFiles('pnpm-lock.yaml') }}
      - run: pnpm install && pnpm build   # PR のコードが走る

直した例。PR のコードは権限の無い pull_request で走らせ、結果だけを渡す

# size.yml 外の人のコードを走らせる側
on:
  pull_request:
jobs:
  size:
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@...  # コミットのハッシュで固定
      - run: pnpm install --ignore-scripts && pnpm build
      - run: du -sb dist > size.txt
      - uses: actions/upload-artifact@...
        with: { name: size, path: size.txt }

# size-comment.yml 書き込みの権限を持つ側。PR のコードを走らせない
on:
  workflow_run:
    workflows: [size]
    types: [completed]
# 成果物を runner.temp に落とし、数字として確かめてから PR に書く

GitHub Security Lab は、信頼しない PR のコードは pull_request で権限の無い所に閉じ、結果を成果物に置いて、書き込みの権限を持つ workflow_run の側で読む形を勧める。成果物も信頼しない物として扱い、特権の側で実行しない[7]。GitHub の手引きも、PR のコードをビルドや実行に使うなら pull_request_target を避けるよう書く[5]。

どう見つかったか

• 見つけたのは外の研究者で、最初の公開から約26分後に issue で報告した[1]。開発元は、自分の公開を見張る仕組みが無く、外から知ったと書く[1]。
• 悪いコードが試験を壊したため、正規の公開の手順は飛ばされ、CI は失敗で終わった。開発元は、試験を壊さない攻撃者なら、もっと長く気付かれずに出せたと書く[1]。
• 依存を持つ包みが多く、npm の決まりで開発元は悪い版を取り下げられなかった。npm の側の削除を待つ間、悪い版は入れられる状態だった[1]。非推奨にするまで公開から約1時間43分、npm の削除の終わりまで約4時間35分かかった[1]。
• 開発元は、ペイロードの中の、無効化に反応する仕掛けに研究者が気付き、トークンの無効化が始まる前に知らせたことが、被害を大きくしなかった理由だと書く[2]。漏れた鍵を回す前に、悪い版が何を見張っているかを確かめる。

後に続いた被害

悪い版は、入った端末の GitHub の資格情報を集める。その先で次の被害が出た。

• Nx は、自社の開発者の1人が TanStack の件で侵害され、GitHub CLI の資格情報が漏れ、攻撃者が貢献者としてリポジトリのワークフローを走らせられたことを原因に挙げた。悪い Nx Console 18.95.0 は、Visual Studio Marketplace に約18分、OpenVSX に約36分あった[9]。
• Nx は、それまで1人で承認無しに Nx Console を出せた形を、2人の管理者の承認が要る形に変えた[9]。
• GitHub は5月20日に、第三者が出した毒入りの VS Code の拡張で従業員の端末が侵害され、5月18日に検知して封じ込めたと発表した。その拡張として Nx Console の勧告を結んでいる。持ち出されたのは GitHub の社内のリポジトリで、攻撃者の言う約3,800のリポジトリは調査と大筋で合うと書く。5月26日の更新では、GitHub Enterprise Server の署名の鍵を回すと告げ、調査は続いているとした[10]。

どこで止められたか

守り方

公開の仕事を分けた架空の release.yml

jobs:
  build:
    permissions:
      contents: read             # id-token を持たない
    steps:
      - uses: actions/checkout@...
      - run: pnpm install --frozen-lockfile && pnpm test && pnpm pack
      - uses: actions/upload-artifact@...

  publish:
    needs: build
    environment: npm-publish     # 承認者の許可が要る
    permissions:
      contents: read
      id-token: write            # この仕事だけ
    steps:
      - uses: actions/download-artifact@...
      - run: npm publish ./example-lib-*.tgz   # 依存を入れず、キャッシュも戻さない

• build の仕事が汚されても、そこに OIDC のトークンは無い。publish の仕事は依存を入れずキャッシュも戻さないので、他人のプログラムが走る余地が小さい。成果物の中身が汚されている危険は残るので、承認の前に中身の差を見る。

AIの名前のコミット

悪いコミットの作者は claude という偽の名前で、GitHub の no-reply の宛先を使っていた。開発元は、本物の Anthropic の Claude ではないと注記している[1]。

• コミットの作者の欄は、誰でも書ける。AIの道具の名前が付いていることは、そのコミットを信じる理由にならない。誰が push し、誰が PR を開いたかを見る。
• AIのコーディングの道具は、CI の定義を書き、pull_request_target のような契機を選び、キャッシュを足す。CI の定義の差分は、鍵を持って走るコードの差分として、人が読んでから入れる。見方は AIの出力を確かめる にある。
• CI の定義で使わない契機と、公開の仕事の形を、リポジトリの決まりとして文書に残す。置き方は 決まりを文書に残す にある。

取り込む物を使う直前に確かめる考え方は A08 ソフトウェアまたはデータの完全性の不備 にある。

参照

1. Postmortem: TanStack npm supply-chain compromise TanStack、2026年5月11日、5月15日更新
2. Hardening TanStack After the npm Compromise TanStack、2026年5月12日、5月15日更新
3. GHSA-g7cv-rxg3-hmpx Malware in @tanstack/* packages GitHub Advisory Database、2026年5月12日。CVE-2026-45321
4. Dependency caching reference GitHub Docs
5. Events that trigger workflows, pull_request_target GitHub Docs
6. Read-only Actions cache for untrusted triggers GitHub Changelog、2026年6月26日
7. Keeping your GitHub Actions and workflows secure: Preventing pwn requests GitHub Security Lab
8. Trusted publishing for npm packages npm Docs
9. GHSA-c9j4-9m59-847w Compromised Nx Console version 18.95.0 Nx、2026年5月18日、5月21日に原因を追記
10. Investigation update: GitHub Enterprise Server signing key rotation GitHub、2026年5月20日、5月26日更新