npmサプライチェーン汚染（@tanstack/Nx事件）後にlockfileを監査する具体手順

2026年に入り、npm レジストリへ正規の発行経路を悪用して悪意あるバージョンが公開される事件が相次いだ。5月には42個の @tanstack/* パッケージに84の悪意あるバージョンが GitHub Actions の OIDC トークン経由で公開され（CVE-2026-45321）、Nx Console でも短時間だけ悪意ある版が出回った（CVE-2026-48027）。いずれも資格情報を盗む挙動を持つ。

こうした事件で怖いのは、npm install を一度でも回していれば package-lock.json に汚染バージョンが固定されている可能性があることだ。「うちは大丈夫か」を勘で判断せず、手元で機械的に確かめる手順をまとめる。

何を確認するか

1. 問題のパッケージが依存ツリーに入っているか、入っているならどのバージョンか
2. lockfile に固定された版が、公開が確認された悪意あるバージョンに一致しないか
3. パッケージの署名（provenance/signature）が検証できるか

実際に試す

前提: Node.js 18以上・npm 9以上。まず対象パッケージが入っているかを確認する。

# @tanstack配下が依存ツリーにあるか（無ければ空 or empty）
npm ls --all 2>/dev/null | grep -i '@tanstack' || echo "no @tanstack in tree"

# 特定パッケージの固定バージョンをlockfileから抜く（jq利用）
jq -r '.packages | to_entries[] | select(.key|test("node_modules/@tanstack")) | "\(.key)  \(.value.version)"' package-lock.json

次に、インストール済みパッケージの署名を検証する。npm 公式のコマンドで、レジストリの署名とローカルの内容が一致するかを一括チェックできる。

npm audit signatures

期待される出力は次のような形だ。署名が検証できないパッケージが列挙されたら要調査になる。

audited 512 packages in 3s
512 packages have verified registry signatures

既知の悪意あるバージョンに固定されていないかを機械的に照合するなら、疑わしいバージョンのリストと突き合わせる小さなスクリプトが有効だ。

# 例: 疑わしいバージョンをファイルにして照合（実際のCVEアドバイザリの版で置き換える）
cat > /tmp/bad.txt <<'EOF'
@tanstack/react-query 5.99.99
EOF

jq -r '.packages | to_entries[] | select(.value.version) | "\(.key|sub("node_modules/";""))  \(.value.version)"' package-lock.json \
  | sort -u > /tmp/installed.txt

# 名前+バージョンが一致する行があれば汚染の疑い
grep -F -f <(awk '{print $1" "$2}' /tmp/bad.txt) /tmp/installed.txt && echo "!! 要対応" || echo "一致なし"

混入が疑われたら

• 該当バージョンを削除し、クリーンな正規版へ固定して npm ci をクリーン環境で再実行する。
• CI/開発端末で露出し得たシークレット（クラウドキー・npm/GitHubトークン・SSH鍵）を失効・ローテーションする。盗まれた資格情報の悪用が本丸なので、パッケージ入れ替えだけで終わらせない。
• 今後は npm install 時に --ignore-scripts を検討し、package-lock.json の差分をレビュー対象にする。

各CVEの影響範囲・クラウド別の対応状況は「脆弱性対応ウォッチ」に整理している。パッケージ側の対応と、盗まれ得た資格情報の失効を両輪で進めるのが、この種の事件の定石だ。