10/10 Axios CVEパニック：誇大広告を監査してパッチを適用した理由
Axiosの重大な欠陥によってAWS認証情報が盗まれる可能性があるというニュースが報道されたとき、私たちのチームは単にアップデートを実行しただけでなく、ランタイムロジックを掘り下げて脅威が実際に存在するのかどうかを確認しました。
JavaScriptの世界でしばらく過ごしたことがあるなら、「axios」に触れたことがあるでしょう。これは Node.js の HTTP リクエストのデフォルト設定です。これは非常に一般的なので、通常は言語そのものの一部のように扱われます。しかし、数週間前、業界は集団崩壊に陥りました。Axiosの10/10の重大な脆弱性（CVE-2026-40175）が話題になり始めました。この脆弱性により、攻撃者が AWS のセキュリティを迂回してクラウド認証情報を盗むことが可能になったとされています。
Sweentでは、「10/10」が下がったときの最初の措置は、ポートフォリオ全体の監査を開始することです。エンタープライズダッシュボードを管理する場合でも、レガシーアプリケーションスタックの最新化を行う場合でも、火災が発生したことを知らせる自動アラートを待つ必要はありません。私たちはまず自分たちで煙を探し始めます。しかし、この特定の脆弱性を掘り下げてみると、センセーショナルな見出しが見逃していたことが分かりました。最近のほとんどのアプリケーションでは、エクスプロイトは到着した時点で無効でした。
恐怖の解剖学
この脆弱性は「ガジェットチェーン」と呼ばれていました。この用語に慣れていない場合は、ハッカー向けのルーブ・ゴールドバーグ・マシンのようなものだと考えてください。最後の爆発が起こるには、特定の順序で複数の異なる問題が発生する必要があります。
理論的には、チェーンは次のようになっていました。
-攻撃者は、アプリケーションのプロトタイプ汚染を引き起こす方法を見つけます。
-Axios は内部構成をマージする際に、汚染された値を検出します。
-これらの値には、ヘッダーに挿入された CRLF (キャリッジリターンラインフィード) 文字が含まれます。
-これらのヘッダーは、サーバーを騙して「リクエストスマグリング」またはサーバーサイドリクエストフォージェリ (SSRF) に仕向けます。
-攻撃者はその SSRF を利用して AWS インスタンスメタデータサービス (IMDSv2) を攻撃し、クラウド認証情報を盗み出します。
-紙の上では、これは悪夢のようなシナリオです。攻撃者がネットワーク内から「169.254.169.254」に到達できれば、攻撃者はインフラストラクチャを所有していることになります。ただし、ここで問題となるのは、理論と本番環境は 2 つの点でまったく異なるということです。
-ランタイムがおそらくあなたを救った理由監査を実施したところ、このエクスプロイトが依存している核となる原始的な CRLF ヘッダーインジェクションは、Node.js がランタイムレベルで長年ブロックしてきたものであることがわかりました。Axios はネットワーク自体でバイトを送信するのではなく、Node.js に組み込まれた http モジュールを使用します。このエクスプロイトを標準環境で再現しようとしたところ、壁にぶつかり続けました。具体的には、「タイプエラー [ERR_INVALID_CHAR]」です。改行文字を含むヘッダー値を http.request () に渡そうとすると、Node.js はリクエストがサーバーを離れる前にエラーを投げます。基盤となるエンジンが駆動を拒否しても、Axios の設定がどれほど「汚れ」ても問題ありません。確認したところ、BunとDenoにも同じ保護策があります。これは、ライブラリは技術的には脆弱だが、環境は安全であるという典型的なケースです。ラウル・ベガ・デル・ヴァッレのような研究者の調査結果も調べました。彼の研究により、私たちの研究室で見たことが裏付けられました。実際のプロダクションアプリケーションでは、インタプリタがそれを止めてしまうため、このチェーンにたどり着くことはほとんど不可能です。では、なぜ10点満点なのでしょう？CVE スコアは、パッチが適切に適用された Node 20.x クラスターではなく、考えられる最悪の環境を想定しているためです。
スイート監査
自動スキャンの他にも、ランタイムがエクスプロイトをブロックするのになぜわざパッチを適用したのかと疑問に思われるかもしれません。答えは簡単です。私たちは、セキュリティを 1 つの防御層だけに賭けているわけではありません。Node.js に頼ってライブラリのミスをキャッチするのは悪い習慣です。私たちのチームは、すべてのアクティブなプロジェクトの「package-lock.json」ファイルと「yarn.lock」ファイルを手動で確認しました。私たちは axios のバージョン番号だけを探したわけではありません。コードが実際にネットワークとどのように相互作用するかを調べました。Dependabot のような自動化ツールは優れていますが、コンテキストを理解できません。組み込みのノード保護をバイパスするようなカスタムアダプタを作成したかどうかは、彼らにはわかりません。
-カスタムアダプターを確認しました。アプリケーションが Node.js の http クライアントをバイパスするカスタム Axios アダプターを使用する場合 (未処理のリクエストをソケットに直接書き込む場合など)、ランタイム保護は無効になります。
-プロトタイプの汚染リスクを調べました。アプリがプロトタイプの汚染の影響を受けやすい場合は、単なる Axios のバグよりもはるかに大きな問題が発生します。「JSON.parse」とオブジェクトマージの処理方法を全面的に監査しました。
-AWS の設定を検証しました。SSRF が発生した場合でも、プロジェクトではホップ制限が厳しい IMDSv2 を使用するようにしています。これにより、たとえインジェクションが成功しても、クレデンシャルの盗難は非常に困難になります。
-ヘッダーがどのように構成されているかを調べました。ユーザー入力がヘッダーキーや値にサニタイズされずに触れる可能性がある場所を探しました。
この24時間の時間枠の間に、すべてのプロジェクトをAxios 1.15.0以降に移行しました。「アラート疲れ」が開発チームを悩ませているのを目の当たりにしてきました。彼らは週に100件の通知を受け取り、そのほとんどはリスクの低い開発依存関係に関するものですが、彼らはそれを無視し始めます。セキュリティは、ノイズがシグナルをかき消さないように、手作業で優先度の高いエンジニアリングタスクとして扱っています。
サプライチェーンの厄介な現実
この CVE は、はるかに恐ろしいもう 1 つの Axios インシデント、つまり実際にリモートアクセス型トロイの木馬 (RAT) をデプロイしたメンテナーアカウントのハイジャックに続いて発生しました。それは本物のサプライチェーン攻撃でした。これは、4 回一致しないと機能しない「ガジェットチェーン」ではなく、ビルドパイプラインで実行されている悪質なコードでした。
この 2 つを比較すると、現代のエンジニアリングにおける大きな問題が浮き彫りになります。業界は、理論上のライブラリレベルのバグには過剰反応する一方で、アカウントの侵害にはあまり反応しない傾向があります。プライマリーメンテナの npm アカウントで 2FA を有効にしていないという事実よりも、理論上の SSRF について話すことに多くの時間を費やしました。
正気を保つ唯一の方法は、インストールしたバージョンと最新のパッチが適用されたバージョンとの差をできるだけ小さくすることです。しかし、やみくもに npm update を実行することはできません。「マイナーな」更新でプロダクションヘッダが壊れたり、タイムアウトの処理方法が変わったりするのを見てきました。これが、当社の CI/CD パイプラインに回帰テストとセキュリティゲートが含まれている理由です。更新によって 1 つの単体テストが失敗すると、先に進めません。
##「重大」バグが重大でないのはどのような場合ですか？
この CVE の「10/10」評価は、絶対的に最悪のシナリオに基づいたものです。攻撃者がすでにアプリのプロトタイプを侵害していて、奇妙なカスタムネットワークスタックを使用していて、クラウドメタデータが広く公開されていると仮定した場合、そうです、10 です。しかし、平均的な開発者にとっては？依存関係を整理しておくことを思い出させてくれます。
2022年以降「package.json」が変更されていないレガシープロジェクトを引き継ぎました。これは大きな負債です。古くなった荷物はすべてドアのロックが解除されたままです。私たちは、なぜこれらの監査が重要なのかをパートナーに伝えることに力を入れています。すべての見出しを追いかけることではなく、本番環境でどのコードが実行されているのか、またその理由を正確に知ることが重要です。
正直に言うと、Axios は肥大化しつつあります。これは素晴らしいツールですが、古いブラウザやNodeバージョンをサポートするためにレガシーに重きを置いています。場合によっては、最善のセキュリティ修正はパッチではなく、最新の Node ランタイムを使用している場合はネイティブの fetch API に切り替えることです。機能は少ないですが、攻撃対象領域もはるかに小さくなります。
私たちのテイクアウト
セキュリティは「一度設定したらあとは忘れる」機能ではありません。これは絶え間ない検証プロセスです。実際に悪用される可能性は低いものの、公開から数時間以内にすべての内部システムと管理対象プラットフォームにパッチが適用され、検証されたことを報告できて嬉しく思います。
ニュースで言われたからといって、パッチを適用しただけではありません。パッチを適用したのは、ランタイムが安全でない値をキャッチしたとしても、ライブラリ自体が許容すべきではないからです。これは多層防御の問題です。最初の防衛線 (Axios) に障害が発生すると、2 番目の防衛線 (Node.js) がそれをキャッチします。2 番目が失敗すると、3 番目 (AWS IMDSv2) が賞品をブロックします。こうすることで、あるライブラリで調子が悪くなっても倒れないシステムを構築できます。
自分の依存関係ツリーが気になる場合や、現在のチームがこれらの微妙な違いを理解しているかどうかわからない場合は、今すぐ package-lock.json を確認したほうがいいでしょう。リスクにさらされたらボットに知らせてもらっているのか、それともランタイムを実際に理解しているチームがあるのか？
よくあるご質問
10/10のスコアは、プロトタイプの汚染がすでに発生していて、CRLFインジェクションがすり抜け、ネットワークアダプターが標準のNodehttpモジュールではなく、クラウドメタデータにアプリプロセスからアクセスできる環境など、絶対的に最悪のケースを反映しています。実際には、ヘッダーに改行が含まれていると、Node.js (および Bun と Deo) は TypeError [ERR_INVALID_CHAR] を投げます。そのため、AWS 認証情報が危険にさらされるずっと前に、チェーンはランタイムレイヤーで停止します。CVE スコアリングでは、実際の環境ではなく、最も危険で妥当な環境を想定しています。
はい—多層防御。ライブラリレベルの間違いは、その後に下のレイヤーがクリーンアップされるからといって許されるべきではありません。将来の Axios リファクタリング、http モジュールをバイパスするカスタムアダプター、または代替ランタイムによって、このセーフティネットは一夜にして削除される可能性があります。1.15.0以降へのパッチ適用は安価です。作成しなかったフォールバックによっては、失敗するとコストがかかります。
まず、ロックファイル (package-lock.json または yarn.lock) から始めて、package.json が宣言している内容だけでなく、どのバージョンが実際に解決されているかを確認します。次に、ライブラリがどのように使用されているかを監査します。たとえば、カスタムHTTPアダプター、ユーザー入力によるヘッダー構築、プロトタイプ汚染を漏洩する可能性のあるオブジェクトマージパス、クラウドメタデータのエンドポイント（AWSではホップ制限が厳しいIMDSv2）がSSRFに到達しても認証情報の盗難をブロックするかどうかなどです。Dependabot はバージョンを確認し、実際の監査では実行時の動作を確認します。
運用上、はい。ガジェットチェーンのCVEが着陸するには4つの偶然が必要です。侵害されたメンテナアカウントは、ビルドパイプラインで実行される悪意のあるコードであり、チェーンは必要ありません。この攻撃は、私たちが実際に眠れなくなったものです。より大まかに言えることは、ライブラリレベルのすべての CVE スコアを追いかけることよりも、npm、パッケージ署名、および固定パッチバージョンの 2FA の方が重要だということです。
最近のノード (18 歳以上) やブラウザでは、これが現実的な選択肢です。fetch の API サーフェスははるかに小さく、ランタイムに同梱されており、レガシーの重みも少なくなっています。トレードオフ:デフォルトのインターセプターがない、エラー処理エルゴノミクスが異なる、AbortController なしではリクエスト/レスポンスのタイムアウトが組み込まれない。新しいプロジェクトの場合は、移行する価値があることがよくあります。すでに axios @1 .15.0+ にインストールされている安定したコードベースでは、ランタイム保護と統制のとれた更新で問題ありません。