Blog

axios@1.14.1 サプライチェーン攻撃：今すぐすべきこと

Ashley Innocent

Ashley Innocent

2 4月 2026

axios@1.14.1 サプライチェーン攻撃：今すぐすべきこと

まとめ

2026年3月30日から31日にかけ、axiosのバージョン1.14.1と0.30.4がnpm上で不正な依存関係によって侵害され、感染したマシンにリモートアクセス型トロイの木馬（RAT）が仕掛けられました。両バージョンはすでに公開停止されています。安全なバージョンは1.14.0です。axios@1.14.1または0.30.4をインストールした場合は、マシンが侵害されたとみなし、直ちにすべての認証情報を変更してください。

axiosとは何か、そしてなぜこれが重要なのか

axiosはnpmで週に1億回ダウンロードされています。これは数えきれないほどのフロントエンドフレームワーク、バックエンドのNode.jsサービス、エンタープライズアプリケーションにおけるHTTPクライアントです。これほど基盤となるパッケージが侵害されると、その影響範囲は計り知れません。3月30日から31日までの狭い時間枠でnpm installを実行した開発者は、知らぬ間にマルウェアを自分のマシンに引き込んでしまいました。

これは仮説上のサプライチェーンリスクではありません。実際に発生し、確認され、そのペイロードは深刻なものでした。任意のコマンドを実行し、システムデータを外部に送信し、感染したマシンに永続化できる多段階のリモートアクセス型トロイの木馬です。

もしあなたのチームがaxiosを使用しており、Apidogを使ってHTTPクライアントの統合を設計・テストしているのであれば、次回のデプロイの前にこれを読んでください。

button

攻撃のタイムライン

2026年3月30日 — 23:59:12 UTC: nrwise@proton.meを使用するアカウントによって、plain-crypto-js@4.2.1という悪意のあるパッケージがnpmに公開されました。その18時間前には、正規のcrypto-jsライブラリの巧妙なタイポスクワットとして、より古いクリーンなバージョン（4.2.0）が公開されていました。

2026年3月31日 — 00:05:41 UTC: Socketの自動マルウェア検出システムが、plain-crypto-js@4.2.1を悪意のあるものとしてフラグ付けしました — 公開からわずか6分後のことです。

2026年3月31日 — 深夜直後: axios@1.14.1がnpmに公開され、依存関係としてplain-crypto-js@4.2.1を引き込みました。このリリースはaxiosのGitHubリポジトリの公式タグには表示されていません。最も新しい正規のタグはv1.14.0のままです。

2026年3月31日 — 午前: GitHubイシュー#10604が公開され、axios@1.14.1とaxios@0.30.4の両方が侵害されたことが報告されました。axiosのメンテナーは、攻撃者のアクセスを最初に取り消せないことを確認しました — 侵害されたアカウントは正規のメンテナーよりも高いnpm権限を持っていました。

2026年3月31日: axios@1.14.1とaxios@0.30.4の両方がnpmから公開停止されました。axiosのメンテナーは、トークンの失効、公開制御の強化、そして長期にわたるnpmトークンがどのように悪用され、不正な公開アクセスを得たのかの調査を開始しました。

攻撃の手口

この攻撃は、axiosの公開ワークフローにおけるギャップを悪用したものです。信頼された公開とともに使用されていた、長期有効なnpmトークンがそれです。攻撃者は — おそらくメンテナーの認証情報を侵害した後 — このトークンを使用して、通常のリリースプロセス外で新しいバージョンを公開しました。

新しいバージョンは、依存関係としてplain-crypto-js@4.2.1を導入しました。このパッケージ名は、正規の暗号化ユーティリティのように見せかけるよう設計されていました。以前のクリーンな4.2.0バージョンは、疑いを減らすために短い履歴を構築していました。

plain-crypto-js@4.2.1の内部で、Socketの分析は多段階ペイロードを発見しました。

  1. ステージ1 — 実行: このパッケージはインストール時（npmライフサイクルスクリプト経由）にコードを実行し、セカンダリペイロードをドロップします。
  2. ステージ2 — RATの展開: ペイロードは、永続的なバックドアを開くリモートアクセス型トロイの木馬をインストールします。
  3. ステージ3 — データ抜き取り: RATは、C2サーバーから送られた任意のシェルコマンドを実行し、ファイルシステムから環境変数や秘密情報を読み取り、システムデータをネットワーク経由で外部に送信することができます。

このRATは再起動後も永続化するため、侵害されたバージョンをインストールしたマシンは、npmパッケージを削除しても、RATが明示的に検出・削除されない限り、危険な状態が続きます。

影響を受けていますか？

以下の場合、影響を受けている可能性があります。

直ちに確認してください。

# インストールされているバージョンを確認
npm list axios

# ロックファイルを確認
grep '"axios"' package-lock.json | head -5

# plain-crypto-jsの存在を確認
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"

もしnode_modulesにplain-crypto-jsが存在する場合、悪意のあるバージョンを実行したことになります。

今すぐすべきこと

1. axiosを直ちにアップデートする

npm install axios@1.14.0
# または最新の安全なバージョンに固定
npm install axios@latest

確認する：

npm list axios
# 1.14.0またはそれ以上が表示されるはず（クリーンな1.14.xが公開された場合）

2. 侵害されたバージョンをインストールした場合

これを日常的な依存関係のアップデートとして扱わないでください。マシンが侵害されたものとして扱ってください。

3. CI/CDパイプラインを監査する

もしあなたのビルドパイプラインがその期間中にnpm installを実行した場合、CI環境が侵害された可能性があります。確認してください。

# 影響を受けた期間のビルドログを確認
# インストールの出力でaxios@1.14.1を探す

# 現在のCIのnode_modulesがクリーンであることを確認
npm list axios plain-crypto-js

CIパイプラインがアクセスできるすべての秘密情報（デプロイキー、クラウドプロバイダ認証情報、レジストリートークン）を変更してください。

4. ロックファイルを確認する

ロックファイル（package-lock.json、yarn.lock）は厳密なバージョンを固定するはずです。もしロックファイルに1.14.1がある場合、再生成してください。

# 削除して再生成
rm package-lock.json
npm install

コミットする前に、新しいロックファイルがaxiosを安全なバージョンに解決していることを確認してください。

Apidogを使用してaxiosのAPIコールを監査する

API呼び出しにaxiosをHTTPクライアントとして使用している場合、Apidogは依存関係のアップデート後も統合が正しいリクエストを送信しているかを確認するのに役立ちます。

axios@1.14.0にアップデートした後、既存のAPIエンドポイントをApidogにインポートし、迅速な回帰テストを実行して動作が変更されていないことを確認してください。これは、悪意のあるバージョンがリクエストやレスポンスのペイロードを改ざんしたのではないかと懸念している場合に特に役立ちます — Apidogのレスポンスアサーションを使用すると、正確なフィールド値、ヘッダー、ステータスコードを検証できます。

// Apidogのレスポンス後アサーション
pm.test("Response is clean — no injected fields", () => {
    const body = pm.response.json();
    pm.expect(body).to.not.have.property('__injected');
    pm.expect(pm.response.headers.get('X-Injected-Header')).to.be.null;
});

Apidogで更新されたaxiosバージョンに対して完全なテストスイートを実行することで、本番環境にプッシュする前に文書化されたクリーンなベースラインを得ることができます。

HTTPクライアントの回帰テストを設定するためにApidogを無料でお試しください。

npmにおけるサプライチェーン攻撃の阻止が困難な理由

axiosへの攻撃は異常なことではありません。これはパターンです。

共通の糸口は、コードではなく公開アカウントへの信頼です。npmのモデルはメンテナーに公開アクセス権を付与しており、メンテナーの認証情報が侵害されると、攻撃者がその信頼を引き継いでしまいます。

実際に役立つ対策：

対策 内容
ロックファイル（package-lock.json） 厳密なバージョンを固定し、サイレントアップデートを防ぐ
CIでのnpm audit デプロイ前に既知の脆弱性を検出する
Socket.dev / Snyk 振る舞い分析 — CVEが存在する前でも疑わしいパッケージを検出する
npmでの二要素認証 認証情報の侵害をより困難にする
有効期限の短いトークンによるnpm publish トークンが漏洩した場合の露出期間を制限する
PRでのロックファイルの確認 コードレビューで予期せぬ依存関係の変更を検出する

axiosチームはその後、長期有効なnpmトークンが問題の一部であったことを認め、より厳格な公開管理へと移行しています。しかし、この解決策は個々のパッケージだけでなく、エコシステム全体から生まれる必要があります。

侵害の痕跡（IOCs）

Socketの分析によると：

感染が疑われる場合は、security@npmjs.comのnpmセキュリティに報告し、ログを保存してください。

結論

axios 1.14.1の侵害は、依存関係のセキュリティが一度きりの監査ではなく、継続的なプロセスであることを再認識させます。バージョンを固定し、CIでSocketのような振る舞い分析ツールを実行し、疑わしい点があれば認証情報を変更し、コードレビューでロックファイルを常に確認してください。

axiosのアップデート後にAPI統合への信頼を再構築する必要がある場合、Apidogは出荷前にHTTPクライアントの動作を検証するためのテストシナリオ、アサーション、モックツールを提供します。

button

よくある質問

侵害されたaxiosのバージョンはどれですか？axios@1.14.1とaxios@0.30.4です。両方ともnpmから公開停止されています。安全なバージョンは1.14.0です（または1.13.x、1.12.xラインの任意のバージョン）。

悪意のあるaxiosペイロードは何をしますか？plain-crypto-js@4.2.1を引き込み、これがリモートアクセス型トロイの木馬（RAT）を含む多段階ペイロードを展開します。このRATは、リモートC2サーバーから任意のコマンドを実行し、環境変数や秘密情報を外部に流出し、再起動後も永続化することができます。

侵害されたバージョンをインストールしたかどうかを知るにはどうすればよいですか？npm list axiosを実行してください — もし1.14.1または0.30.4が表示された場合、影響を受けています。また、npm list plain-crypto-jsも確認してください — もしそのパッケージが存在する場合、悪意のあるコードがあなたのマシン上で実行されました。

axiosを更新するだけで十分ですか？いいえ。更新は今後の悪意のある依存関係を削除しますが、RATはすでにマシンにインストールされ永続化している可能性があります。侵害されたバージョンをインストールした場合は、すべての秘密情報を変更し、永続化メカニズムについてマシンを監査してください。

攻撃者はメンテナーでなくとも、どのようにnpmに公開できましたか？攻撃者は、メンテナーの認証情報を侵害し、公開アクセス権を持つ長期有効なnpmトークンを悪用した可能性が高いです。axiosチームは現在調査中で、公開管理を強化しています。

これと通常の脆弱性との違いは何ですか？脆弱性とは、正規のコードにおける欠陥です。サプライチェーン攻撃は、信頼された公開チャネルを通じて悪意のあるコードを導入します。侵害されたコードはaxiosのGitHubリポジトリには決して存在せず、npmの公開プロセスに直接注入されました。

将来のサプライチェーン攻撃からプロジェクトを保護するにはどうすればよいですか？ロックファイルを使用し、CIでnpm auditを実行し、振る舞い分析のためにSocket.devのようなツールを追加し、npmアカウントで2FAを有効にし、有効期限の短い公開トークンを使用し、コードレビューでロックファイルの差分を監査してください。

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる

無料会員登録ダウンロード