axiosにマルウェア混入｜サプライチェーン攻撃の全容と感染確認・安全な対処法

2026年3月31日、週1億回以上ダウンロードされるnpmの定番HTTPクライアント「axios」のメンテナアカウントが乗っ取られ、マルウェアを仕込んだ不正バージョン（1.14.1と0.30.4）が公開されました。npm installするだけでクロスプラットフォーム型のRAT（リモートアクセス型トロイの木馬）が起動する仕組みで、直接axiosを使っていないプロジェクトも間接依存経由で影響を受け得ます。本記事では、何が起きたのかの全容に加え、自分の環境が感染していないかの確認手順（npm ls axios）、安全なバージョンへの対処、そして再発を防ぐ設定までを、開発者がすぐ動ける形で整理します。なお最新の安全版バージョンは公式（npm/GitHub）で必ずご確認ください。

まとめ：axiosマルウェア混入インシデントの要点（結論先出し）

• 何が起きたか：2026年3月31日、axiosのメンテナ（jasonsaayman）のnpmアカウントが侵害され、不正版1.14.1・0.30.4が公開。ファントム依存[email protected]のpostinstallでRAT「WAVESHAPER.V2」が起動した。
• 公開時間：悪性版がnpm上にあったのは約2〜3時間と短いが、CI/CDは24時間稼働するため、その間にnpm installした環境は要確認。
• 攻撃者：Googleの脅威分析チーム（GTIG）は北朝鮮系の金銭目的アクターUNC1069に帰属判定。
• 感染確認：まずnpm ls axiosで直接・間接依存の両方を確認。1.14.1または0.30.4が出れば侵害の疑い。RATは自己消去するため、OS別の設置パスとC2ドメインsfrclak[.]comへの通信ログも併せて確認する。
• 対処：感染端末はネットワークから即時隔離→axiosを安全なバージョン（1.x系は1.15.0以降、0.x系は0.31.0以降）へ更新→API・クラウド・SSHなど全認証情報をローテーション。最新の安全版は公式で確認。
• 再発防止：.npmrcにmin-release-age=7・ignore-scripts=trueを設定し、CIはnpm ciへ。Dependabot側もcooldownで自動更新PRを7日遅延させる。

以下では、攻撃の全容と技術的手口、感染有無の判別手順、インシデント対応、npm/CI-CDの防御設定、SBOM・SCA体制までを順に詳しく解説します。

週1億DLのaxiosを襲ったサプライチェーン攻撃の全容と開発者が直面したリスク

2026年3月31日、JavaScriptエコシステムにおいて最も広く利用されているHTTPクライアントライブラリ「axios」が、サプライチェーン攻撃の標的となりました。axiosは週間1億回以上のnpmダウンロードを記録する基幹的パッケージであり、フロントエンドからバックエンドまであらゆる開発現場で日常的に使用されています。今回の攻撃では、メンテナのnpmアカウントが乗っ取られ、クロスプラットフォーム対応のリモートアクセス型トロイの木馬（RAT）が仕込まれた不正バージョンが公開されました。本章では、事件の全容を時系列で整理し、開発者が認識すべきリスクの範囲を明らかにします。

週間1億DL超のaxiosが標的になった背景と攻撃者が狙った影響範囲の大きさ

axiosがサプライチェーン攻撃の標的として選ばれた最大の理由は、その圧倒的な普及率にあります。npmレジストリにおける週間ダウンロード数は1億回を超え、約17万5,000件のnpmプロジェクトが直接的な依存関係としてaxiosを宣言しています。さらに重要なのは、axiosを間接的に利用しているプロジェクトの数がこの何倍にも上る点です。あるライブラリが内部でaxiosに依存していれば、そのライブラリを使うプロジェクトも自動的に影響を受けます。

攻撃者の視点で考えると、1つのパッケージを侵害するだけで、世界中の開発者のPC、CI/CDパイプライン、本番サーバーにマルウェアを到達させることができます。これはソフトウェアサプライチェーン攻撃における「レバレッジ効果」の典型例です。特にaxiosは、企業のプロダクション環境だけでなく、個人の学習用プロジェクトや社内ツールにも広く使われているため、セキュリティ意識の高低を問わず、あらゆる開発者が潜在的な被害者になり得ました。攻撃者はこの波及効果を十分に理解した上で、axiosを戦略的に選定したとみられており、標的選定の合理性がうかがえる事例でした。

2026年3月30日から31日にかけて発生した攻撃タイムラインの時系列整理

今回の攻撃は、周到な事前準備のもとで実行されました。まず2026年3月30日14時57分（日本時間）、攻撃者は「[email protected]」というアカウントを使い、[email protected]をnpmに公開しています。このバージョンは正規のcrypto-jsソースの完全なコピーであり、それ自体に悪意あるコードは含まれていませんでした。目的は、公開実績をゼロから作り、後続の悪性バージョンが「新規パッケージ」として警告されることを回避するためです。

その約18時間後の3月31日午前8時59分（日本時間）に、ペイロードを含む[email protected]が公開されました。続いて午前9時21分にはaxiosの侵害済みアカウントから[email protected]が、午前10時00分には[email protected]が立て続けに公開されています。1.x系とレガシーの0.x系の両方のリリースブランチが狙われたことで、どちらのバージョン系列を使っていても被害を受ける状態が生まれました。この2つの不正バージョンは、わずか39分の間に公開されており、攻撃の自動化や事前のリハーサルが行われていた可能性を示唆しています。

悪意あるバージョン1.14.1と0.30.4が公開からわずか数時間で削除された経緯

不正バージョンの公開後、npmエコシステムの自動セキュリティスキャナーが数分以内に異常を検知しました。[email protected]は公開直後に複数のスキャナーによって既知のマルウェアとして判定され、サプライチェーンセキュリティスコアは0%と評価されています。同様に[email protected]も検出対象となり、npmの管理チームによって非公開化（unpublish）の措置が取られました。

悪性バージョンがnpm上で利用可能だった時間は、おおよそ2〜3時間と推定されています。日本時間に換算すると、3月31日の午前9時21分から12時15分頃までの間にあたります。一見すると短時間のように思えますが、自動ビルドシステムやCI/CDパイプラインは時間帯を問わず動作しているため、この数時間の間に世界中で多数のnpm installが実行された可能性があります。特に、キャレット記法（^1.12.0など）でバージョンを指定していたプロジェクトでは、意図せず最新の悪性バージョンがインストールされるリスクがありました。

政府・金融・医療を含む複数業界に影響が及んだ被害範囲の実態と深刻度

トレンドマイクロが2026年3月31日時点で公開したテレメトリデータによると、今回の攻撃に関連する活動は複数の業界に影響を及ぼしていることが確認されています。対象には政府機関、金融サービス、小売、コンサルティング、エンターテインメント、製造業、テクノロジー企業、医療機関、公共事業が含まれます。この業界横断的な影響は、axiosがあらゆる分野のWebアプリケーションで使われていることを裏付けています。

被害の深刻度を押し上げている要因は、マルウェアが単なる情報窃取にとどまらず、フル機能のRAT（リモートアクセス型トロイの木馬）を展開する点にあります。感染端末からはシステム情報、認証情報、ファイルシステムの内容が攻撃者のC2サーバーに送信される可能性があり、さらに任意のコマンド実行も可能です。とりわけCI/CDパイプライン上で感染が発生した場合、パイプラインに注入されたシークレット（APIキー、クラウド認証情報、デプロイトークンなど）が一括で漏洩するリスクがあります。被害組織にとって、影響範囲の特定と封じ込めには相当の工数が必要となります。

北朝鮮系脅威アクターUNC1069の関与をGoogleが指摘した根拠と過去の攻撃実績

Google Threat Intelligence Group（GTIG）は2026年3月31日に詳細な脅威分析レポートを公開し、今回のaxiosサプライチェーン攻撃が北朝鮮を拠点とする金銭目的の脅威アクター「UNC1069」によるものと評価しました。この帰属判定の根拠として、GTIGは攻撃に使用されたバックドア「WAVESHAPER.V2」が、過去にUNC1069が使用した「WAVESHAPER」の更新版であることを挙げています。また、攻撃インフラのアーティファクト分析から、UNC1069の過去の活動で使用されたインフラとの重複も判明しました。

UNC1069は少なくとも2018年から活動が確認されている金銭目的のグループであり、過去には暗号資産関連の攻撃に多く関与してきました。GTIGのチーフアナリストは、北朝鮮のハッカーがサプライチェーン攻撃における豊富な経験を有していると指摘しており、こうした攻撃手法が従来の暗号資産窃取から、より広範なソフトウェアサプライチェーンの侵害へと拡大している傾向がうかがえます。国家支援型の攻撃者が、オープンソースエコシステムの信頼構造を標的にしているという事実は、個々の開発者レベルの対策だけでは不十分であることを示しています。

npmアカウント乗っ取りからRAT配布まで39分で完了した攻撃の技術的手口

今回のaxiosサプライチェーン攻撃は、コードの脆弱性やCVEを突いたものではありません。信頼された公開経路そのものが武器にされた事件です。攻撃者はメンテナのアカウントを侵害し、npmの依存関係解決メカニズムを悪用して、開発者がnpm installを実行するだけでマルウェアが自動起動する仕組みを構築しました。この章では、攻撃の技術的な手口を段階ごとに詳しく解説します。

メンテナjasonsaaymanのnpmアカウントが侵害されGitHub Actionsを迂回した手法

攻撃者が最初に侵害したのは、axiosプロジェクトのリードメンテナであるjasonsaaymanのnpmアカウントです。このアカウントはaxiosの新バージョンをnpmに公開する権限を持っていました。侵害の過程で、アカウントに登録されていたメールアドレスが攻撃者の管理する「[email protected]」というProtonMailアドレスに変更されています。この変更により、正規のメンテナがアカウント復旧を試みる際の障壁が高まりました。

通常、axiosの正規リリースはGitHub ActionsのOIDC Trusted Publisherという仕組みを通じて公開されます。これはGitHubリポジトリとnpmアカウントを安全に連携させ、CI/CDパイプラインからの自動公開を実現する機能です。しかし攻撃者は、この自動化された公開フローを完全に迂回し、盗んだnpmトークンを使用してnpm CLIから直接不正バージョンを手動で公開しました。その結果、公式のGitHubリポジトリにはコミット履歴やプルリクエストなどの痕跡が一切残りませんでした。この手法は、リポジトリの監視だけではサプライチェーン攻撃を防げないことを端的に示しています。

plain-crypto-jsというファントム依存関係を18時間前に仕込んだ事前準備の巧妙さ

今回の攻撃で使用された中核的な手法が「ファントム依存関係攻撃」です。不正なaxiosバージョンにおける唯一のコード変更は、package.jsonにplain-crypto-js@^4.2.1という依存関係が1行追加されたことでした。このパッケージはaxiosのソースコード内のどこからもimportやrequire()されておらず、全86ファイルを対象にgrep検索を行っても使用箇所は確認されていません。

この依存関係が存在する目的はただ一つ、npmの自動依存関係解決を発動させ、plain-crypto-jsのpostinstallフックを実行させることです。攻撃者は悪性パッケージの公開に先立ち、18時間前にまず無害なバージョン（4.2.0）を公開して公開実績を作っています。npmでは公開履歴がゼロのパッケージに対して警告が表示される場合があるため、この手順で検出回避を図ったと考えられています。パッケージ名も正規の暗号化ライブラリ「crypto-js」に酷似させ、説明文やリポジトリURLまで本物と同一に偽装するという徹底ぶりでした。

postinstallフックを悪用しnpm installだけでRATが自動起動する感染メカニズム

npmパッケージにはpreinstall、install、postinstallといったライフサイクルスクリプトを設定する機能があり、パッケージのインストール時に自動でコードを実行できます。今回の攻撃では、[email protected]のpostinstallスクリプトとしてsetup.jsが指定されていました。開発者がnpm installを実行するだけで、依存関係の解決過程でこのスクリプトが自動的に起動する仕組みです。

setup.jsは高度に難読化されており、実行時にまずOSを判別します。その後、ハードコードされたC2（コマンド＆コントロール）サーバーに接続し、macOS・Windows・Linuxそれぞれに対応したペイロードをダウンロードして展開します。重要な点として、axiosを直接利用していないプロジェクトでも影響を受ける可能性があります。他のライブラリが間接的にaxiosに依存していれば、postinstallフックはトランジティブ依存（間接依存）に対しても発火するためです。npm ls axiosコマンドで依存ツリーを確認しなければ、自分のプロジェクトにaxiosが含まれていること自体に気づかないケースも十分にあり得ます。

macOS・Windows・Linuxの3プラットフォームに対応したペイロードの実行と自己消去

攻撃者はmacOS、Windows、Linuxの3つのOSに対応したペイロードを事前に構築していました。macOS向けにはMach-Oバイナリ、Windows向けにはPowerShellベースのスクリプト、Linux向けにはPythonスクリプトがそれぞれ用意されています。C2サーバーからダウンロードされたペイロードは、各プラットフォーム固有のパスに配置されました。

このマルウェアには高度なアンチフォレンジック機能が組み込まれています。ペイロードの展開が完了すると、ドロッパーは自身の痕跡を完全に消去し、package.jsonをクリーンなバージョンのものに置き換えます。つまり、感染後にnode_modulesディレクトリを事後的に検査しても、悪意あるコードの痕跡は見つかりません。この自己消去メカニズムにより、従来のファイルベースの検知手法では感染を発見することが極めて困難になっています。RATだけがバックグラウンドで動作し続けるという設計は、攻撃者が長期的な潜伏を意図していたことを示唆しています。

WAVESHAPER.V2が備えるシステム偵察・コマンド実行・ファイル列挙の3大機能

展開されるバックドア「WAVESHAPER.V2」は、プラットフォームごとに異なる言語で実装されたフル機能のRATです。macOS向けはC++、Windows向けはPowerShell、Linux向けはPythonで記述されており、GTIGの分析によれば主に3つの中核機能を備えています。第一にシステム偵察機能では、ホスト名、ユーザー名、ブート時刻、タイムゾーン、OSバージョン、実行中のプロセス一覧といったシステムテレメトリを詳細に抽出します。この情報は攻撃者が標的の価値を判断し、次のアクションを決定するための基礎データとなります。

第二のコマンド実行機能は、複数の実行手法をサポートしています。メモリ内でのPortable Executable（PE）インジェクションや任意のシェルコマンド実行が可能であり、C2サーバーからスクリプトとパラメータを受け取って実行します。スクリプトが提供されない場合はパラメータがPowerShellコマンドとして直接実行され、スクリプトが提供された場合はサイズに応じてBase64エンコードまたはファイル書き出しが行われます。第三のファイルシステム列挙機能では、指定されたディレクトリを再帰的にスキャンし、詳細なメタデータを返却します。この3つの機能を組み合わせることで、攻撃者は感染端末を完全に遠隔操作できる状態を確立します。開発者のPCだけでなく、CI/CDサーバーや本番環境が感染した場合、組織のインフラ全体が攻撃者の支配下に置かれかねません。

自社プロジェクトが感染しているか即座に判別するための確認手順とIOC一覧

axiosの悪性バージョンが公開されていた時間帯は限定的でしたが、その間にCI/CDパイプラインや開発端末でnpm installが実行されていた可能性は否定できません。さらに、マルウェアは感染後に自己消去する設計となっているため、通常のファイル検査だけでは見落とすリスクがあります。ここでは、自社プロジェクトが影響を受けたかどうかを正確に判別するための手順を、確認すべき順序に沿って解説します。

npm ls axiosコマンドで直接依存・間接依存の両方を洗い出す最初の確認ステップ

最初に実施すべき確認は、自分のプロジェクトにaxiosが含まれているかどうかの把握です。axiosを直接利用していないプロジェクトでも、他のライブラリがトランジティブ依存（間接依存）としてaxiosを内部で使用しているケースは珍しくありません。この確認にはnpm ls axiosコマンドが最も効果的です。

プロジェクトのルートディレクトリでこのコマンドを実行すると、依存ツリー内にaxiosが存在するかどうか、そしてどのバージョンがインストールされているかが表示されます。出力にaxiosが含まれていなければ、そのプロジェクトは影響を受けていないと判断できます。一方、1.14.1または0.30.4というバージョンが表示された場合は、侵害された可能性が高いため、後続の詳細確認が必要になります。なお、複数のプロジェクトを管理している場合は、すべてのリポジトリに対してこの確認を実施してください。モノレポ構成の場合はワークスペースごとに個別の依存ツリーが存在するため、各ワークスペースで個別に確認してください。

package-lock.jsonとnode_modulesから該当バージョンを特定する具体的な検索方法

npm lsコマンドに加えて、package-lock.jsonファイルの内容を直接検索する方法も有効です。lockfileにはインストール済みの全パッケージの正確なバージョンが記録されているため、以下のコマンドで該当バージョンの存在を確認できます。

grep -n "axios" package-lock.json | grep -E "1\.14\.1|0\.30\.4"

このコマンドで何も出力されなければ、lockfileには悪性バージョンが記録されていないことを意味します。ただし、lockfileの確認だけでは不十分な場合があります。lockfileが更新されていない、あるいはコミットされていない環境では、実際にインストールされたバージョンと乖離している可能性があるためです。node_modulesディレクトリ内の実ファイルも併せて確認することを推奨します。node_modules/axios/package.jsonを開き、versionフィールドとdependenciesフィールドを目視で確認してください。plain-crypto-jsという依存関係が記載されていれば、確実に侵害されたバージョンです。

OS別RATファイルの設置パスを確認して感染有無を判定する3つのチェックポイント

悪性バージョンをインストールした場合、プラットフォーム固有のRATファイルがシステム上に配置されている可能性があります。各OSにおいて確認すべきファイルパスは以下の通りです。macOSでは/Library/Caches/com.apple.act.mond、Windowsでは%PROGRAMDATA%\wt.exe、Linuxでは/tmp/ld.pyが該当します。

macOSの場合はターミナルでls -la /Library/Caches/com.apple.act.mondを実行し、ファイルの存在を確認します。このパスはAppleのシステムキャッシュに偽装されており、一見すると正規のシステムファイルのように見えるため注意が必要です。Windowsではdir %PROGRAMDATA%\wt.exeで確認できます。ファイル名「wt.exe」はWindows Terminalの実行ファイルに類似させた命名であり、プロセス一覧で見逃されやすい設計になっています。Linuxではls -la /tmp/ld.pyで確認しますが、/tmpディレクトリは再起動時にクリアされる環境もあるため、再起動後の検査では痕跡が消えている場合があります。これらのファイルが1つでも検出された場合は、その端末が侵害されたものとして即座にインシデント対応を開始してください。

C2ドメインsfrclak.comへの通信ログを確認し外部送信の有無を検証する手順

RATファイルの有無に加えて、ネットワーク通信ログの確認も重要な検証手段です。今回の攻撃で使用されたC2（コマンド＆コントロール）ドメインはsfrclak[.]comであることが判明しています。ファイアウォールやプロキシサーバーのログ、DNSクエリログを遡って、このドメインへの通信が発生していないかを調査してください。

企業環境であれば、SIEMツールやEDR製品のログから該当ドメインへの接続試行を検索することで、感染端末を特定できます。個人の開発環境の場合は、macOSではConsoleアプリやネットワークモニタ、Linuxではjournalctlやiptablesのログ、Windowsではイベントビューアのネットワーク関連ログが確認対象となります。通信が確認された場合、その端末からはシステム情報、認証情報、ファイルシステムの内容が攻撃者に送信されている可能性が高いと考えてください。また、C2ドメインへのエグレストラフィックをファイアウォールやDNSフィルタリングで即座にブロックすることも、被害拡大防止のために実施すべき初動対応の一つです。

痕跡を自己消去するplain-crypto-jsをnode_modules検査だけで見逃す失敗パターン

今回の攻撃で最も見落としやすいポイントは、マルウェアの自己消去機能です。plain-crypto-jsのドロッパーは、RATの展開が完了するとnpm関連の痕跡を消去し、package.jsonをクリーンなバージョンのものに置き換える仕組みを備えています。そのため、感染後にnode_modulesディレクトリを調べても、悪意あるファイルはすでに存在しない状態になっています。

この特性が意味するのは、「node_modulesを検査して問題が見つからなかったから安全」という判断は誤りだということです。感染の有無を正確に判定するには、実際のnpm installが実行された時刻と攻撃のタイムライン（日本時間3月31日9時21分〜12時15分頃）を照合する方法が必要になります。CI/CDパイプラインであれば実行ログからインストール時刻を特定できますが、ローカル開発環境ではシェル履歴やファイルシステムのタイムスタンプを手がかりにするしかありません。先述のOS別RATファイルの確認やC2通信ログの調査と組み合わせて、多角的に感染有無を検証してください。

感染が確認された環境で最優先すべきインシデント対応とクレデンシャル失効処理

悪性バージョンのインストールが確認された、もしくは否定しきれない場合は、すでにバックドアが設置され外部と通信している前提で行動することが求められます。RATがバックグラウンドで稼働している環境では、あらゆるデータの漏洩と追加攻撃の継続を疑わなければなりません。この章では、インシデント確認後の初動対応から、クレデンシャルの優先的なローテーション、そして再発防止までの対応手順を体系的に整理します。

感染端末のネットワーク即時隔離とaxios安全バージョンへのダウングレード手順

感染が確認された端末に対して最初に実施すべきアクションは、ネットワークからの即時隔離です。LANケーブルの抜去やWi-Fiの切断により、C2サーバーとの通信経路を物理的に遮断します。RATが稼働中であれば、ネットワークに接続されている限り攻撃者が遠隔操作を継続できるため、隔離の速度がその後の被害範囲を左右します。

ネットワーク隔離の後、axiosを安全なバージョンにダウングレードします。1.x系を使用している場合はnpm install [email protected]を、レガシーの0.x系を使用している場合はnpm install [email protected]を実行してください。併せて、node_modules/plain-crypto-jsディレクトリが残存していれば手動で削除します。ダウングレード後はlockfileが正しく更新されていることを確認し、package-lock.jsonをリポジトリにコミットしてください。なお、感染端末上でのダウングレード作業はあくまで応急措置であり、端末自体のクリーンインストールやフォレンジック調査が完了するまではプロダクション用途での使用を再開すべきではありません。

APIキー・AWSクレデンシャル・SSHキーなど全認証情報のローテーション優先順位

感染が確認された端末や、感染を否定しきれない端末に保存されていたすべての認証情報は、漏洩している前提でローテーション（無効化と再発行）を行う必要があります。特に優先度の高い対象として、npmトークン、クラウドサービスの認証情報（AWS、GCP、Azureのアクセスキーやサービスアカウントキー）、SSHキー、GitHubの個人アクセストークン（PAT）が挙げられます。

ローテーションの優先順位を判断する際は、漏洩した場合のビジネスインパクトの大きさを基準にしてください。本番環境のデータベース接続情報やデプロイ用のシークレットキーは最優先で対応すべき対象です。環境変数や.envファイルに格納されていた認証情報だけでなく、ブラウザに保存されたセッション情報やパスワードマネージャーのマスターパスワードも対象に含めるべきケースがあります。WAVESHAPER.V2はファイルシステムの列挙機能を備えているため、端末上のあらゆるファイルが読み取られた可能性を想定してください。ローテーション完了後は、各サービスのアクセスログを確認し、不正な認証や異常なAPI呼び出しが発生していないかを検証することが重要です。

CI/CDパイプラインで悪性バージョンが実行された場合のシークレット漏洩範囲の特定

ローカル開発環境だけでなく、CI/CDパイプラインでの感染はさらに深刻な影響をもたらします。GitHub ActionsやGitLab CI、Jenkins等のパイプラインでnpm installが実行されていた場合、パイプラインに注入されていたすべてのシークレットが漏洩している可能性を考慮しなければなりません。CI/CDのシークレットには、デプロイ先のクラウド認証情報、コンテナレジストリのアクセストークン、通知系サービスのAPIキーなどが含まれるケースがほとんどでしょう。

被害範囲を特定するためには、まず該当時間帯（UTC 3月31日00:21〜03:20頃）にパイプラインが実行されたかどうかをCI/CDの実行ログから確認します。該当する実行が存在した場合は、そのジョブで利用されていたシークレットの一覧を洗い出し、すべてをローテーションしてください。さらに、パイプラインのビルド成果物（Dockerイメージ、デプロイパッケージなど）が侵害されたバージョンを含んだままプロダクション環境に展開されていないかも確認が必要です。展開済みであれば、安全なバージョンでの再ビルドと再デプロイを速やかに実施してください。

overridesを活用した間接依存のaxiosバージョン強制固定による緊急回避策の実装例

axiosを直接依存として使用している場合はバージョン指定を変更するだけで済みますが、間接依存としてaxiosが含まれている場合は、依存元のライブラリがバージョンを制御しているため、単純なダウングレードでは対応できないケースがあります。この場合に有効なのが、npmのoverrides機能です。

package.jsonに以下の設定を追加することで、依存ツリー内のすべてのaxiosを安全なバージョンに強制的に固定できます。

{ "overrides": { "axios": "1.14.0" } }

この設定を追加した後にnpm installを実行すると、間接依存を含むすべてのaxiosが指定バージョンに解決されます。pnpmを使用している場合はpnpm.overrides、Yarnを使用している場合はresolutionsフィールドが同等の機能を提供しています。ただし、overridesはあくまで緊急回避策です。依存元のライブラリが安全なバージョンに対応したアップデートを公開した時点で、overridesの設定は削除し、通常の依存関係管理に戻してください。長期間放置すると、本来必要なバージョンアップが阻害され、別のセキュリティリスクを生む原因になります。

インシデント収束後に見落としやすいバックドア残存確認と再発防止チェックリスト

axiosの安全なバージョンへのダウングレードとクレデンシャルのローテーションが完了しても、インシデント対応はまだ終わりではありません。WAVESHAPER.V2のRATは、npmのパッケージとは独立してシステム上に残存している可能性があります。先述のOS別ファイルパス（macOSの/Library/Caches/com.apple.act.mond、Windowsの%PROGRAMDATA%\wt.exe、Linuxの/tmp/ld.py）を再度確認し、存在する場合は削除してください。

さらに、RATが永続化メカニズム（OS起動時の自動実行設定など）を追加していないかの確認も必要です。macOSではLaunchDaemonsやLaunchAgents、WindowsではスタートアップフォルダやレジストリのRunキー、Linuxではcronジョブやsystemdサービスを調査対象としてください。再発防止に向けては、今回のインシデントを契機に以下の事項を見直すことを推奨します。lockfileの管理体制の厳格化、npm ciの標準化、postinstallスクリプトの実行制御、依存パッケージの定期監査、そしてインシデント対応手順書の整備です。特に組織においては、今回の対応を振り返るポストモーテムを実施し、検知から封じ込めまでの所要時間と改善点を記録に残すことが、次のインシデントへの備えとなります。

npmのデフォルト設定が招く脆弱性とcooldown・lockfile運用による事前防御策

今回のaxios攻撃は、npmのデフォルト設定が抱える構造的な弱点を浮き彫りにしました。キャレット記法による自動バージョン更新、postinstallスクリプトの無条件実行、lockfileの軽視といった「便利さ優先」の初期設定が、攻撃者にとっての侵入経路となっています。この章では、パッケージマネージャーの設定変更だけで実現できる具体的な防御策を、npmを中心に各ツールの対応状況を比較しながら解説します。

キャレット指定が自動で最新版を取得し悪性バージョンを引き込んだ根本原因

今回の攻撃で多くの開発者が悪性バージョンをインストールしてしまった直接的な原因は、package.jsonにおけるバージョン指定方法にあります。npmでパッケージをインストールすると、デフォルトではキャレット記法（^）でバージョンが記録されます。たとえば"axios": "^1.12.0"という指定は、メジャーバージョンが同じ範囲で最新のマイナー・パッチバージョンを自動的に取得する挙動を意味しました。

この記法のもとでnpm installを実行すると、[email protected]が利用可能であれば自動的にそのバージョンが解決されます。lockfileが正しくコミットされていればnpm ciを使うことで固定バージョンをインストールできますが、多くの開発者は日常的にnpm installを使用しており、lockfileとの乖離が発生した場合には自動で最新版が取り込まれてしまいます。攻撃者はこのnpmの仕様を熟知した上で、最新バージョンとして不正パッケージを公開する戦略を取りました。対策として、.npmrcにsave-exact=trueを設定することで、キャレットを付けずに正確なバージョン番号で保存するようになります。すべてのバージョン更新が明示的なプルリクエストを通じてレビューされる運用に切り替えることが、リスクを大幅に低減させます。

npm v11.10.0のmin-release-age設定で公開7日未満のパッケージを自動拒否する方法

2026年2月にリリースされたnpm v11.10.0には、サプライチェーン攻撃対策としてmin-release-ageという設定が追加されました。この機能は、npmレジストリに公開されてから指定日数が経過していないパッケージバージョンのインストールを自動的に拒否するものです。設定方法は.npmrcファイルに1行追加するだけと非常にシンプルです。

min-release-age=7

この設定により、公開から7日未満のバージョンはnpm installの対象外となります。今回のaxios攻撃では、悪性バージョンは公開から数時間で検出・削除されました。7日間のクールダウンが設定されていれば、不正バージョンはインストール対象にすらならなかったことになります。調査によると、最近のサプライチェーン攻撃の多くは公開後1週間以内に検出・削除されているため、7日間という期間設定は実効性が高いと評価されています。設定値は日数で指定し、プロジェクトの更新頻度やリスク許容度に応じて調整してください。セキュリティ要件が厳しい環境では21日間に設定しているケースもあります。

save-exact=trueとnpm ciの併用でlockfileの安全性を担保する運用ルールの設計

lockfile（package-lock.json）は、依存関係ツリー全体の正確なバージョンとハッシュ値を記録するファイルです。これを正しく運用することで、「いつ、どこでnpm installを実行しても同じバージョンがインストールされる」という再現性を担保できます。しかし現実には、lockfileの管理が形骸化しているプロジェクトが少なくありません。

まず.npmrcにsave-exact=trueを設定し、npm install axiosの結果を"axios": "1.14.0"のようにキャレットなしの正確なバージョンで記録させます。次に、CI/CDパイプラインではnpm installではなくnpm ciを必ず使用してください。npm ciはlockfileとpackage.jsonの間に差分がある場合にエラーで停止するため、意図しないバージョン変更を確実に防止できます。運用ルールとして重要なのは、lockfileのマージコンフリクトが発生した際に「lockfileを削除してnpm installで再生成する」という対処法を禁止することです。この操作は依存ツリー全体を最新版で再解決してしまうため、攻撃者の不正バージョンを取り込むリスクが生まれます。代わりに、npm ciを利用した安全な再インストールを標準手順として定着させてください。

pnpm・Yarn・Bunの各パッケージマネージャーにおけるcooldown設定値の比較と注意点

クールダウン機能はnpmだけでなく、主要なJavaScriptパッケージマネージャーに広く実装されています。ただし、設定名や指定する単位がツールごとに異なるため、混同に注意が必要です。

特筆すべきは、pnpm v10ではpostinstallスクリプトがデフォルトで無効化されている点です。今回のaxios攻撃はpostinstallフックを実行経路としていたため、pnpmをデフォルト設定で使用していた開発者は攻撃の影響を受けにくい状態にありました。pnpmでは必要なパッケージだけを明示的に許可リストに追加する方式を採用しており、「デフォルトで安全」という設計思想が他のパッケージマネージャーとの大きな違いです。いずれのツールを使用する場合も、クールダウンの設定値はプロジェクト内の.npmrcや設定ファイルに記述し、リポジトリにコミットしてチーム全体で共有することが重要です。

ignore-scripts=trueでpostinstallフックを無効化する際に動作しなくなるパッケージへの対処

npmの.npmrcにignore-scripts=trueを設定すると、すべてのパッケージのpreinstall、install、postinstallスクリプトが実行されなくなります。今回のaxios攻撃で使用された感染メカニズムを根本的にブロックできるため、最も効果の高い防御設定の一つといえるでしょう。ただし、この設定にはトレードオフが伴うため、導入前に影響範囲を把握しておくことが欠かせません。

ネイティブアドオンのコンパイルが必要な一部のパッケージ（たとえばbcryptなど）は、postinstallスクリプトを使ってビルドを行うため、ignore-scripts=trueの環境では正常に動作しません。ただし、以前はsharpやesbuildもこの問題の対象とされていましたが、現在はいずれもoptionalDependenciesでプラットフォーム別バイナリを配布する方式に移行しており、スクリプト無効化環境でも正常に動作します。対処法としては、スクリプトの実行が必要なパッケージを把握した上で、そのパッケージのインストール時にのみ個別にスクリプト実行を許可する運用が推奨されます。pnpmではonlyBuiltDependenciesでホワイトリスト方式の管理が可能です。npmの場合は、全体をignore-scripts=trueに設定した上で、必要時にnpm rebuildコマンドで個別にビルドを実行する方法が実用的です。

CI/CDパイプラインとGitHub Actionsを標的にしたサプライチェーン攻撃への実務的対策

サプライチェーン攻撃のリスクは、ローカルの開発環境だけでなくCI/CDパイプライン全体に及びます。2026年3月にはaxiosに限らず、GitHub ActionsのアクションであるTrivyやtj-actions/changed-filesなど、CI/CDインフラそのものを狙った攻撃も複数発生しました。自動化されたパイプラインは、一度侵害されるとシークレットの大規模漏洩やプロダクション環境への不正コード混入に直結するため、開発ワークフロー全体を防御対象として捉える必要があります。

Dependabot cooldownで自動更新PRの作成を7日間遅延させるyml設定の具体例

npmのmin-release-ageはローカル環境でのnpm installを保護しますが、CI/CD上のDependabotによる自動更新PRは別の経路で動作するため、追加の設定が必要です。Dependabotは2025年7月からcooldown設定をサポートしており、新バージョンが公開されてからPRを作成するまでの待機期間を柔軟に指定できるようになりました。

dependabot.ymlに以下のように設定することで、min-release-ageと同じ待機期間をDependabot側にも適用できます。default-daysにはnpmのmin-release-ageと同じ日数を指定するのが基本です。semverのレベル（メジャー、マイナー、パッチ）ごとに個別の日数を設定することも可能で、メジャーアップデートにはより長いクールダウンを設けるといった運用が実現できます。重要な点として、セキュリティアップデートはcooldownの対象外として扱われるため、脆弱性修正のPRが遅延する心配はありません。この設計により、「通常の更新は慎重に、緊急のセキュリティ修正は迅速に」という運用モデルを自動化できます。min-release-ageとDependabot cooldownの日数を揃えておくことで、ローカルでもCIでも一貫した保護が適用される状態を構築してください。

GitHub ActionsのタグをSHAピニングで固定しタグ書き換え攻撃を防ぐ設定方法

GitHub Actionsで外部のアクションを利用する際、actions/checkout@v4のようなタグ指定を使用しているプロジェクトは多いですが、この指定方法にはリスクがあります。Gitのタグは可変であり、リポジトリが侵害された場合、既存のタグが指すコミットを攻撃者が書き換えることが可能です。タグの見た目は変わらないまま、実行されるコードが悪意あるものに差し替えられるという攻撃手法が現実に発生しています。

この問題への対策が、SHA（コミットハッシュ）によるピニングです。たとえばactions/checkout@v4をactions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683のようにフルハッシュで指定します。コミットハッシュは特定のコミットを一意に識別するため、タグの書き換えによる攻撃を完全に防止できます。GitHubでは2025年8月から組織レベルでSHAピニングを強制するポリシー設定が提供されており、設定画面のチェックボックス1つで有効化できます。ただし、このポリシーは利用しているアクションが内部で依存している別のアクションにも適用されるため、導入時にはワークフロー全体の動作確認が必要です。RenovateやDependabotのGitHub Actions対応機能を活用すれば、ハッシュの自動更新もPRベースで管理できます。

lockfile-lintによるpackage-lock.jsonの整合性チェックをCIに組み込む実装手順

lockfileの改ざんや不整合を自動的に検出するために、CIパイプラインにlockfile-lintを組み込むことが推奨されます。このツールはpackage-lock.jsonの内容を検証し、許可されたレジストリ以外からのパッケージ取得や、想定外のURLパターンが含まれていないかを自動的にチェックしてくれるため、導入の手間に対して得られる効果は非常に大きいでしょう。

npx lockfile-lint --path package-lock.json --type npm --allowed-hosts npm --validate-https

このコマンドをCIのステップに追加することで、プルリクエストのたびにlockfileの整合性が自動検証されます。検証に失敗した場合はCIが停止するため、不正な依存関係の混入をマージ前に検知できます。Gitのpre-commitフックとして設定すれば、ローカル環境でのコミット時にも同じ検証を実行させることが可能です。lockfile-lintに加えて、プルリクエストのdiffでpackage-lock.jsonに新しい依存関係が追加されていないかを目視レビューするプロセスも有効です。特に、これまで存在しなかったパッケージ名が突然lockfileに出現した場合は、その正当性を確認する習慣をチーム内に定着させてください。

hasInstallScript検知で新規依存追加時のpostinstallフックを自動フラグする仕組み

lockfileには各パッケージにhasInstallScriptというフィールドが記録されており、そのパッケージがインストールスクリプト（preinstall、install、postinstall）を持っているかどうかを示しています。新たに追加された依存関係がこのフラグを持っている場合、それは高いリスクシグナルとして扱うべきです。今回のaxios攻撃でも、plain-crypto-jsはpostinstallフック付きの未知のパッケージでした。

この検知を自動化するには、CIパイプライン内でlockfileのdiffを解析し、新規追加されたパッケージの中にhasInstallScript: trueが含まれていないかを確認するスクリプトを組み込みます。該当するパッケージが検出された場合は、CIを失敗させるか、セキュリティチームにアラートを送信する仕組みを構築してください。すべてのinstallスクリプト付きパッケージが悪意あるものとは限りませんが、「初めて見るパッケージ名」かつ「installスクリプト付き」という組み合わせは、非常に高い確率でサプライチェーン攻撃のシグナルです。この判定ロジックをCIに組み込むだけでも、今回のような攻撃パターンに対する検知率は大幅に向上します。

Trusted Publisherを迂回されたaxiosの事例から学ぶOIDC連携だけに頼る危険性

axiosプロジェクトは、GitHub ActionsのOIDC Trusted Publisherという仕組みを通じてnpmへの公開を自動化していました。Trusted Publisherは、GitHubリポジトリとnpmアカウントをOIDCトークンで安全に連携させる機能であり、CI/CDパイプラインからの公開に限定することで不正な手動公開を防ぐことを意図しています。しかし今回の攻撃では、この保護が迂回されました。

攻撃者はnpmのアカウント認証情報（トークン）を直接入手していたため、Trusted Publisherを経由せずにnpm CLIから手動で不正バージョンを公開できました。Trusted Publisherは「正規のCI/CDからの公開経路を保証する」機能であり、「npm CLIからの手動公開をブロックする」機能ではありません。つまり、アカウント認証情報が漏洩した時点で、Trusted Publisherの保護は無効化されます。この事実が示唆しているのは、OIDC連携を導入していることだけをもって安全とみなすのは危険だということです。アカウント側のセキュリティ、すなわち多要素認証（MFA）の強制、トークンの定期ローテーション、IPアドレス制限といった多層的な防御を併用しなければ、パッケージ公開経路の安全性は担保できません。

SBOM管理とSCAツール導入で依存関係の可視化と継続監視を実現する体制構築

個別の設定変更や緊急対応だけでは、次のサプライチェーン攻撃を確実に防ぐことはできません。依存関係の全体像を継続的に把握し、異常を早期に検知する「仕組み」を組織内に構築することが不可欠です。その中核となるのが、SBOM（Software Bill of Materials：ソフトウェア部品表）の管理と、SCA（Software Composition Analysis）ツールの導入です。この章では、ツールの選定基準から運用フローの設計まで、持続可能な体制構築に必要な知識を整理します。

間接依存を含む全パッケージの把握にSBOMが不可欠となる3つの実務的理由

SBOMとは、ソフトウェアを構成するすべてのコンポーネント（ライブラリ、フレームワーク、ツール）の一覧表です。今回のaxios攻撃が示したように、開発者が直接利用していないパッケージでも、間接依存として依存ツリーの深い階層に存在している可能性があります。SBOMの管理が実務上不可欠である理由は主に3つあります。

第一に、インシデント発生時の影響範囲の即時特定です。SBOMが整備されていれば、「axiosのバージョン1.14.1を使用しているプロジェクトはどれか」という問いに対して、数分で回答を得られます。SBOMがなければ、全プロジェクトを個別に調査する作業が必要となり、対応が大幅に遅延します。第二に、脆弱性情報との自動照合です。新たなCVEや侵害情報が公開された際に、SBOMと照合することで自社への影響を即座に判定できます。第三に、規制対応の要件充足です。米国の大統領令14028をはじめ、各国でSBOMの提出や管理を求める規制が強化されています。サプライチェーンセキュリティは技術的な課題であると同時に、コンプライアンス上の要件でもあるという点を見落としてはなりません。

yamoryやSnykなど主要SCAツールの検知範囲と導入コストの比較判断基準

SCAツールは、プロジェクトの依存関係を自動的にスキャンし、既知の脆弱性やライセンス違反、EOL（End of Life）パッケージの使用を検出するツールです。主要なツールとしては、国産のyamory、グローバルで広く使用されるSnyk、GitHub内蔵のDependabot、そしてSocket.devなどがあります。ツール選定の際に比較すべき主な判断基準を整理します。

今回のaxios攻撃のような「正規パッケージの侵害」は、従来のCVEベースの脆弱性スキャンでは検出が困難です。Socket.devのようにパッケージの振る舞い分析を行うツールや、Snykの21日間自動クールダウン機能のように予防的なアプローチを持つツールが、こうした攻撃パターンに対してより有効に機能します。組織の規模や予算に応じて、複数のツールを組み合わせる多層防御の考え方が推奨されます。

Takumi Guardをnpmレジストリプロキシとして導入し侵害パッケージを事前遮断する方法

GMO Flatt Securityが無償で提供する「Takumi Guard」は、npmレジストリとプロジェクトの間にプロキシとして介在し、既知の悪意あるパッケージのインストールを事前にブロックするセキュリティツールです。2026年3月時点ではnpmとPyPIに対応しており、今後crates.ioとRubyGemsへの対応も予定されているとのことでした。

導入手順は非常にシンプルで、.npmrcにTakumi Guardのレジストリプロキシを指定するだけで利用開始できます。インストールリクエストがTakumi Guardを経由することで、マルウェアとして報告されたパッケージや、サプライチェーンセキュリティスコアが低いパッケージのインストールが自動的に遮断されます。今回のaxios攻撃においても、[email protected]は公開直後にスコア0%と判定されていたため、Takumi Guard経由であればインストールがブロックされた可能性があります。導入にあたっての注意点として、無償サービスであるためサービス継続性に関する保証がないこと、そしてレジストリプロキシへの依存が新たな単一障害点になりうることを組織のリスク評価に含める必要があります。

SBOM生成からCI連携・定期スキャンまでの運用フローを最短で構築する5ステップ

SBOM管理とSCAツールの導入を最短で実現するための運用フロー構築手順を、5つのステップに分けて解説します。段階的に導入することで、既存の開発ワークフローへの影響を最小限に抑えながら、セキュリティ体制を強化できます。

1. 現状の依存関係の棚卸し：全プロジェクトでnpm ls --allを実行し、間接依存を含む依存ツリーの全体像を把握する
2. SCAツールの選定と初期スキャン：前項の判断基準をもとにツールを選定し、全リポジトリに対して初回スキャンを実施する
3. CI/CDへのスキャンステップ組み込み：プルリクエスト時に自動でSCAスキャンが実行されるようパイプラインを設定する
4. SBOM自動生成の設定：CIパイプライン内でCycloneDXまたはSPDX形式のSBOMを自動生成し、成果物として保存する
5. 定期スキャンとアラート運用の確立：週次または日次の定期スキャンを設定し、新規脆弱性の検出時にSlackやメール等でアラートが通知される体制を構築する

このフローの中で最も重要なのは、ステップ3のCI/CD統合です。手動でのスキャン実行に依存した運用は必ず形骸化するため、パイプラインに組み込んで自動化することが成功の鍵になります。また、検知されたアラートへの対応責任者と対応期限のルールを事前に定めておくことで、アラートが放置される事態を防げるでしょう。

ツール導入だけで安心しSBOMの更新頻度が低下する組織に共通する運用失敗の傾向

SCAツールやSBOM管理を導入した組織においても、時間の経過とともに運用が形骸化するケースは珍しくありません。共通する失敗パターンを把握しておくことで、自組織が同じ轍を踏むことを防げます。

最も多い失敗は、ツール導入をゴールと見なし、検知結果への対応プロセスが確立されないまま放置されるパターンです。SCAツールが脆弱性を検出しても、それを誰が・いつまでに・どのように修正するかのルールがなければ、アラートは単なるノイズになります。次に多いのが、SBOMの更新頻度の低下です。SBOMは依存関係が変更されるたびに再生成しなければ正確性を維持できませんが、手動運用に頼っているとリリースサイクルに追いつかなくなります。CIパイプラインへの自動生成の組み込みが必須である理由はここにあります。もう一つの典型的な失敗は、開発チームとセキュリティチームの間の責任分界点が曖昧なケースです。脆弱性の修正を開発チームに任せるのか、セキュリティチームがパッチを提供するのか、判断基準が不明確だと対応が遅延します。ツールの導入と同時に、対応フローと責任体制をドキュメントとして整備してください。

2025年後半から急増するnpmエコシステム攻撃の傾向と今後の開発者に求められる防衛意識

今回のaxios攻撃は孤立した事件ではなく、2025年後半から加速しているnpmエコシステムへの組織的攻撃の一環として位置づけられます。攻撃手法は高度化し、対象パッケージの規模も拡大しています。最終章では、直近の攻撃事例との比較を通じて攻撃トレンドを俯瞰し、個人開発者から組織まで今すぐ実行できる防御策を改めて整理します。

Chalk・Debug侵害やShai-Hulud自己増殖型マルウェアなど2025年の主要攻撃事例との比較

axiosへの攻撃に先立ち、2025年後半にはnpmエコシステムを標的にした大規模な攻撃が相次いで発生していました。2025年9月にはフィッシングによりChalkとDebugのメンテナアカウントが侵害されています。この2つのパッケージは合計で週間20億件以上のダウンロードがあり、axiosをはるかに上回る影響規模でした。

同月には、npm史上初の自己増殖型マルウェア「Shai-Hulud」が確認されています。従来のサプライチェーン攻撃はパッケージの直接的な改ざんに依存していましたが、Shai-Huludはワーム型の振る舞いを持ち、感染したパッケージから別のパッケージへと自動的に感染を広げる能力を持っていました。2025年11月にはその第二世代「Shai-Hulud 2.0」が出現し、795件以上のnpmパッケージが侵害されたことが確認されています。さらに2026年3月にはaxiosの前後に、Trivy、LiteLLM、Telnyxといったツールやライブラリも相次いで侵害を受けています。これらの事例に共通するのは、メンテナアカウントの侵害という攻撃起点と、postinstallフックを利用した感染メカニズムです。攻撃者のプレイブックが確立されつつあり、今後も同種の攻撃が繰り返される可能性は高いといえます。

メンテナアカウント侵害・タイポスクワッティング・依存関係混乱の3大攻撃パターン分類

npmサプライチェーン攻撃は、その手口によって大きく3つのパターンに分類されます。第一のパターンが、今回のaxios攻撃で使用された「メンテナアカウント侵害」です。攻撃者は正規のメンテナのnpm認証情報を窃取し、信頼されたパッケージの新バージョンとして不正コードを公開します。利用者の視点からは正規のアップデートに見えるため、発見が最も困難な攻撃パターンです。

第二のパターンは「タイポスクワッティング」で、人気パッケージに酷似した名前（たとえばaxiosに対するaxoisやaxi0sなど）の悪意あるパッケージを公開し、開発者のタイプミスを狙う手法です。第三のパターンは「依存関係混乱（Dependency Confusion）」で、社内で使用しているプライベートパッケージと同名のパッケージを公開npmレジストリに公開し、名前解決の優先順位を悪用して不正パッケージをインストールさせる手法です。この3つのパターンに対する防御策はそれぞれ異なるため、自社が直面しやすいリスクに応じた対策の優先順位を見極めてください。

• メンテナアカウント侵害：MFAの強制適用とcooldownによる公開直後バージョンの自動拒否が有効
• タイポスクワッティング：lockfileの厳格管理と新規依存追加時の目視レビュー徹底が有効
• 依存関係混乱：スコープ付きパッケージ名（@your-org/foo）の使用とレジストリ設定の明示が有効

自社の開発環境がどのパターンに対して脆弱かを評価し、上記の対策から着手すべき項目を選定することが、効率的なリスク低減への第一歩となるでしょう。

公開後1週間以内に検出される攻撃が8割という調査データが示すcooldownの有効性

クールダウン機能の有効性を裏付けるデータとして、セキュリティ研究者のAndrew Nesbittが「Package Managers Need to Cool Down」で紹介した調査結果があります。この調査によると、最近のnpmサプライチェーン攻撃10件のうち8件は、公開から1週間以内に検出・削除されていました。今回のaxios攻撃も、悪性バージョンが利用可能だった時間はわずか2〜3時間にとどまっています。

この事実が意味するのは、7日間のクールダウンを設定するだけで、統計的には約8割のサプライチェーン攻撃を事前にブロックできるということです。もちろん、検出まで1週間以上を要する攻撃も存在するため、クールダウンだけで完全な防御にはなりません。しかし、設定ファイルに1行追加するだけという導入コストの低さを考慮すれば、費用対効果は極めて高いと評価できます。2025年後半から主要パッケージマネージャーが相次いでクールダウン機能を実装したのも、この有効性が実証されたためです。Mend Renovateに至っては、npmパッケージに対する3日間のクールダウンをデフォルトで有効化しており、Snykは設定不要の21日間クールダウンを組み込んでいます。エコシステム全体がクールダウンを標準化する方向に進んでいることは明確です。

個人開発者がゼロコストで今日から実装できるサプライチェーン防御の最低限3設定

組織的な体制構築には時間がかかりますが、個人開発者であっても今日から実装できる防御策があります。追加のツールインストールは不要で、設定ファイルの変更だけで完了する3つの設定を紹介しましょう。いずれも今回のaxios攻撃を防げた可能性が高いものばかりでした。

1. .npmrcにignore-scripts=trueを追加：postinstallフック経由の感染を根本的にブロックする最重要の設定
2. .npmrcにmin-release-age=7を追加：公開7日未満のバージョンのインストールを拒否し、検出・削除までの時間的猶予を確保する（npm v11.10.0以降が必要）
3. Dependabotのdependabot.ymlにcooldown: default-days: 7を追加：自動更新PRの作成を7日間遅延させ、CI/CD側の保護も確保する

この3つを設定することで、ローカル開発環境とCI/CDの両方をカバーする基本的な防御層が構築されます。ignore-scripts=trueを設定した後に特定のパッケージが動作しなくなった場合は、npm rebuild パッケージ名で個別にビルドを実行してください。これらは完全な防御策ではありませんが、設定の手軽さに対して得られるリスク低減効果は非常に大きく、すべてのnpm利用者が導入を検討すべき最低限のベースラインです。

コードの品質からサプライチェーン全体の信頼性へと拡張すべきセキュリティの守備範囲

今回のaxiosサプライチェーン攻撃は、「コードの品質さえ高ければ安全」という従来の前提が通用しなくなっていることを決定的に示しました。axios本体のソースコードには悪意あるコードは1行も含まれておらず、セキュリティレビューやコード品質管理では防げない種類の攻撃でした。侵害されたのはコードではなく、「信頼された配布経路」そのものです。

この事実を受けて、開発者とセキュリティ担当者が守備範囲として認識すべき領域は、アプリケーションコードの品質管理から、サプライチェーン全体の信頼性管理へと拡大しています。具体的には、パッケージの取得元の検証、インストール時の実行制御、依存関係ツリーの可視化、公開フローの保護、CI/CDパイプラインのハードニングといった領域がすべてセキュリティの守備範囲に入ります。今回の攻撃でElasticが指摘したように、89秒で感染が始まるスピードは人手による確認だけでは対応が追いつかないレベルです。ツールによる自動化と、組織文化としてのサプライチェーンセキュリティ意識の醸成を車の両輪として推進することが、オープンソースエコシステムの恩恵を安全に享受し続けるための前提条件といえるでしょう。

よくある質問（FAQ）

axiosのマルウェア混入とは、何が起きたのですか？

2026年3月31日、axiosのリードメンテナのnpmアカウントが乗っ取られ、マルウェアを含む不正バージョン（1.14.1と0.30.4）がnpmレジストリに公開されました。axiosのソースコード自体ではなく、追加された[email protected]というファントム依存のpostinstallスクリプトが感染の起点で、npm installを実行するとmacOS・Windows・Linux向けのRAT（WAVESHAPER.V2）が自動的に展開されます。コードの脆弱性を突いたのではなく、信頼された配布経路そのものが悪用された「サプライチェーン攻撃」です。

自分のプロジェクトが感染しているか確認する方法は？

まずプロジェクトのルートでnpm ls axiosを実行し、依存ツリーにaxiosが含まれるか、どのバージョンかを確認します（yarnはyarn why axios、pnpmはpnpm why axios）。1.14.1または0.30.4が表示されたら侵害の疑いがあります。ただしマルウェアは痕跡を自己消去するため、node_modulesの検査だけでは見逃すことがあります。OS別のRAT設置パス（macOSは/Library/Caches/com.apple.act.mond、Windowsは%PROGRAMDATA%\wt.exe、Linuxは/tmp/ld.py）と、C2ドメインsfrclak[.]comへの通信ログも併せて確認してください。

影響を受けたバージョンと、安全なバージョンはどれですか？

不正版は1.x系の1.14.1とレガシー0.x系の0.30.4の2つです。対処としては、これらを避けて1.x系は1.15.0以降、0.x系は0.31.0以降へ更新し、package-lock.jsonを更新・コミットします。なお1.15.0（2026年4月7日公開）は、axiosで別途報告された脆弱性CVE-2026-40175（CVSS10.0）の修正も含むため、混入インシデントとあわせて対処できる更新先になります。間接依存でaxiosが入っている場合はoverrides（pnpmはpnpm.overrides、Yarnはresolutions）でバージョンを強制固定すると確実です。バージョン番号は更新される可能性があるため、適用する安全版の最新値はnpm公式・axiosのGitHubで確認してください。

このマルウェア混入による被害・影響範囲はどの程度ですか？

axiosは約17万5,000件のプロジェクトが直接依存し、間接依存を含めればさらに広範に使われています。トレンドマイクロのテレメトリでは、政府・金融・小売・医療・製造・テクノロジーなど複数業界にまたがる活動が確認されました。マルウェアはフル機能のRATで、システム情報・認証情報・ファイルの窃取と任意コマンド実行が可能です。とくにCI/CDパイプラインで実行された場合、注入されていたAPIキーやクラウド認証情報などのシークレットが一括で漏洩するおそれがあります。

誰がこの攻撃を行ったのですか？

Google Threat Intelligence Group（GTIG）は、今回の攻撃を北朝鮮を拠点とする金銭目的の脅威アクターUNC1069に帰属すると評価しました。根拠として、使用されたバックドア「WAVESHAPER.V2」が過去にUNC1069が用いた「WAVESHAPER」の更新版であること、攻撃インフラの重複が挙げられています。国家支援型のアクターがオープンソースの信頼構造を狙っている点が、本インシデントの深刻さを示しています。

関連記事

• CVSS10.0を記録したCVE-2026-40175がAxios利用企業に迫る深刻リスク
• CVE-2026-40175がCVSS満点10.0と評価された理由と開発現場への緊急度
• pnpmとcorepackを使ったNode.jsとpnpmのバージョン管理のまとめ