Axios改ざん事件を整理する

はじめに

2026年3月31日、JavaScriptのHTTPクライアントとして広く使われているAxiosのnpm配布物に、悪意ある依存関係が一時的に混入した。

対象は axios@1.14.1 と axios@0.30.4 で、公開されていた時間は約3時間と短い。しかし、npm install 時点でマルウェアが動作するタイプだったため、もし該当バージョンを取得していた場合は「端末やCI環境の侵害」として扱う必要がある。

本記事では、何が起きたのか、どういう経緯で混入したのか、今感染していないかを確認するために何をすべきか、今後同様の事故に巻き込まれにくくするには何を行うべきかを整理する。

何が起きたのか

今回の問題は、Axios本体のHTTP通信ロジックに脆弱性が見つかった、という話ではない。

公式ポストモーテムによると、2026年3月31日にメンテナーの侵害されたアカウントを通じて axios@1.14.1 と axios@0.30.4 がnpmへ公開され、その2つの版には plain-crypto-js@4.2.1 という悪意ある依存関係が追加されていた。

この依存関係は、インストール時に postinstall フックを通じて動作し、macOS・Windows・Linux向けにそれぞれ別のRATを取得して実行する仕組みだったと報告されている。つまり、アプリ実行時ではなく、依存関係を入れた瞬間に侵害が始まる構成だった。

重要なのは、Axiosのソースコード本体が改ざんされたのではなく、配布パッケージの依存関係定義が悪用された点である。ソースレビューだけでは見落としうるタイプの事故であり、ソフトウェアサプライチェーン攻撃として扱うべき事案である。

どういう問題が起きたのか

問題の本質は次の通りである。

• 悪意ある版のAxiosを npm install すると、依存先の plain-crypto-js@4.2.1 も一緒に取得される
• その依存パッケージに仕込まれた postinstall スクリプトが自動実行される
• スクリプトが外部サーバー sfrclak[.]com:8000 に接続し、OS別の追加ペイロードを取得する
• 端末上でRATが起動し、攻撃者による遠隔操作や情報窃取の足掛かりになる
• 実行後は痕跡を隠すため、自身の設定ファイルを差し替えるなど、見つかりにくくする動きもあった

そのため、影響を受けた環境では「Axiosを安全な版に戻せば終わり」では済まない。すでに認証情報や端末自体が抜かれている前提で対処する必要がある。

どういう経緯で混入したのか

Axios公式の説明では、攻撃者は標的型のソーシャルエンジニアリングとRATを使ってリードメンテナーのPCへ侵入し、その結果得たnpm公開権限を用いて悪意ある版を公開したとされている。

時系列としては、概ね次の流れである。

1. 2026年3月中旬ごろから、メンテナーに対する標的型のソーシャルエンジニアリングが始まる
2. 2026年3月30日、攻撃用の依存パッケージ plain-crypto-js がnpmに用意される
3. 2026年3月31日 00:21 UTC に axios@1.14.1 が公開される
4. 同日 01:00 UTC ごろに axios@0.30.4 も同様の内容で公開される
5. 外部研究者やコミュニティが異常に気づき、報告と対応が進む
6. 同日 03:15 UTC に悪意あるAxios版が削除される
7. 同日 03:29 UTC に plain-crypto-js も削除される

ここで押さえておきたいのは、通常のリリースフローに沿った正常な更新に見せかけて、配布物だけが汚染された点である。利用者側から見ると「いつもの依存更新」にしか見えないため、ロックファイルやCI運用が甘いとかなり踏みやすい。

今感染していないか確認するために行うこと

1. ロックファイルで該当バージョンを確認する

まずは package-lock.json や yarn.lock などに、問題の版が含まれていないか確認する。

grep -E 'axios@(1\.14\.1|0\.30\.4)|plain-crypto-js' package-lock.json yarn.lock 2>/dev/null

npm系の依存関係で確認するなら、次のような見方も有効である。

npm ls axios
npm ls plain-crypto-js

もし axios@1.14.1、axios@0.30.4、plain-crypto-js のいずれかが出てくるなら、影響調査対象として扱う。

2. インストールした時刻を確認する

公式には、問題の版が配布されていた時間帯は2026年3月31日 00:21 UTC から 03:15 UTC 前後までとされている。日本時間では2026年3月31日 09:21 から 12:15ごろである。

この時間帯に、ローカル環境やCIで npm install、npm update、依存更新ジョブが走っていなかったかを確認する。ロックファイルが安全な版で固定されていたなら影響は受けにくいが、固定していない自動更新ジョブは特に危ない。

3. 端末やCIに痕跡がないか確認する

公開情報ベースでは、主に次のIOCが挙がっている。

• ネットワーク接続先: sfrclak[.]com または 142.11.206.73:8000
• macOS: /Library/Caches/com.apple.act.mond
• Windows: %PROGRAMDATA%\\wt.exe
• Linux: /tmp/ld.py

端末のプロセス、EDR、FW、Proxy、DNSログ、CIランナーの通信ログにこれらの痕跡がないかを見る。

4. 該当したら「端末侵害」として扱う

Axios公式は、該当したマシンを侵害済みとして扱うよう案内している。つまり、単に依存関係を消すだけでなく、少なくとも以下を実施するべきである。

• 安全な版へ戻す
• node_modules/plain-crypto-js/ を除去する
• その端末で使ったシークレット、トークン、認証情報をローテーションする
• CIランナーなら、そのジョブに注入した環境変数やクラウド認証情報も全交換する
• 必要に応じて端末の再イメージ化やクリーンビルドを行う

RAT系は「入ったかもしれない」で終わらせると後で被害が広がる。曖昧な場合でも、保守的に侵害前提で動くほうが安全である。

今後感染しないように行うこと

ロックファイルを必ずコミットし、CIでは npm ci を優先する

今回のような事故では、ロックファイルが古い安全版を固定していれば踏まない可能性が高い。開発端末でもCIでも、npm install を漫然と叩くより、ロックファイルに従う npm ci を基本にしたほうがよい。

依存更新を自動実行する時間帯と対象を見直す

夜間バッチや定期ビルドで自動的に npm install を回している構成は、汚染版を取り込みやすい。依存更新は、PRベースで差分確認できる形に寄せるほうが安全である。

パッケージ追加時に「新しい依存」が増えていないか確認する

今回の混入は、Axios本体ではなく依存の増加が入口だった。メジャー更新でなくても、依存パッケージが急に増えていないか、インストールフックが付いていないかを確認する習慣が有効である。

インストールフックを監視する

postinstall は便利だが、攻撃面でもある。組織としては、依存関係スキャン、SBOM、Allowlist/Blocklist、インストールスクリプト監視などを組み合わせ、未知の postinstall 実行を検知できるようにしたい。

.npmrc でインストール時のリスクを下げる

今回のように postinstall が悪用される事案では、.npmrc の設定で被害の起点を減らせる。特にCIや本番ビルド環境では、次のような設定を検討しやすい。

ignore-scripts=true
fund=false
audit=true
save-exact=true

この中で特に重要なのは ignore-scripts=true である。これを有効にすると postinstall、preinstall、prepare などのライフサイクルスクリプトが自動実行されなくなるため、今回のような「インストールした瞬間に発火する」攻撃への耐性が上がる。

ただし、副作用もある。ネイティブモジュールのビルドや、正当なセットアップ処理まで止まるため、すべての開発環境で常時有効にできるとは限らない。そのため、まずはCI、依存更新ジョブ、検証用ランナーなど、不要なスクリプト実行を止めやすい場所から適用するのが現実的である。

例えば、CI専用の .npmrc では次のような方針が取りやすい。

• CIでは ignore-scripts=true を基本にする
• どうしても必要なジョブだけ、明示的に npm rebuild や許可済みコマンドで後段実行する
• npm ci と組み合わせて、ロックファイルに固定された依存だけを再現する

また、save-exact=true は新規導入時に曖昧なバージョン範囲を避けやすくし、意図しない版の取り込みを減らす助けになる。これだけでサプライチェーン攻撃を防げるわけではないが、「いつの間にか別版を拾う」事故を抑えやすい。

.npmrc は万能な防御ではないが、ロックファイル運用や npm ci と合わせることで、少なくとも「インストールフックが無条件で走る」状態を減らせる。今回のような事案では、かなり実務的な防御策になる。

開発端末と公開権限の分離を進める

Axios側も再発防止策として、個人端末依存の公開から、OIDCやimmutableなリリースフローへ寄せると説明している。これは利用側にも参考になる。個人端末に強い権限を集中させず、公開・署名・配布の経路を自動化して分離したほうがよい。

シークレットを長寿命にしない

もし開発端末やCIが侵害されても、短命トークンや最小権限設計になっていれば被害は縮む。クラウド鍵、npm token、GitHub token、各種APIキーは、定期ローテーションと最小権限を前提に運用したい。

まとめ

今回のAxios事案は、公開経路と依存関係を悪用したサプライチェーン攻撃だった。

影響があるのは主に axios@1.14.1 と axios@0.30.4 を取得した環境であり、該当する場合は「依存を戻す」だけでは不十分である。端末侵害、認証情報流出、CIシークレット漏えいまで含めて確認する必要がある。

まずはロックファイル、インストール時刻、IOC、CIの実行履歴を確認し、怪しい場合は保守的に隔離と資格情報ローテーションを進めるのがよい。今後に向けては、ロックファイルの厳格運用、npm ci の利用、インストールフック監視、公開権限の分離が実践的な防御になる。

参考情報

• External Link Axios公式ポストモーテム

  Post Mortem: axios npm supply chain compromise Date: March 31, 2026 Author: Jason Saayman Status: Remediation in progress On March 31, 2026, two malicious versions of axios (1.14.1 and 0.30.4) were...

  GitHub

  
• External Link JFrogの技術分析

  The JFrog security research team recently identified a supply chain attack targeting the `axios` npm package. If you installed `axios@1.14.1`, or `axios@0.30.4` you must assume your environment is compromised.

  research.jfrog.com
• External Link Snykの解説と確認手順

  Meta description: Malicious versions of the Axios npm package (1.14.1 and 0.30.4) were published via a compromised maintainer account, injecting a hidden dependency that deploys a cross-platform remote access trojan. Here's what happened, who's affected, and how to check your exposure.

  Snyk