axios のサプライチェーン問題は「開発者だけの話」ではない！Web 担当者が今すぐ確認すべき 5 つのポイント 

こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、最新の Web セキュリティに関する内容を紹介し、企業のサイトを守るための考え方と実践方法をご紹介します。 

2026 年 3 月 31 日、JavaScript の HTTP クライアントとして広く使われている axios の npm パッケージで、悪意あるバージョンが公開されるサプライチェーン侵害が発生しました。公開されたのは axios@1.14.1 と axios@0.30.4 で、plain-crypto-js@4.2.1 という依存関係が差し込まれ、macOS / Windows / Linux 向けの RAT をインストールする動作が確認されています。 
※ Remote Access Trojan（遠隔操作型トロイの木馬）。攻撃者が感染端末をリモートで自由に操作できるマルウェアの一種。 

Axios の GitHub リポジトリ上でも、この問題についての事後分析が公開されています。 
Post Mortem: axios npm supply chain compromise #10636 

今回の件で怖いのは、Axios 本体のアプリケーションロジックが変わっていない点です。後述の Microsoft の分析でも、通常のアプリ挙動はそのままでも、npm install や npm update のタイミングで install-time のスクリプトが動き、開発端末や CI/CD 環境で悪性動作が起こり得ると説明されています。 

Axios npm サプライチェーンの侵害を軽減する: Mitigating the Axios npm supply chain compromise 

Web 担当者が今すぐ確認すべき 5 つのポイント 

この話は、一見すると「Node.js や npm を触る開発者（主にフロントエンド開発チーム）の問題」に見えますが、Web 担当者も当事者です。なぜなら、企業の Web サイト運用は、いまや CMS 本体だけでは完結しないからです。 

昨今の Web サイト運用は、制作、保守、計測タグ、フォーム、CDN、CI/CD、クラウド、SaaS 連携まで、いろいろな仕組みが繋がっています。1 つの依存関係の事故が、デプロイ基盤や各種トークン、場合によっては本番環境の更新権限にまで波及する可能性があります。 

「公開中のサイトに脆弱性があるか」だけではなく、どの依存関係を入れているか、誰の権限で publish / build / deploy しているか、CI にどのような secrets（API キーやパスワードなど）を渡しているかまで含めて、Web 運用基盤として管理する必要があります。 

1) まず「どこで axios を使っているか」を洗い出す 

自社開発の案件だけでなく、制作会社・運用会社に委託している案件、社内の運用ツール、過去のキャンペーンサイトまで含めて確認します。怖いのは脆弱性そのものより、「自社がどこでその依存関係を持っているかを把握・説明できないこと」です。まずは関係者に声をかけて、棚卸しの起点を作るところから始めます。 

2) 3 月 31 日前後に npm install / npm update / npm ci など依存解決を伴う処理が走っていないかを確認する 

今回の攻撃は、利用中のサイト画面ではなく、npm install や CI 実行時に発生します。CI/CD ログを見て、axios@1.14.1、axios@0.30.4、plain-crypto-js の痕跡がないかを確認します。該当時間帯にビルドやデプロイが走っていた案件は、念のため侵害されていないかを見直すのが安全です。 

また、可能であれば outbound 通信（外向きの通信）も確認しておくと良いでしょう。「悪意ある依存関係がマルウェアをインストールするために外部と通信を行っていた」というような情報を得ることができ、今後の対策につながります。 

3) lockfile とキャッシュを点検する 

Google は lockfile 内の plain-crypto-js を確認し、npm / yarn / pnpm のキャッシュもクリアすべきと案内しています。安全版へ戻したつもりでも、キャッシュ経由で再混入する可能性があるためです。 

私自身、開発をしている最中に「あれ、パッケージ更新したはずなのに変わっていないな」という時には過去の node_modules にキャッシュが残っていたということもよくあります。 

package-lock.json や yarn.lock を grep（検索）するなど、痕跡が残っていないかをチームで確認しておくと安心です

4) 影響端末の secrets を軽く見ない 

該当端末や runner に API キー、SSH キー、クラウド認証情報、.env が載っていたなら、侵害されている可能性があります。npm token、GitHub token、クラウドのアクセスキーなど、まず止められるものから順にローテーションしていくと良いでしょう。 

5) 今後の再発防止を「開発者任せ」にしない 

ミスは誰しもしてしまうものです。パッケージの ^ や ~ による自動追随を見直し、必要な依存は exact version で固定することや、ルールを仕組みとして整備することが重要です。 

「依存関係の更新ルールを誰が決めるのか」「緊急時に secrets を誰が止めるのか」「委託先や制作会社が触る領域をどう分けるのか」などを決めておくと、発生防止にも繋がりますし、万が一問題が発生してしまった際の対応も速くなります。 

まとめ 

今回の axios 事案で本当に怖いのは、有名ライブラリが狙われたことだけではありません。Web 担当者の立場で見ると、自社の Web サイト運用がどれだけ多数の依存関係と外部委託、ビルド環境、秘密情報の上に成り立っているかが、改めて露呈した事故だったと思います。 

だからこそ必要なのは、その場しのぎではなく、Web 資産・運用フロー・委託先管理・デプロイ経路まで含めた見える化です。「脆弱性を探して塞ぐ」だけでなく、「依存関係をどう取り込み、どう更新し、問題が起きたときにどう止めるか」を運用の設計として持っておく、ということです。 

GMOプライム・ストラテジーでは、こうした運用の標準化や継続的なセキュリティ対応を支援するサービスを提供しています。ぜひご活用いただき、運用の見直しのきっかけにしてみてください。 

• CMS プラットフォーム統合サービス（増え続ける CMS 環境を共通ルールのもとで高速かつ安全に運用するためのサービス） 

• KUSANAGI マネージドサービス（保守運用・障害対応・セキュリティ対策まで含めた継続支援） 

• Security Advisory for WordPress（WordPress テーマ・プラグインの脆弱性情報ダイジェストを無料で購読） 

• Web ガバナンスガイドライン（企業が Web ガバナンスにおいて気を付けるべきポイントを無料でダウンロード）