CVE-2026-40175がCVSS満点10.0と評価された理由と開発現場への緊急度

CVE-2026-40175がCVSS満点10.0と評価された理由と開発現場への緊急度

2026年4月7日にaxios 1.15.0がリリースされ、同月9日にGitHub Security Advisory、10日にNVD（National Vulnerability Database）でCVE-2026-40175として登録された脆弱性は、CVSS v3.1で満点の10.0を記録するCritical評価を受けました。JavaScriptの代表的なHTTPクライアントライブラリであるaxiosに存在するこの脆弱性は、Prototype Pollutionを起点としたGadget攻撃チェーンにより、リモートコード実行（RCE）やAWSクラウド環境の全面侵害につながる深刻な問題です。週間ダウンロード数が約9,300万回に達するaxiosの利用規模を考えると、影響を受けるプロジェクトは膨大な数にのぼります。本セクションでは、なぜこの脆弱性が最高スコアを獲得したのか、その評価構造と緊急対応の根拠を整理していきましょう。

攻撃複雑度Low・認証不要・スコープ変更ありが満点を導く評価構造

CVSSスコアの算出は、攻撃元区分（AV）、攻撃条件の複雑さ（AC）、必要な権限レベル（PR）、ユーザー関与（UI）、スコープ（S）、機密性・完全性・可用性への影響（C/I/A）という複数の基本評価基準に基づいて行われるものです。CVE-2026-40175のベクトル文字列はAV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hであり、すべての項目が最大リスク側に振れていることがわかります。なお、2026年4月14日時点でNVDのステータスは「Received」であり、この10.0スコアはCNA（CVE Numbering Authority）であるGitHubが算出した評価値をNVDが掲載している段階です。攻撃元区分がNetwork（リモートから攻撃可能）、攻撃条件の複雑さがLow（特殊な条件不要）、必要な権限がNone（認証なしで悪用可能）、ユーザー関与もNone（被害者の操作不要）という組み合わせは、攻撃者にとって極めてハードルの低い状況を意味するでしょう。さらにスコープがChanged（脆弱なコンポーネントの権限範囲を超えて他システムに影響が波及する）に設定されている点が、10.0という満点評価の決定的要因です。axiosライブラリ自体の脆弱性がAWSメタデータサービスへのアクセスを可能にし、クラウドインフラ全体の侵害に発展するため、スコープ変更ありと判定されました。

EPSSパーセンタイル46.96%が示すリスク水準と他のCritical脆弱性との比較

CVSSスコアが脆弱性の技術的な深刻度を表すのに対し、EPSS（Exploit Prediction Scoring System）は今後30日間に実環境で悪用される確率を予測する仕組みです。EPSSには2つの指標があり、Probability（悪用確率）とPercentile（全CVEにおける相対順位）に分かれています。CVE-2026-40175のEPSSパーセンタイルは46.96%と報告されており、これは全CVEのうち約47%よりも悪用リスクが高いことを意味する順位指標です。一方、実際の悪用確率（Probability）は公開直後の時点で約0.24%と算出されています。この数値は一見低く見えるかもしれませんが、CVSSスコアと異なりEPSSは公開直後から時間経過とともに更新される動的なスコアであり、PoCが広まるにつれて上昇する傾向がある点に注意が必要です。実際にGitHub Advisoryには詳細なPoCコードが掲載されており、攻撃チェーンの再現手順が公開済みです。Prototype Pollutionの攻撃プリミティブがJavaScriptエコシステムに広く存在するため、前提条件のハードルが低く、今後EPSSのProbabilityが上昇するリスクは十分に考えられるでしょう。

CWE-113とCWE-444の複合指定が意味するHTTPレイヤーの多重リスク

この脆弱性には、CWE-113（HTTPヘッダーにおけるCRLFシーケンスの不適切な無害化）、CWE-444（HTTPリクエストの不整合な解釈）、CWE-918（サーバーサイドリクエストフォージェリ：SSRF）の3つの弱点タイプが複合的に指定されています。CWE-113はHTTPヘッダー値に改行コード（CR: \r、LF: \n）が混入することでレスポンス分割やリクエスト分割が発生する問題に対応した分類です。CWE-444はフロントエンドプロキシとバックエンドサーバーの間でHTTPリクエストの解釈が食い違うことで生じるスマグリング攻撃を示します。そしてCWE-918は、サーバー側からの不正なリクエスト送信を許すSSRFの脆弱性です。CVE-2026-40175では、Prototype Pollutionで汚染されたヘッダー値にCRLFが含まれたままaxiosがHTTPリクエストを送信し（CWE-113）、そのリクエストがバックエンドで異なる解釈をされ（CWE-444）、最終的にAWSメタデータサービスへの不正アクセスとして機能する（CWE-918）という3段構えの攻撃が成立します。単一のCWEでは説明しきれない複合的な攻撃パスを持つことが、この脆弱性の対処を困難にしている要因です。

2026年4月10日公開から72時間以内に対応すべきと判断される根拠

セキュリティインシデント対応において、CVSS 9.0以上のCritical脆弱性には通常24〜72時間以内のパッチ適用が推奨されます。CVE-2026-40175が72時間以内の対応を要する根拠は、技術的な深刻度だけではありません。第一に、axiosはnpmエコシステムで週間約9,300万回ダウンロードされるキーパッケージであり、直接依存だけでなく推移的依存として無数のプロジェクトに組み込まれています。第二に、この脆弱性はaxios単体では発火しないものの、攻撃の前提条件であるPrototype Pollutionの脆弱性がqs、minimist、body-parserなどの広く使われているライブラリに過去何度も報告されており、依存ツリーのどこかに該当パッケージが存在する可能性が高い状況です。第三に、この脆弱性の公開はaxiosのnpmサプライチェーン攻撃（2026年3月31日）からわずか10日後であり、axiosの依存関係を精査する注目度が高まっている最中でした。攻撃者が注目の集まるライブラリの脆弱性情報を利用して悪用を試みるリスクは、通常よりも高いと判断すべきです。

CVSS 10.0とGitHub Advisory 9.9のスコア差が生じた評価基準の違い

CVE-2026-40175のCVSSスコアをめぐっては、一見すると食い違いがあるように見える記載が存在するため注意が必要です。GitHub Security Advisoryの正式なCVSSパネルでは、ベクトルCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Hに基づきスコア10.0と算出されており、NVDでも同じ10.0が掲載されています。しかし、同じGitHub Advisoryの「Description」セクション内で、報告者が「Severity: Critical (CVSS 9.9)」と記述しているため、一部のセキュリティ情報サイトがこの9.9を引用している状況が見られるのです。実際には、報告者がDescription内に記載した9.9と、CVSS計算機が正式なベクトルから算出した10.0の間に矛盾が生じた形であり、正規のスコアは10.0が正確な値となります。この食い違いが発生した原因は明確には公表されていませんが、報告者がCVSS計算ツールの異なるバージョンや設定を使用したか、一部の評価基準を手動で調整した可能性が考えられるでしょう。実務上で重要なのは、スコアの小数点以下の差異ではなく、自社環境でaxiosがどのバージョンで使用されているかを迅速に特定し、1.15.0以上へのアップグレードを実行することです。9.9でも10.0でもCriticalカテゴリに該当し、即時対応が必要な脆弱性であることに変わりはありません。

Prototype Pollutionからクラウド全面侵害に至る多段攻撃チェーンの全容

CVE-2026-40175の最大の特徴は、axios自体がPrototype Pollutionの発生源ではないにもかかわらず、他のライブラリで発生した汚染を「増幅」してRCEやクラウド侵害に発展させるGadget（部品）として機能する点にあります。ここでは攻撃チェーンの各段階を順に追い、なぜaxiosが最も危険なGadgetの一つとなりうるのかを技術的に解説します。

qs・minimist・body-parserなど外部ライブラリ経由で汚染が始まる第1段階

攻撃チェーンの出発点は、axiosそのものではなく、アプリケーションの依存ツリーに含まれる別のライブラリに存在するPrototype Pollution脆弱性です。Prototype Pollutionとは、JavaScriptのオブジェクト継承メカニズムを悪用し、Object.prototypeにプロパティを注入する攻撃手法です。攻撃者が__proto__やconstructor.prototypeを経由して任意のプロパティを設定すると、その値がアプリケーション内のすべてのオブジェクトに継承されます。過去にPrototype Pollution脆弱性が報告されたライブラリとしては、クエリ文字列パーサーのqs、コマンドライン引数パーサーのminimist、設定ファイルパーサーのini、Express.jsのリクエストボディパーサーであるbody-parserなど、Node.jsプロジェクトで極めて一般的なパッケージが挙げられるでしょう。これらのライブラリで修正済みの脆弱性であっても、古いバージョンが推移的依存として残っていれば攻撃の起点になります。重要なのは、攻撃者がaxiosのコードに一切触れることなく、別のパッケージへの入力だけで第1段階を完了できるという点です。

Object.prototypeの汚染値がAxiosのconfig mergeに継承される第2段階

第1段階でObject.prototypeが汚染されると、axiosの内部処理で自動的に汚染値が取り込まれます。axiosはHTTPリクエストを送信する際、デフォルト設定・インスタンス設定・リクエスト固有の設定を深くマージするmergeConfig関数を使用する設計です。このプロセスでオブジェクトのプロパティを走査する際、hasOwnPropertyによるチェックが不十分な箇所があると、Object.prototypeに注入されたプロパティも通常のconfigプロパティとして取り込まれます。たとえば攻撃者がObject.prototype['x-amz-target']にCRLF文字を含む値を設定した場合、axiosのconfigマージ処理はこれを正規のHTTPヘッダー設定として扱ってしまうのです。この段階では、開発者が記述したaxiosの呼び出しコードには一切の変更や不審な点がなく、IDE上のコードレビューでは検知できません。汚染はJavaScriptランタイムのプロトタイプチェーンという目に見えないレイヤーで伝播するため、デバッグも極めて困難です。

CRLF未検証のヘッダー値がHTTPリクエスト分割を引き起こす第3段階

第2段階でaxiosのconfig内にCRLF文字を含むヘッダー値が取り込まれた後、lib/adapters/http.jsがNode.jsのhttpモジュールを使ってHTTPリクエストを構築・送信します。パッチ前のaxiosでは、lib/core/AxiosHeaders.jsのsetメソッドがヘッダー値に含まれるCR（\r）やLF（\n）の検証を行っていませんでした。normalizeValue関数による末尾のCRLF除去処理は存在しましたが、ヘッダー値の途中に挿入されたCRLFには対応していなかったのです。その結果、攻撃者が注入した\r\nがHTTPリクエスト内でそのまま送信され、HTTPリクエスト分割（HTTP Request Splitting）が発生します。1つのHTTPリクエストの中に改行で区切られた別のリクエストが埋め込まれることで、axiosが意図しない宛先への追加リクエストを送信するという事態が発生します。これがHTTPリクエストスマグリング（CWE-444）の成立であり、攻撃チェーンの核心部分です。

AWS IMDSv2バイパスによるEC2認証情報の窃取に至る最終到達シナリオ

HTTPリクエスト分割が可能になった攻撃者は、axiosが稼働するサーバーから内部ネットワークへのSSRFリクエストを構築できます。最も深刻なシナリオは、AWSのEC2インスタンスメタデータサービス（IMDS）への不正アクセスです。IMDSv2はIMDSv1のセキュリティ強化版で、まずPUTリクエストでセッショントークンを取得し、そのトークンをヘッダーに付与してGETリクエストを送る2段階認証を採用しています。しかし、HTTPリクエスト分割を利用すれば、攻撃者は1つのaxiosリクエスト内にPUTリクエスト（トークン取得）とGETリクエスト（メタデータ取得）の両方を埋め込むことが可能です。取得されるメタデータには、IAMロールに紐づく一時的なAWSアクセスキー、シークレットキー、セッショントークンが含まれ、これらを窃取されるとS3バケット、DynamoDB、Lambda、その他すべてのAWSリソースへの不正アクセスが成立します。これがCVSSスコアにおけるスコープ変更（S:C）の根拠であり、axiosのライブラリ境界を超えてクラウドインフラ全体が侵害される最終到達シナリオです。

ユーザー入力ゼロで攻撃が成立する点が従来のSSRFと異なる決定的特徴

従来のSSRF脆弱性は、攻撃者がURLパラメータやリクエストボディを通じて不正なURLをサーバーに送り込み、サーバー側で内部リソースへのリクエストを発生させるパターンが一般的でした。つまり、攻撃者が直接的なユーザー入力を行う必要がありました。CVE-2026-40175が根本的に異なるのは、axiosに対する直接的なユーザー入力が一切不要な点です。攻撃者が操作するのはPrototype Pollutionを引き起こす別のライブラリへの入力だけであり、axiosは汚染されたObject.prototypeからヘッダー値を自動的に継承して不正リクエストを送信します。開発者がaxiosの呼び出し箇所にどれほど厳密な入力バリデーションを実装していても、プロトタイプチェーン経由の汚染は防げません。この特性は、WAF（Web Application Firewall）やAPIゲートウェイでの入力フィルタリングをすり抜けることを意味します。従来の「入力をサニタイズすればSSRFは防げる」というセキュリティモデルが通用しない点が、この脆弱性を特に危険たらしめている要因です。GitHubのAdvisoryでもこの特徴は明確に指摘されており、Gadget型脆弱性への対策にはライブラリ自体のアップデートが唯一の根本対策であると強調されています。

2026年3月のnpmサプライチェーン攻撃との関連性と被害拡大の時系列

CVE-2026-40175の公開は2026年4月10日ですが、axiosをめぐるセキュリティ問題はその約10日前に発生したnpmサプライチェーン攻撃と密接に関連しています。2026年3月31日、axiosの正規メンテナーアカウントが乗っ取られ、RATを含む悪意あるバージョンがnpmレジストリに公開されました。このサプライチェーン攻撃と脆弱性公開の時系列を正確に把握することは、自社プロジェクトへの影響を正しく評価するうえで不可欠です。

3月31日未明の約3時間で配布されたaxios 1.14.1と0.30.4の侵害経緯

2026年3月31日午前0時21分（UTC）、axiosのnpmレジストリにバージョン1.14.1が公開されました。続いて午前1時にバージョン0.30.4も公開されています。1.14.1はlatestタグ、0.30.4はlegacyタグが付与されたため、npm install axiosを実行したすべての開発者・CI/CDパイプラインが自動的に悪意あるバージョンを取得する状態になりました。これらの悪意あるバージョンは約3時間後の午前3時29分頃にnpmレジストリから削除されましたが、axiosの週間ダウンロード数が約9,300万回であることを考えると、この短い時間窓でも相当数のシステムが影響を受けた可能性があります。特に重要な点は、悪意あるバージョンにはaxiosのソースコード自体への変更が含まれておらず、package.jsonに新たな依存パッケージ（plain-crypto-js@^4.2.1）が追加されただけだったことです。ソースコードのdiffだけを確認しても侵害を検出できない巧妙な手口でした。

[email protected]のpostinstallフックで自動実行されたRAT配信手口

攻撃者が追加した依存パッケージplain-crypto-jsには、npmのライフサイクルフックであるpostinstallスクリプトが設定されていました。npm installが依存パッケージのインストールを完了した直後にnode setup.jsが自動実行される仕組みです。setup.jsは多層の難読化が施されており、実行時にモジュール名、プラットフォーム識別子、ファイルパス、コマンドテンプレートなどの文字列を動的に復元します。実行後は攻撃者のC2サーバー（sfrclak[.]com:8000）に接続し、OSに応じたRAT（リモートアクセストロイ）のペイロードをダウンロード・実行します。macOSにはC++製、WindowsにはPowerShell製、LinuxにはPython製のRATが配信され、いずれも同一のC2プロトコルとコマンドセットを実装したクロスプラットフォーム対応でした。さらにRAT配信後、setup.jsは自身を削除し、悪意あるpostinstallフックを含むpackage.jsonも削除したうえで、あらかじめ用意されていたクリーンなスタブファイル（package.md）をpackage.jsonにリネームするアンチフォレンジック処理を実行するため、事後の調査でもnode_modules内の痕跡は消去されている可能性があります。

北朝鮮関連アクターSapphire Sleetによるアカウント乗っ取りの攻撃手法

2026年4月1日、MicrosoftのThreat Intelligenceチームはこのサプライチェーン攻撃をSapphire Sleet（北朝鮮関連の金銭目的の脅威アクター）に帰属させました。Googleの脅威分析グループも同様にUNC1069としてこのアクターを追跡しています。攻撃者はaxiosのリードメンテナーであるjasonsaayman氏のnpmアカウントを乗っ取り、登録メールアドレスを攻撃者管理のProtonMailアドレス（ifstap@proton[.]me）に変更しました。jasonsaayman氏は「2FA/MFAはほぼすべてに設定していた」とGitHub issue #10604で述べていますが、具体的な侵入経路は調査中のままです。乗っ取り後、攻撃者はGitHub ActionsのCI/CDパイプラインを完全にバイパスし、npm CLIから直接パッケージを公開しています。正規のリリースに付与されるOIDCプロヴナンスメタデータやSLSAビルド証明が悪意あるバージョンには一切含まれておらず、この不在が侵害検出の重要な手がかりとなりました。

OIDC Trusted Publishing設定下でも長寿命トークンが突破口になった失敗例

axiosプロジェクトではv1.xブランチにOIDC Trusted Publishingが設定されていましたが、CI/CDパイプラインの実装に致命的な問題がありました。公開ワークフローがOIDC認証と同時にNPM_TOKENを環境変数として渡しており、npmはOIDCとトークンの両方が存在する場合にトークンを優先して使用します。つまりOIDC Trusted Publishingが設定されていても、実質的には長寿命のnpmアクセストークンが認証手段として機能していたのです。攻撃者はこのトークンを窃取・利用することで、GitHubのブランチ保護やコードレビューのプロセスを一切経由せずにパッケージを公開できました。この事例は、OIDC Trusted Publishingを「設定しただけ」では不十分であり、長寿命トークンの完全な廃止とパブリッシュ権限のスコープ制限を同時に行わなければ実効性がないことを示しています。npmの公式ドキュメントでもOIDC導入時にはトークンベースの認証を無効化することが推奨されており、この推奨事項の軽視が突破口になった典型的な失敗パターンです。

CVE-2026-40175公開が供給チェーン事件の10日後になった時系列の意味

サプライチェーン攻撃が2026年3月31日に発生し、CVE-2026-40175の公開が4月10日という時系列には、セキュリティ対応上の重要な含意があります。まず、サプライチェーン攻撃への対応としてaxios 1.14.0または0.30.3へのロールバックが推奨されましたが、これらのバージョンにもCVE-2026-40175の脆弱性は存在していました。つまり、サプライチェーン攻撃から適切にロールバックしたプロジェクトであっても、Prototype Pollution Gadget脆弱性への対策は別途必要です。次に、サプライチェーン攻撃の調査過程でaxiosのセキュリティ監査が強化され、その結果としてCVE-2026-40175を含む複数の脆弱性が発見・修正されたという経緯があります。実際にaxios 1.15.0のリリースには、CVE-2026-40175のほかにNO_PROXYバイパスSSRF（GHSA-3p68-rc4w-qgx5）やHTTP/2セッション状態破損など、複数のセキュリティ修正を同時に含んだリリースとなりました。この時系列は、サプライチェーン攻撃対応を完了したと思っている組織にも追加のアップグレード作業が必要であることを意味しており、対応の「完了判断」を慎重に行うべき理由となっています。

週間1億DL超のaxiosが影響を及ぼすプロジェクトの条件と判定基準

axiosはnpmレジストリで週間約1億回ダウンロードされているキーエコシステムプロジェクトです。しかし、CVE-2026-40175の影響を受けるかどうかは、単にaxiosを使っているかどうかだけでは判断できません。実行環境、axiosのバージョン、依存ツリー内のPrototype Pollution脆弱性の有無など、複数の条件を組み合わせて判定する必要があります。

直接依存だけでなくtransitive dependencyで影響を受ける5つの典型パターン

axiosは多くのプロジェクトで直接依存として利用されていますが、推移的依存（transitive dependency）として間接的に組み込まれているケースも非常に多く、影響範囲の正確な把握を困難にしている要因でもあるのです。影響を受ける典型的なパターンは以下の5つに分類できます。

• 自社のpackage.jsonにaxiosを直接記載しており、明示的に利用しているケース
• AWS SDKやFirebase Admin SDKなど、クラウドサービスのSDKがaxiosを内部依存として利用しているパターン
• テストフレームワークやモックライブラリがaxiosに依存し、CI/CDパイプラインの開発環境に影響が及ぶケース
• WordPressプラグインなどCMSやサイトビルダーのNode.jsツールチェーンにaxiosが含まれるパターン（実際にサプライチェーン攻撃ではWordPressモジュールの推移的依存からplain-crypto-jsが検出された事例あり）
• 社内共有のnpmパッケージやモノレポ内の共通ユーティリティがaxiosに依存しているケース

npm ls axiosコマンドで依存ツリーを確認し、どの経路でaxiosが導入されているかを特定することが対策の第一歩です。特に推移的依存は開発者が認識していないことが多いため、定期的な依存ツリーの棚卸しが不可欠といえるでしょう。

React・Vue・AngularなどフロントエンドフレームワークごとのAxios利用状況

フロントエンド開発において、axiosはフレームワークを問わず広く採用されてきました。Reactプロジェクトでは、useEffectフック内でのAPI呼び出しにaxiosが使われるケースが多く、Next.jsのgetServerSidePropsやAPI Routesでもサーバーサイドで利用されます。Vue.jsでは、Vue 2時代にvue-resourceからaxiosへの移行が公式に推奨された経緯があり、Vuex/PiniaのアクションやNuxtのasyncDataでの利用が標準的な構成として定着しました。Angularでは組み込みのHttpClientが存在するためaxiosの直接利用は比較的少ないものの、Angular Universalでのサーバーサイドレンダリングや、AngularベースのIonicアプリでaxiosが使われているケースがあります。ただし、CVE-2026-40175のRCEリスクが直接的に発生するのはNode.jsサーバーサイドでaxiosが実行される場合です。ブラウザ環境ではHTTPリクエストのヘッダー設定にブラウザのセキュリティ制約がかかるため、攻撃チェーンの第3段階以降が成立しにくくなります。とはいえ、SSRやAPIルートでaxiosを使うフルスタックフレームワークでは、同一コードベース内にサーバーサイド実行パスが含まれるため、油断は禁物です。

Node.jsサーバーサイドとブラウザ環境でリスクレベルが異なる判断基準

CVE-2026-40175の攻撃チェーンは、最終的にHTTPリクエスト分割を利用したSSRFに到達するため、リスクレベルは実行環境によって明確に異なります。Node.jsサーバーサイドで動作するaxiosは、lib/adapters/http.jsを通じてNode.jsのhttp/httpsモジュールを直接使用するため、CRLF注入が有効に機能します。この環境ではIMDSv2バイパスを含むフルチェーンの攻撃が成立するため、リスクレベルは最大（Critical）です。一方、ブラウザ環境で動作するaxiosはlib/adapters/xhr.jsを使用し、XMLHttpRequestまたはfetch APIを通じてリクエストを送信します。ブラウザのHTTPスタックはヘッダー値に対する独自のバリデーションを持ち、CRLFを含むヘッダーは拒否されるため、攻撃チェーンの第3段階が成立しません。ただし、Prototype Pollution自体はブラウザ環境でも発生するため、axiosのconfig汚染による予期せぬリクエスト先変更など、別の攻撃パスが存在する可能性は残ります。判断基準として、自社プロジェクトでaxiosがサーバーサイドで実行される箇所が1つでもあれば、CVE-2026-40175の影響ありとして対応を進めるべきです。

AWS Lambda・Cloud Functionsなどサーバーレス環境で被害が拡大しやすい理由

サーバーレス環境はCVE-2026-40175の攻撃対象として特に危険性が高いとされています。AWS Lambdaでは、関数の実行環境にIAMロールが自動的に割り当てられ、そのロールの認証情報はIMDS経由で取得可能です。Lambda関数内でaxiosを使用してAPIコールを行う場合、Prototype Pollutionが発生すれば攻撃チェーンによってLambda実行ロールの認証情報が窃取されます。Lambda関数のIAMロールは、S3、DynamoDB、SQS、SNSなど複数のAWSサービスへのアクセス権限を持つことが多く、過剰な権限が付与されているケースも少なくありません。Google Cloud FunctionsやAzure Functionsでも同様のメタデータサービスが存在し、IMDSv2のような2段階認証が実装されていない環境では、さらに攻撃が容易になります。サーバーレス環境特有の課題として、関数のデプロイパッケージに含まれるnode_modulesの管理が疎かになりやすい傾向も見られるでしょう。一度デプロイした関数のaxiosバージョンが長期間更新されないまま運用されるケースは珍しくなく、脆弱なバージョンが本番環境に残存するリスクは従来型のサーバーよりも高くなる傾向があります。

package-lock.jsonのaxiosバージョンが1.15.0未満かを30秒で判定する方法

影響有無の最も迅速な判定方法は、プロジェクトのlockfileを検索することです。npmを使用している場合は、ターミナルでgrep -E '"axios"' package-lock.json | grep -v '1\.15\.'を実行します。出力があればaxios 1.15.0未満のバージョンが含まれており、対応が必要です。yarnの場合はgrep 'axios@' yarn.lock | grep -v '1\.15\.'、pnpmの場合はgrep 'axios' pnpm-lock.yaml | grep -v '1\.15\.'で同様の確認が可能です。より詳細な確認にはnpm ls axiosコマンドが有効で、依存ツリー内のすべてのaxiosインスタンスとそのバージョン、依存経路を一覧表示できます。lockfileがコミットされていないプロジェクトでは、package.jsonの依存関係からaxiosのバージョン範囲を確認し、キャレット（^）やチルダ（~）指定で1.15.0未満に解決される可能性がないかを確認します。モノレポ構成の場合は各ワークスペースのlockfileを個別に確認する必要があるため、find . -name 'package-lock.json' -exec grep -l axios {} \;でaxiosを含むlockfileを一括検出してから順に調査する方法が効率的です。

AxiosHeadersのCRLF未検証がRCEとAWS認証窃取を生む技術的構造

CVE-2026-40175の根本原因は、axiosのHTTPヘッダー処理におけるCRLF文字の検証不備にあります。脆弱性の発生箇所はlib/core/AxiosHeaders.jsのsetメソッドと、lib/adapters/http.jsのヘッダー処理部分です。ここでは、パッチ前後のコードの違いを含め、脆弱性の技術的な構造を詳細に解説します。

lib/core/AxiosHeaders.jsのsetメソッドが改行文字を素通しさせていた欠陥

AxiosHeadersクラスのsetメソッドは、axiosのすべてのHTTPリクエストで使用されるヘッダー設定の中核関数です。パッチ前のこのメソッドは、ヘッダー名の重複チェックやnull/undefined値の除外は行っていたものの、ヘッダー値の内容に対するバリデーションは実装されていませんでした。HTTPプロトコルにおいて、ヘッダーフィールドの値にCR（0x0D）やLF（0x0A）が含まれることは許容されておらず、これらの文字の存在はHTTPレスポンス分割やリクエスト分割の攻撃ベクトルとなります。しかしsetメソッドはこの制約を強制していなかったため、Object.prototypeから継承された汚染値がCRLFを含んでいた場合でも、そのままヘッダーとして設定されてしまいました。RFC 7230ではHTTPヘッダーフィールド値にCRLFが含まれることを明確に禁止しており、axiosのこの実装は仕様への準拠が不十分だったと言えます。Node.jsのhttpモジュール自体は一部のバージョンでヘッダー値のCRLFチェックを行いますが、そのチェックもバージョンによって一貫しておらず、axiosライブラリ側での検証が不可欠でした。

normalizeValueの末尾CRLF除去だけでは防げなかったインジェクション経路

パッチ前のaxiosにもヘッダー値の正規化処理としてnormalizeValue関数が実装されていたのも事実です。この関数はヘッダー値の末尾に付与されたCRLF文字を除去する処理を行っていましたが、ヘッダー値の先頭や中間に挿入されたCRLFには対応していませんでした。攻撃者がPrototype Pollutionで注入する値は、たとえば"malicious-value\r\nX-Injected-Header: evil\r\n\r\nGET /latest/meta-data/iam/security-credentials/ HTTP/1.1\r\nHost: 169.254.169.254"のように、CRLFをヘッダー値の途中に配置します。normalizeValueによる末尾トリミングでは、この中間CRLFは除去されません。結果として、axiosが構築するHTTPリクエストのヘッダー部分に改行が挿入され、意図しない追加ヘッダーや別のHTTPリクエストがリクエストボディに埋め込まれます。この設計上の見落としは、末尾の空白文字除去のような「整形処理」とセキュリティ上の「入力検証」は根本的に異なる目的を持つ処理であり、前者で後者を代替できないことを示す教訓的な事例です。

汚染されたx-amz-targetヘッダーがIMDSv2のPUTトークン取得を偽装する仕組み

攻撃チェーンの具体例として、AWSのIMDSv2バイパスシナリオを技術的に追跡します。攻撃者がPrototype PollutionでObject.prototype['x-amz-target']に細工された値を設定すると、axiosが次にHTTPリクエストを送信する際、configマージ処理でこのプロパティがヘッダーとして自動的に継承される仕組みです。設定される値にはCRLF文字と追加のHTTPリクエストが埋め込まれており、axiosが1つのリクエストを送信したつもりが、実際にはネットワーク上に2つ以上のリクエストが送出されます。追加されたリクエストの宛先はhttp://169.254.169.254/latest/api/token（IMDSv2トークン取得エンドポイント）であり、X-aws-ec2-metadata-token-ttl-seconds: 21600ヘッダーを付与したPUTリクエストとして構築されています。このPUTリクエストのレスポンスとして返されるトークンを取得するため、さらに後続のGETリクエストが埋め込まれる構造です。最終的に/latest/meta-data/iam/security-credentials/へのアクセスが成功すると、EC2インスタンスに割り当てられたIAMロールの一時認証情報が攻撃者に渡ります。

PR #10660で導入されたassertValidHeaderValue関数による検証の実装内容

CVE-2026-40175の修正はPR #10660としてaxiosリポジトリに提出され、コミット363185461b90b1b78845dc8a99a1f103d9b122a1で実装されました。修正の中核は、assertValidHeaderValueという新しいバリデーション関数の導入です。この関数はAxiosHeaders.setメソッド内でヘッダー値の設定時に呼び出され、値にCR（\r）またはLF（\n）が含まれていないかを検証します。不正な文字が検出された場合はTypeErrorをスローし、ヘッダーの設定を拒否します。この検証はブラウザアダプター、Node.js httpアダプター、fetchアダプターのすべてで共通に適用されるため、アダプターごとの検証漏れが発生しません。加えて、__proto__やconstructorなどPrototype Pollutionに関連するキーがリクエストオブジェクトからaxiosの内部処理に漏洩することを防ぐ防御的なフィルタリングも追加されています。修正はaxios 1.15.0としてリリースされ、v0.xブランチへのバックポートは行われていないため、0.x系を使用しているプロジェクトは1.x系へのメジャーアップグレードが必要です。

パッチ適用後にsetHeaderがthrowする破壊的変更と回避策のloose/strictモード

axios 1.15.0のassertValidHeaderValueによる検証強化は、セキュリティ上は正しい対応ですが、既存のコードベースに影響を与える破壊的変更（breaking change）を含んでいます。パッチ適用後、ヘッダー値に改行文字を含むリクエストを送信しようとすると、従来は暗黙的に送信されていたリクエストがTypeErrorで失敗するようになります。実際にmdn-http-observatoryプロジェクトでは、1.15.0へのアップグレード後にsetHeader()がスローするエラーが報告されました。この問題に対し、axiosのメンテナーは今後のリリースでloose/strictモードの導入を計画しています。looseモード（新しいデフォルトになる見込み）ではCRLF文字を検出した際にスローするのではなくサニタイズ（除去）する動作になり、strictモードでは現行の1.15.0と同様にスローします。1.15.0へのアップグレードで既存のテストが失敗する場合は、ヘッダー値に意図せず改行文字が含まれている箇所を修正するのが根本対策です。一時的な回避策としてtry-catchでエラーをハンドリングすることも可能ですが、その場合は該当リクエストのヘッダー値に不正な文字が含まれている根本原因を併せて調査すべきです。

npm auditとlockfile確認で自社環境の影響有無を特定する実務手順

脆弱性の技術的な理解が完了したら、次は自社プロジェクトが実際に影響を受けているかどうかを特定する実務フェーズに入ります。CVE-2026-40175への対応と、3月31日のサプライチェーン攻撃への対応では確認すべきポイントが異なるため、それぞれの手順を整理します。

npm ls axiosコマンドで依存ツリー内の全バージョンを一覧表示する手順

最も基本的な確認手順は、プロジェクトディレクトリでnpm ls axiosを実行することです。このコマンドは依存ツリー内のすべてのaxiosインスタンスを階層表示し、各インスタンスのバージョンとそこに至る依存パスを表示します。出力に[email protected]未満のバージョンが含まれていれば、CVE-2026-40175の影響を受けます。yarnを使用している場合はyarn why axiosで同様の情報が得られ、pnpmではpnpm why axiosが対応するコマンドです。注意点として、npm lsはインストール済みのnode_modulesを参照するため、node_modulesが存在しない環境ではlockfileから情報を取得する必要があります。また、モノレポ構成では各ワークスペースで個別に実行するか、ルートでnpm ls axios --all（npm 8以降）を使用します。出力が大量になる場合はnpm ls axios 2>&1 | grep -v 'deduped'で重複除外済みの表示を排除し、実際にインストールされているバージョンの一覧を確認するのが効率的です。加えて、devDependenciesのみでaxiosを使用している場合でも、CIパイプラインやビルド環境で実行される可能性があるため、対応対象から除外すべきではありません。

grep -Eによるlockfile検索でaxios 1.14.1と0.30.4の混入を即座に検出する方法

サプライチェーン攻撃の影響確認では、悪意あるバージョン（1.14.1と0.30.4）がlockfileに記録されていないかを検索します。npmプロジェクトではgrep -E '1\.14\.1|0\.30\.4' package-lock.jsonを実行し、yarnではgrep -E '1\.14\.1|0\.30\.4' yarn.lock、bunではgrep -E '1\.14\.1|0\.30\.4' bun.lockを使用します。さらに、悪意ある依存パッケージplain-crypto-jsの存在確認も重要です。grep 'plain-crypto-js' package-lock.jsonで検出された場合は、サプライチェーン攻撃の直接的な影響を受けている可能性が極めて高く、当該マシンを侵害済みとして扱う必要があります。lockfileだけでなく、開発者のローカル環境やCIランナーのnode_modulesディレクトリも確認対象です。find / -name 'plain-crypto-js' -type d 2>/dev/nullでファイルシステム全体を検索し、攻撃パッケージの痕跡がないかを調査します。ただし、攻撃パッケージはアンチフォレンジック処理で自身を削除するため、痕跡が見つからないからといって安全とは断定できません。侵害時間帯（2026年3月31日 00:21〜03:29 UTC）にnpm installが実行された形跡がある場合は、lockfileの内容にかかわらず侵害の可能性を考慮すべきです。

Snyk testとnpm auditの検出精度を比較した場合の得意領域と検出漏れの差

脆弱性スキャンツールの選択は、検出精度と運用コストのバランスで決まります。npm auditはnpmに組み込まれた無料ツールで、GitHub Advisory Databaseを参照して既知の脆弱性を検出します。CVE-2026-40175はGitHub Advisoryに登録済みのため、npm auditで検出可能です。一方、snyk testはSnyk独自の脆弱性データベースを使用し、推移的依存の脆弱性やライセンスリスクもカバーします。

実務上の推奨は、CI/CDパイプラインにnpm audit --audit-level=criticalを組み込んで自動チェックを行いつつ、Snykの無料枠やDependabotで継続的な監視を併用する体制です。npm auditだけでは検出漏れが生じうるケースとして、Advisory登録が遅れた脆弱性や、npmレジストリ側で削除された悪意あるパッケージの検出があります。複数ツールの併用によって検出漏れのリスクを低減できます。

CI/CDパイプラインのビルドログから侵害時間帯のinstall実行を特定する手順

サプライチェーン攻撃の影響調査で最も重要なのは、悪意あるバージョンが公開されていた時間帯（2026年3月31日 00:21〜03:29 UTC）にnpm installまたはnpm ciが実行されたかどうかの確認です。調査手順を以下に示します。

1. CI/CDプラットフォーム（GitHub Actions、GitLab CI、Jenkins、CircleCIなど）のビルド履歴から、3月30日〜31日のビルドジョブを抽出する
2. 各ジョブのログでnpm install、npm ci、yarn install、pnpm installの実行タイムスタンプを確認する
3. 侵害時間帯にインストールが実行されていた場合、そのビルドで使用されたaxiosのバージョンをログから特定する
4. CIランナーが永続的な環境（セルフホステッドランナーなど）の場合、node_modules内にplain-crypto-jsの痕跡がないかを確認する
5. GitHub Actionsのホステッドランナーのように毎回環境が再構築される場合でも、ビルド成果物（Dockerイメージ、デプロイパッケージ）に悪意あるコードが含まれていないかを確認する

特に注意が必要なのは、npm ciではなくnpm installを使用しているCI環境でしょう。npm ciはlockfileを厳密に再現するため、lockfileが侵害前にコミットされていれば影響を受けません。しかしnpm installはlockfileを更新する動作を含むため、侵害時間帯に実行された場合、悪意あるバージョンに解決された可能性があります。

sfrclak[.]comへのアウトバウンド通信をネットワークログから検出するIOC一覧

サプライチェーン攻撃のRAT通信を検出するためのIOC（Indicator of Compromise）を整理します。C2サーバーのドメインはsfrclak[.]comであり、IPアドレスについてはMicrosoftが142.11.206[.]72、Google GTIGのDNS解決分析では142.11.206[.]73と報告しているため、両方をブロック対象に含めるべきでしょう。通信ポートは8000番です。RAT通信のUser-Agent文字列はmozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)という2026年時点では極めて不自然なInternet Explorer 8の文字列であり、ネットワークログでのフィルタリングに有効な特徴です。C2通信のURLパスは/6202033というキャンペーン識別子を使用しており、POSTボディにはnpmレジストリ通信を偽装したpackages.npm.orgプレフィックスが含まれます。ファイアウォールやプロキシのログでsfrclak[.]comまたは142.11.206[.]72/142.11.206[.]73のポート8000への接続が検出された場合、当該マシンは侵害済みと判断してネットワークからの即時隔離、クリーンバックアップからの再イメージ化、すべての認証情報のローテーションが必要です。EDR（Endpoint Detection and Response）製品を導入している環境では、各ベンダーがこのIOCに対応した検出ルールをリリースしているため、最新の検出定義に更新されているかを確認してください。

axios 1.15.0へのアップグレードと依存関係の安全な移行における注意点

CVE-2026-40175への根本対策は、axiosをバージョン1.15.0以上にアップグレードすることです。しかし、メジャーバージョンの互換性、パッケージマネージャの挙動の違い、推移的依存の固定化、パッチによる破壊的変更への対処など、アップグレード作業には複数の注意点があります。安全かつ確実にアップグレードを完了するための実務手順を整理します。

npm install [email protected]実行前に確認すべきNode.jsバージョンとの互換性

axios 1.15.0のセキュリティ修正で導入されたassertValidHeaderValue関数は標準的なJavaScript機能のみを使用しているため、Node.jsバージョン固有の互換性問題は基本的に発生しません。ただし、axiosの1.x系はNode.jsのサポート終了（EOL）済みバージョンでの動作保証がないため、Node.js 18以上の現行LTSバージョンを使用している環境でのアップグレードが推奨されます。アップグレード前の確認手順として、まずnode -vでNode.jsバージョンを確認し、EOL済みのバージョンであればNode.jsのアップグレードを先行させてください。次にnpm outdated axiosで現在のaxiosバージョンと最新バージョンの差分を確認します。1.x系の範囲内でのアップグレード（たとえば1.7.xから1.15.0）であればセマンティックバージョニング上はマイナーアップグレードに該当しますが、セキュリティ修正に伴う動作変更があるためテストの実行は必須です。npm install [email protected]を実行後、npm ls axiosで依存ツリー内のすべてのaxiosインスタンスが1.15.0に更新されたことを確認し、テストスイートを実行してヘッダー関連のエラーが発生していないかを検証してください。

yarn・pnpm・bunなどパッケージマネージャ別のアップグレード手順と差異

パッケージマネージャによってアップグレードの手順と挙動に違いがあるため、自社プロジェクトで使用しているツールに応じた対応が必要です。yarnを使用している場合はyarn upgrade [email protected]で直接依存のバージョンを更新できます。yarn.lockは自動的に更新されますが、推移的依存のaxiosはこのコマンドでは更新されない場合があるため、yarn why axiosで確認が必要です。pnpmではpnpm update [email protected]が対応するコマンドとなっています。pnpmは厳格なnode_modules構造（コンテンツアドレッサブルストレージ）を採用しているため、推移的依存の重複が発生しにくく、axiosのバージョン統一が比較的容易です。bunではbun update axiosで最新バージョンに更新できます。bunのlockfileはバイナリ形式のため、テキストベースのgrep検索にはbun.lockのテキスト出力（bun v1.1以降で対応）を使用します。いずれのパッケージマネージャでも、アップグレード後にlockfileをコミットし、CI/CDパイプラインでnpm ci（または各マネージャの再現可能インストールコマンド）が正常に完了することを確認するまでがアップグレード作業の範囲です。

overridesとresolutionsを使って推移的依存のaxiosも強制更新する設定方法

直接依存のaxiosを更新しても、推移的依存として古いバージョンのaxiosが残存するケースがあります。たとえば、社内のnpmパッケージや特定のSDKがaxios@^1.6.0のように古いバージョン範囲を指定している場合、そのパッケージが更新されるまで脆弱なバージョンが依存ツリーに残り続けてしまうのです。この問題を強制的に解決するには、パッケージマネージャのオーバーライド機能を使用します。npmでは、package.jsonに"overrides": {"axios": "1.15.0"}を追加することで、依存ツリー内のすべてのaxiosを強制的に1.15.0に固定する方法が有効でしょう。yarnでは"resolutions": {"axios": "1.15.0"}が同等の機能を持ちます。pnpmでは"pnpm": {"overrides": {"axios": "1.15.0"}}をpackage.jsonに記述する形式です。ただしオーバーライド機能はAPIの互換性を保証しないため、推移的依存がaxiosの古いAPIに依存している場合に実行時エラーが発生する可能性があります。オーバーライド適用後は必ず統合テストを実行し、すべての外部API通信が正常に動作することを確認してください。オーバーライドはあくまで緊急措置であり、推移的依存元のパッケージが正式にaxios 1.15.0以上に対応した時点でオーバーライド設定を解除し、通常の依存解決に戻すことが推奨されます。

1.15.0のヘッダー検証厳格化で既存コードがエラーになる3つの破壊的変更

axios 1.15.0のセキュリティ修正により、以下の3つのパターンで既存コードがエラーを起こす可能性があります。第一に、ヘッダー値にCR（\r）やLF（\n）を意図的に含めているケースです。一部のレガシーAPIとの連携で改行を含むヘッダー値を送信していた場合、assertValidHeaderValueがTypeErrorをスローします。第二に、外部ソースから取得した値をバリデーションなしにヘッダーに設定しているケースです。データベースや環境変数から取得した値に予期しない改行文字が含まれている場合にエラーが発生します。第三に、テストコードでモックヘッダーに改行文字を含めているケースです。テストの期待値として設定していたヘッダー値が1.15.0の検証に引っかかり、テストが失敗します。これらの問題に対する根本対策は、ヘッダー値を設定する前にString(value).replace(/[\r\n]/g, '')でサニタイズ処理を追加することです。axiosのメンテナーが計画しているlooseモードが実装されるまでの間、この手動サニタイズが最も確実な回避策となります。破壊的変更によるテスト失敗を理由にアップグレードを遅延させることは、CVSS 10.0の脆弱性を放置するリスクと比較して許容できない判断です。

ロールバック先に1.14.0を選ぶ場合にCVE-2026-25639のDoS修正を確認すべき理由

サプライチェーン攻撃後のインシデント対応で、多くのガイダンスがaxios 1.14.0を安全なロールバック先として推奨しました。1.14.0は悪意あるバージョン1.14.1の直前のリリースであり、サプライチェーン攻撃の影響を受けていない正規バージョンです。しかし、1.14.0にはCVE-2026-40175の脆弱性が存在するため、ロールバック先としては不十分です。さらに考慮すべき点として、axiosの脆弱性履歴があります。CVE-2026-25639はmergeConfig関数で__proto__をown propertyとして持つオブジェクトを処理した際にTypeErrorでクラッシュするDoS脆弱性であり、1.13.5と0.30.3で修正されました。1.14.0はこの修正を含んでいるため、DoSに関しては安全です。一方、0.xブランチでロールバック先を検討する場合、0.30.3がDoS修正を含む最新の安全バージョンですが、CVE-2026-40175の修正は含まれていません。最終的な推奨は、ロールバック先として1.14.0を一時的に使用しつつ、可能な限り速やかに1.15.0へのアップグレードを完了することです。ロールバックはあくまでサプライチェーン攻撃への緊急対応であり、脆弱性対策のゴールはあくまで1.15.0以上へのアップグレードであることを組織内で明確にしておく必要があります。

Prototype Pollution Gadget攻撃の再発を防ぐサプライチェーン防御体制

CVE-2026-40175とサプライチェーン攻撃は、JavaScriptエコシステムにおけるサプライチェーンセキュリティの脆弱性を複合的に露呈しました。個別の脆弱性対応を完了した後は、同様のインシデントの再発を防ぐための構造的な防御体制の構築が必要です。パッケージマネージャの設定変更、ビルドパイプラインの強化、代替ライブラリの評価まで、長期的な対策を整理します。

pnpm v10のpostinstallスクリプト制限がaxios型攻撃を構造的に遮断する仕組み

axiosサプライチェーン攻撃の感染経路は、npmのpostinstallライフサイクルフックを通じた自動コード実行でした。このクラスの攻撃を構造的に防ぐ手段として、pnpm v10が導入したインストールスクリプト制限が注目されています。pnpm v10では、デフォルトで依存パッケージのpostinstallスクリプトが実行されません。正当なビルドスクリプトが必要なパッケージ（ネイティブモジュールのコンパイルなど）は、package.jsonのpnpm.onlyBuiltDependenciesで明示的に許可リストに登録する必要があります。この設計は暗黙的な信頼（implicit trust）から明示的な承認（explicit approval）へのパラダイムシフトであり、未知のパッケージがインストール時にコードを実行するリスクを根本的に排除できるようになりました。npm自体にも--ignore-scriptsオプションがありますが、これはすべてのスクリプトを無効化するため、正当なpostinstallスクリプトも動作しなくなり、実用上の制約が大きくなります。pnpmの許可リスト方式は、セキュリティと実用性のバランスが取れた解決策です。プロジェクトの依存管理をnpmからpnpmに移行することを検討する価値がある、という評価がセキュリティコミュニティで広がっています。

SLSA Level 2以上のビルド証明とOIDC Trusted Publishingの導入手順

axiosサプライチェーン攻撃では、悪意あるバージョンにOIDCプロヴナンスメタデータとSLSAビルド証明が含まれていなかったことが侵害検出の重要な手がかりとなりました。SLSA（Supply-chain Levels for Software Artifacts）はビルドプロセスの信頼性を段階的に保証するフレームワークで、Level 2以上ではビルドがCI/CDサービス上で実行され、ビルドプロセスの改ざん防止と証明が提供されます。npmパッケージにSLSA Level 2を適用するには、GitHub Actionsの--provenanceフラグを使用したパッケージ公開が基本的な手段となるでしょう。これにより、公開されたパッケージにはGitHub Actionsのワークフロー実行情報、リポジトリのコミットハッシュ、ビルド環境の情報が暗号的に署名されたプロヴナンス情報として付与されます。OIDC Trusted Publishingを正しく機能させるには、長寿命のNPM_TOKENをCI/CD環境から完全に削除することが不可欠です。axiosの事例で判明したとおり、OIDC認証とトークン認証が共存する場合、npmはトークンを優先して使用するため、OIDCの保護効果が無効化されます。設定手順は、npmレジストリでTrusted Publisher設定を有効化し、GitHub Actionsワークフローのpublishステップで--provenanceを付与し、NPM_TOKENシークレットを削除するという3段階です。

Object.freezeによるprototype凍結が実務で有効なケースと性能への影響

Prototype Pollution攻撃そのものを防ぐ防御的プログラミング手法として、Object.freeze(Object.prototype)によるプロトタイプの凍結があります。この処理をアプリケーションの起動時に実行すると、Object.prototypeへのプロパティ追加や変更がすべて拒否（strictモードではTypeErrorをスロー）されるため、Prototype Pollutionの発生自体を未然に防ぐことが可能です。ただし、この手法を本番環境に適用するにはいくつかの注意点を考慮しなければなりません。Object.prototypeを凍結すると、Object.prototypeを拡張しているライブラリ（ポリフィルやレガシーフレームワーク）が動作しなくなる可能性があります。パフォーマンスへの影響については、V8エンジンの最適化により、Object.freeze自体のオーバーヘッドは無視できるレベルです。ただし、凍結後にプロトタイプへの書き込みが頻繁に試行される環境では、strictモードでの例外スローがパフォーマンスに影響する可能性があります。実務上この手法が有効なのは、依存ライブラリがObject.prototypeの拡張に依存していない新規プロジェクトや、マイクロサービスとして独立した小規模なNode.jsアプリケーションです。既存の大規模プロジェクトに後から適用する場合は、テストスイートでの互換性検証が不可欠であり、段階的な導入が推奨されます。

Dependabotと手動監査を併用して重要パッケージの異常公開を検知する運用例

依存パッケージの脆弱性を継続的に監視する体制として、GitHubのDependabotとnpm auditの自動実行、そして手動監査の併用が実践的な運用モデルです。Dependabotは依存パッケージの脆弱性アラートとセキュリティアップデートPRを自動生成しますが、サプライチェーン攻撃のようなリアルタイムの侵害には対応が遅れる場合があります。そこで補完的な対策として、重要パッケージ（axiosのように週間DL数が多いもの）に対する異常検知の仕組みが求められるでしょう。具体的には、CIパイプラインにnpm audit signaturesを追加してレジストリ署名の検証を行い、プロヴナンスメタデータが欠落しているパッケージのインストールを拒否するルールを設定します。さらに、Socketなどのサプライチェーンセキュリティ専門ツールを導入し、新しいバージョンのパッケージが通常の公開パターンから逸脱している場合（メンテナーのメールアドレス変更、CI/CDバイパス公開、新規依存の追加など）にアラートを発報する体制を整えることも効果的です。手動監査としては、四半期ごとにnpm ls --depth=0で直接依存の棚卸しを行い、不要になったパッケージの除去や代替パッケージへの移行を検討するサイクルを回すことが重要です。

fetchやky・got・undicなどaxios代替ライブラリへの移行判断と比較基準

axiosに繰り返し脆弱性が発見されている現状を踏まえ、代替ライブラリへの移行を検討する動きがあります。移行判断の基準として、API互換性、依存関係の軽量さ、セキュリティ実績、メンテナンス体制の4つの観点を踏まえて主要な選択肢を比較してみましょう。

Node.js 18以降の環境であれば、グローバルfetch APIがネイティブで利用可能なため、外部ライブラリへの依存自体を排除できます。fetch APIはaxiosのようなインターセプターやリクエスト/レスポンス変換機能を持ちませんが、基本的なHTTP通信には十分です。より高機能なHTTPクライアントが必要な場合は、Node.jsコアチームが推進するundicが高性能かつセキュリティ面で信頼性の高い候補となるでしょう。ただし、axiosからの移行はAPI呼び出し箇所の全面的な書き換えを伴うため、大規模プロジェクトではコストとリスクの慎重な見積もりが求められます。短期的にはaxios 1.15.0へのアップグレードで脆弱性を解消し、中長期的な技術ロードマップとして代替ライブラリへの段階的移行を計画するのが現実的なアプローチです。