Tech BlogAWSツール & 技術ブログ
メニュー

カテゴリ

AWS & AI ツール

タグ

AI24Claude Code23AWS12セキュリティ11Claude9効率化8開発ツール6プラグイン5S35CloudFront5Next.js4Opus 4.83すべて見る →

axios npm侵害事件まとめ：影響チェック手順とClaude Codeで一発確認する方法

セキュリティnpmサプライチェーン攻撃axiosClaude Code

この記事の独自の切り口

CVEの解説や時系列まとめは他のセキュリティブログでも読めるので、この記事ではそこは最小限にとどめ、自分が実際に手を動かして得た「次に何をするか」に寄せて書く。具体的には以下の3点を扱う。

  • (1) Claude Codeのプロンプトで環境チェックを自動化する — lockfileやnode_modules、バックドアファイルの確認を手作業でやらず、プロンプト1本に任せる方法
  • (2) npm audit のCI組み込みへの学習転化 — 今回のインシデントをきっかけに、このブログのCI（GitHub Actions）へチェックを常設した経緯
  • (3) クレデンシャルローテーションの具体リスト — バックドアが走った前提で「何を順番に再生成するか」をチェックリスト化

事件そのものの詳細分析は末尾の参考リンク（Flatt Security Blog）に譲る。

何が起きたのか（要点だけ）

2026年3月31日、週間約1億ダウンロードのHTTPクライアント axios のnpmパッケージが侵害された。攻撃者はメンテナアカウント jasonsaayman を乗っ取り、悪意あるバージョン axios@1.14.1（latest, JST 09:21公開）と axios@0.30.4（legacy, 10:00公開）を公開。npmチームが約12:15に削除したが、この時間帯にnpm installを実行した環境はすべて影響の可能性がある。

仕組みとしては、侵害された axios の依存に悪性パッケージ plain-crypto-js@4.2.1 が追加され、その postinstall スクリプトがインストール時に自動実行されて、プラットフォーム別のRAT（リモートアクセストロイの木馬）をダウンロード・実行する。設置先とC2は以下のとおり。

環境 設置パス
macOS /Library/Caches/com.apple.act.mond
Windows %PROGRAMDATA%\wt.exe
Linux /tmp/ld.py

C2サーバ sfrclak[.]com:8000 と通信し、packages.npm.org/product[0-2] という偽装URLで正規のnpm通信に見せかける。露出時間こそ約3時間と短いが、対象がメジャーパッケージである以上、影響範囲は小さくない。

ここまでが「公式・他ブログでも読める情報」なので、以降は実際の確認と予防に進む。

影響チェック手順（手動）

Step 1: lockfileの確認

最も確実な方法は、lockfileに侵害バージョンが記録されているか確認することです。

# package-lock.json の場合
grep -E '"axios".*"(1\.14\.1|0\.30\.4)"' package-lock.json
grep "plain-crypto-js" package-lock.json

# yarn.lock の場合
grep -E 'axios@.*(1\.14\.1|0\.30\.4)' yarn.lock
grep "plain-crypto-js" yarn.lock

# pnpm-lock.yaml の場合
grep -E 'axios@(1\.14\.1|0\.30\.4)' pnpm-lock.yaml
grep "plain-crypto-js" pnpm-lock.yaml

いずれかにヒットした場合、影響を受けています。

Step 2: node_modules の確認

lockfileが更新されていなくても、node_modules 内に悪性パッケージが残っている可能性があります。

# 悪性パッケージの存在確認
ls node_modules/plain-crypto-js 2>/dev/null && echo "!! 検出: plain-crypto-js が存在します"

# axios のバージョン確認
cat node_modules/axios/package.json | grep '"version"'

Step 3: バックドアファイルの検出

すでにインストールが実行されていた場合、バックドアが設置されている可能性があります。

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "!! バックドア検出"

# Linux
ls -la /tmp/ld.py 2>/dev/null && echo "!! バックドア検出"

# Windows (PowerShell)
# Test-Path "$env:PROGRAMDATA\wt.exe"

Step 4: ネットワーク接続の確認

C2サーバへの通信が発生していないか確認します。

# アクティブな接続を確認
netstat -an | grep "142.11.206.73"
# または
ss -tnp | grep "142.11.206.73"

複数プロジェクトを一括チェック

開発マシンに複数のNode.jsプロジェクトがある場合、以下のワンライナーで一括確認できます。

# ホームディレクトリ以下のすべてのlockfileを検索
find ~/ -name "package-lock.json" -not -path "*/node_modules/*" \
  -exec grep -l "plain-crypto-js" {} \; 2>/dev/null

# node_modules 内の悪性パッケージを直接検索
find ~/ -type d -name "plain-crypto-js" -path "*/node_modules/*" 2>/dev/null

Claude Codeで一発チェックするプロンプト

Claude Codeを使っている方は、以下のプロンプトをそのまま貼り付けるだけで環境チェックができます。

プロンプト（コピペ用）

2026年3月31日のaxios npmサプライチェーン攻撃の影響を調べてください。

以下を順番にチェックして結果を報告してください：

1. このプロジェクトのlockfile（package-lock.json, yarn.lock, pnpm-lock.yaml）に
   axios@1.14.1、axios@0.30.4、または plain-crypto-js が含まれていないか確認

2. node_modules/plain-crypto-js ディレクトリが存在しないか確認

3. node_modules/axios/package.json のバージョンが 1.14.1 または 0.30.4 でないか確認

4. バックドアファイルの存在確認：
   - macOS: /Library/Caches/com.apple.act.mond
   - Linux: /tmp/ld.py

5. 結果をまとめて、影響があった場合は対処手順も教えてください

複数プロジェクト一括チェック用プロンプト

開発マシン上のすべてのNode.jsプロジェクトについて、
2026年3月31日のaxios npmサプライチェーン攻撃の影響を調べてください。

1. ~/以下でpackage-lock.json, yarn.lock, pnpm-lock.yamlを探し、
   それぞれ plain-crypto-js または axios@1.14.1, axios@0.30.4 を含むものを報告

2. ~/以下のnode_modules内にplain-crypto-jsディレクトリがないか検索

3. バックドアファイルの確認：
   - /Library/Caches/com.apple.act.mond
   - /tmp/ld.py

4. 影響があったプロジェクトのリストと対処手順をまとめてください

影響があった場合の対処

1. 即座にバージョンを戻す

# latest系
npm install axios@1.14.0

# legacy系（使用している場合）
npm install axios@0.30.3

2. 悪性パッケージの除去

# node_modules をクリーンインストール
rm -rf node_modules package-lock.json
npm install

3. バックドアの除去とプロセス停止

# macOS
rm -f /Library/Caches/com.apple.act.mond
# 関連プロセスの確認・停止
ps aux | grep "com.apple.act.mond"

# Linux
rm -f /tmp/ld.py
ps aux | grep "ld.py"

4. クレデンシャルのローテーション（最重要）

バックドアが実行された可能性がある場合、環境内のすべてのシークレットが漏洩した前提で対応してください。

  • npmトークンの再生成
  • AWS / GCP / Azure のアクセスキー
  • SSH秘密鍵の再生成
  • データベース接続情報
  • CI/CDのシークレット（GitHub Actions, CircleCI等）
  • .env ファイル内のすべての値

今後の予防策

npm v11+ の場合

.npmrc に以下を設定すると、公開から一定期間未満のバージョンをブロックできます。値は秒・分・時・日などの単位付きで記述でき、たとえば「7日」は次のように書きます。

min-release-age=7d

これにより、公開から7日未満のバージョンはインストールされなくなります。今回のように数時間で削除されるような攻撃には非常に有効です。

pnpm の場合

# .pnpmfile.cjs や設定で trustPolicy を活用
trustPolicy: no-downgrade

その他の対策

  • npm audit の定期実行: CI/CDパイプラインに組み込む
  • lockfileのdiff確認: PRレビュー時に依存関係の変更を必ずチェック
  • postinstallスクリプトの制限: npm install --ignore-scripts で postinstall 等のライフサイクルスクリプト実行を止められる。今回のように postinstall でRATを仕込む攻撃には有効な一方、ネイティブモジュールのビルドなど postinstall に依存する正常なインストールが動かなくなるトレードオフがあるため、依存構成を見極めて使い分ける
  • Socket.dev / Snyk 等のサプライチェーン監視ツールの導入

まとめ

今回のaxios侵害は、露出時間こそ約3時間と短かったものの、週間1億ダウンロードのパッケージが対象であり、影響範囲は決して小さくありません。

特にCI/CD環境では、この時間帯にビルドが走っていれば自動的にインストールされてしまうため、ビルドログの確認も忘れずに行ってください。

「自分は大丈夫だろう」ではなく、チェックして大丈夫を確認することが重要です。上記の手順やClaude Codeプロンプトを活用して、まずは確認から始めましょう。

このブログのプロジェクトで確認した結果

このブログ（Next.js + Cloudflare Pages構成、2026年5月にS3 + CloudFrontから移行済み）でも、axiosの影響を受けていないか確認した。

結果として、このプロジェクトではaxiosを直接使用しておらず、影響はなかった。 Next.jsの内部依存にもaxiosは含まれていないため、サプライチェーン経由の間接的な影響もない。

確認に使ったコマンド:

# package-lock.jsonでaxiosの有無を確認
grep -c '"axios"' package-lock.json
# → 0（axiosへの依存なし）

今回は影響がなかったが、この機会に npm audit をCI（GitHub Actions）に組み込むことにした。「問題が起きてから調べる」ではなく、定期的にチェックが走る仕組みを持っておくことが、次のインシデントへの備えになる。

参考

関連記事

← 記事一覧に戻る