2026年3月31日、JavaScriptの人気HTTPクライアントライブラリ axios のnpmアカウントが乗っ取られ、マルウェアを含む悪意あるバージョンが公開されました。週間ダウンロード数1億回以上を誇るaxiosへの攻撃は、オープンソースのサプライチェーンを標的にした高度な手口として、セキュリティコミュニティに衝撃を与えています。
何が起きたのか
axiosのリードメンテナー（GitHubアカウント名: jasonsaayman）のnpmアカウントが攻撃者に乗っ取られ、以下の2つのバージョンが公開されました。
- axios@1.14.1（1.x系ユーザーが対象）
- axios@0.30.4（0.x系ユーザーが対象）
これらのバージョンには、実際のaxiosのコードに変更はありません。代わりに plain-crypto-js@4.2.1 という隠し依存パッケージが追加されており、npm install を実行した瞬間に RAT（Remote Access Trojan）のドロッパーが起動します。
悪意あるバージョンはUTC 2026年3月31日 00:21〜03:29頃まで、約2〜3時間にわたってnpmレジストリ上に存在していました。
攻撃の仕組み
事前準備：18時間前から仕込まれていた
攻撃は偶発的なものではありませんでした。悪意あるバージョンが公開される18時間前に、囮となるクリーンバージョン（plain-crypto-js@4.2.0）が先に公開されており、npmレジストリ上での「公開履歴」を作る工作が行われていました。
実行フロー
npm install axios@1.14.1 を実行すると、以下の流れで感染が進みます。
- 依存解決により
plain-crypto-js@4.2.1が自動インストールされる - postinstallフックが
node setup.jsを実行（ユーザーの操作なし） setup.jsがリバースBase64 + XOR暗号（キー:OrDeR_7077）で難読化された文字列を復号- C2サーバー（
sfrclak.com:8000）から第2ステージのPythonペイロードをダウンロード - マルウェアがバックグラウンドで常駐（npmプロセス終了後も継続）
- 実行後、
setup.jsは自己削除し、package.jsonをクリーンな内容に差し替えてフォレンジック検知を回避
ペイロードはmacOS・Windows・Linuxの3つのOS向けに個別にビルドされており、クロスプラットフォームで感染します。
なぜCI/CDパイプラインを突破できたのか
axiosは通常、GitHub ActionsのOIDCプロビナンスとSLSAビルド証明を含む公式リリースプロセスを持っています。今回の悪意あるバージョンにはそれらが一切なく、npm CLIから直接手動でpublishされていました。正規リリースとの判別を可能にするシグナルがあったにもかかわらず、多くの環境で検知されなかった点が問題です。
また、メンテナーはOIDCを設定していたものの、NPM_TOKEN（長期有効トークン）が環境変数として残っており、攻撃者はこのトークンを悪用してpublishを実現しました。
影響を受けるバージョン
| 系統 | 影響を受けるバージョン | 安全なバージョン |
|---|---|---|
| 1.x系 | 1.14.1 | 1.14.0以前（ただし脆弱性のない最新版を選ぶこと） |
| 0.x系 | 0.30.4 | 0.30.3以前 |
UTC 2026年3月31日 00:21〜03:15の間に npm install を実行した環境は、完全に侵害されたとみなす必要があります。
影響を受けているか確認する方法
まずロックファイル（package-lock.json / yarn.lock / pnpm-lock.yaml）を確認します。
# package-lock.json を確認
grep -E '"axios@1\.14\.1"|"axios@0\.30\.4"|"plain-crypto-js@4\.2\.1"' package-lock.json
# node_modules 内を確認
ls node_modules/plain-crypto-js 2>/dev/null && echo "感染の可能性あり"上記のいずれかが検出された場合は、以降の「対処手順」を即座に実施してください。
感染していた場合の対処手順
1. ネットワークから隔離する
感染が疑われるマシンをただちにネットワークから切り離し、C2サーバーとの通信を遮断します。
2. すべてのクレデンシャルを失効・ローテーションする
インストール実行時にそのマシンがアクセスできた可能性のあるすべてのシークレットをローテーションします。
- npmトークン
- AWSアクセスキー・GCP・Azureのクレデンシャル
- SSHプライベートキー
- CI/CDシークレット（GitHub Secrets, CircleCI環境変数など）
.envファイルに記載されていた値すべて
3. マシンをクリーンな状態から再構築する
マルウェアはnpmプロセス終了後もバックグラウンドで常駐します。単なるパッケージ削除では不十分です。侵害されたマシンは既知のクリーンなスナップショットから再構築することを強く推奨します。
4. ビルド成果物の信頼性を見直す
悪意あるaxiosをインストールしたビルド環境が生成したコンテナイメージ・バンドル・デプロイパッケージは、ビルド環境自体が侵害されているため、信頼できない成果物とみなす必要があります。再ビルドが必要です。
5. axiosを安全なバージョンに固定する
# 1.x系の場合（1.13.5は直前のDoSパッチ済みバージョン）
npm install axios@1.14.0
# 0.x系の場合
npm install axios@0.30.3今後の再発防止策
今回の攻撃は非常に高度であり、個人でできる対策にも限界があります。それでも組織として実施できる主な対策を整理します。
| 対策 | 概要 |
|---|---|
| OIDCプロビナンスの必須化 | 新しいバージョンにOIDC証明がない場合に自動アラートを発報する |
| 長期トークンの廃止 | NPM_TOKENを短期・スコープ限定のトークンに移行する |
| postinstallスクリプトの制限 | pnpmはデフォルトで無効化。allowlistを明示的に管理する |
| 新規パッケージへのクールダウン | 公開直後のバージョンへの更新を一定期間ブロックするCIゲートを設ける |
| SBOMの継続的生成と監視 | syft・cdxgenでSBOMを生成し、脆弱性DBと継続照合する |
| npmプロキシの活用 | Artifactory・Nexus・Verdaccioでプロビナンスのないパッケージをブロック |
まとめ
今回のaxios事件は「既知の信頼できるパッケージ」でさえ安全ではないことを改めて示しました。axiosの1.14.1および0.30.4を使用した環境は完全侵害を前提に対処することが求められます。
チェックリストを再掲します。
- ✅ ロックファイルで
axios@1.14.1/axios@0.30.4/plain-crypto-js@4.2.1を検索 - ✅ 該当する場合はマシンをネットワーク隔離
- ✅ すべてのクレデンシャルをローテーション
- ✅ マシンをクリーンな状態から再構築
- ✅ axiosを安全なバージョンに固定し直す
- ✅ ビルド成果物を再生成する
サプライチェーン攻撃の脅威は増大しており、依存パッケージの管理はもはやセキュリティの最前線です。組織として継続的なSBOM管理とCI/CDパイプラインへのセキュリティゲートの組み込みを検討することを強くお勧めします。
コメント