NPMパッケージのハイジャックは、パッケージへの信頼を攻撃経路として利用するソフトウェアサプライチェーン攻撃の一種です。攻撃者は、パッケージを公開しているアカウントを制御できれば、リポジトリのコードを改変する必要はありません。
だからこそ、信頼されているnpmパッケージは極めて大きな攻撃対象領域となるのです。メンテナンス担当者のアカウントが侵害されると、その影響を受けるパッケージをインストールしているすべてのプロジェクトが、通常の依存関係更新を通じて危険にさらされる可能性があります。2026年3月のAxiosの事例は、1つのnpmアカウントが侵害されただけで、axiosのソースコードに目に見える変更を加えることなく、週1億回以上のダウンロードが危険にさらされる可能性があることを示しました。
npmパッケージのハイジャックがどのように機能するかを理解することで、セキュリティチームは、多くのチームが検証対象としているソースファイルだけでなく、実際の攻撃経路に対処する対策を構築できるようになります。
Axiosのnpm攻撃で何が起きたのか
Axiosのnpm攻撃は、メンテナンス担当者のアカウントが乗っ取られ、信頼されていたパッケージがマルウェアの配布手段へと変貌した事件です。攻撃者はAxiosの主要なメンテナンス担当者のnpmアカウントを乗っ取り、登録メールアドレスを攻撃者が管理するアドレスに変更し、正当なメンテナンス担当者をアカウントから締め出しました。
この攻撃は周到に計画されたものでした。実害をもたらすコードが有効化される約18時間前に、おとりとなるパッケージが公開され、直ちに不審に思われないよう公開履歴が作成されました。その後、約39分の間に、攻撃者は2つの悪意のあるバージョンを公開しました。それは、最新リリースブランチ向けのaxios 1.14.1と、レガシーブランチ向けのaxios 0.30.4です。
両方のリリースラインを同時に対象としたのは、露出を最大化するためでした。この選択により、標準的な更新処理を通じて、現行環境とレガシー環境の両方で、改ざんされたパッケージが取り込まれる可能性が高まりました。
package.json の一行が、いかにして攻撃の入り口となったのか
package.json における単一の依存関係の変更が、npm サプライチェーン攻撃における攻撃経路全体となる可能性があります。Axios のインシデントでは、悪意のある動作が新しい依存関係を通じて導入されたため、axios のソースファイルを変更する必要はありませんでした。
その依存関係は、npmのpostinstallフックを通じて実行されました。開発者のワークステーション、CI/CDパイプライン、またはビルドシステムでnpm installが実行されるとすぐに、悪意のあるパッケージは攻撃者が制御するサーバーに接続し、OS固有のペイロードを取得して、実行を開始することができました。
ペイロードはmacOS、Windows、Linux向けに作成された。この攻撃は設計上、クロスプラットフォーム対応となっていた。実行後、ドロッパーは自身の痕跡を消去し、本物のpackage.jsonを改ざんされたバージョンに置き換えたため、その後のフォレンジック調査が著しく困難になった。
なぜ従来のコードレビューではAxiosへの攻撃を検知できなかったのか
従来のコードレビューは、リポジトリ内のソースコードの変更を検査するために設計されていますが、今回の攻撃経路はAxiosのソースコードには存在しませんでした。Axiosへの攻撃は、悪意のあるロジックがAxiosのソースコードではなく別の依存関係内に存在していたため、目に見えるリポジトリの変更には依存していませんでした。
その違いは重要です。パッケージの更新内容を確認するレビュー担当者は、package.json に新しい依存関係が追加されていること以外、ほとんど何も気づかないでしょう。実際の悪意のある動作は、その依存関係が解決され、インストールされたときに初めて現れるのです。
これが、diffベースのレビューだけでは信頼できるパッケージによる攻撃を検知するのが難しい理由です。この攻撃経路は、ほとんどのチームが検査するソースファイルの外側に存在するため、そのパッケージは通常の開発ワークフローを通過できるほど十分に正当なものに見えてしまうのです。
なぜ爆風範囲は、パッケージが触れるすべてのものを巻き込むのか
脆弱性が発見されたnpmパッケージの影響範囲は、そのパッケージ自体ではありません。影響範囲とは、そのパッケージが関与するすべてのものです。
多くの組織において、これには、高い権限を持つCI/CDパイプライン、SSHキーやクラウドトークンを使用する開発者向けエンドポイント、アーティファクトリポジトリへの書き込み権限を持つビルドサーバー、そして本番システムに接続されたデプロイメントツールなどが含まれます。悪意のあるパッケージは、被害をもたらすために依存関係ツリー内に留まる必要はありません。必要なのは、信頼された実行ポイントが1つあることだけです。
だからこそ、Axiosの件は単なるJavaScriptパッケージ管理の問題にとどまらないのです。postinstallを悪用された場合、通常のインストール操作が、認証情報の窃取、横方向の移動、あるいは下流のインフラへのアクセスへとつながりかねません。
Axiosへの攻撃が露呈した構造的な脆弱性
Axiosの件は、現代のソフトウェア開発環境に共通する構造的な弱点を浮き彫りにした。これらは決して稀な例外事例ではない。多くの組織において、これらは当たり前の前提となっているのだ。
パッケージメンテナの身元に対する信頼
npmパッケージへの信頼は、多くの場合、そのパッケージを公開しているメンテナンス担当者のアカウントに基づいています。もしそのアカウントが乗っ取られたり、フィッシング被害に遭ったりした場合、攻撃者は正当なメンテナンス担当者と同じ公開権限を継承することになります。
依存関係のバージョンの変動
フローティング版やピン留めが緩いバージョンの範囲が広くなると、悪意のあるリリースへの曝露リスクが高まります。新たに公開された改ざんされたバージョンが、意図的な承認プロセスを経ることなく、自動的に環境内に侵入する可能性があります。
インストール後の監視対象外スクリプト
npmのpostinstallスクリプトは、インストールプロセスの権限で任意のコードを実行することができます。多くの組織では、ライフサイクルスクリプトの実行前にその内容を検査したり制限したりしていません。
実行時の可視性が限定されたCI/CDパイプライン
CI/CDパイプラインは、多くの場合、社内システム、ビルドインフラストラクチャ、およびクラウド環境への広範なアクセス権限を有しています。こうしたパイプラインは、デフォルトで信頼されていることが多く、インストール時の悪意のあるパッケージの挙動について監視されることはほとんどありません。
完全なセキュリティ対策の対象外となる開発者向けエンドポイント
開発者のマシンには、SSHキー、クラウドの認証情報、エンタープライズトークンなど、価値の高い資産が保存されています。また、開発環境のエンドポイントは、本番環境システムに比べて可視性が低く、実行時の制御も不十分な場合が多いため、攻撃の標的となりやすい傾向があります。
高速ローテーショントリガーを使用しない資格情報ストア
ソフトウェアのサプライチェーン攻撃は、しばしば認証情報の漏洩につながる。多くのチームでは、漏洩の恐れがある機密情報を特定し、直ちに更新する信頼性の高いワークフローが依然として整備されていない。
どのようなセキュリティ対策があれば、結果が変わっていたでしょうか
3つの種類のセキュリティ対策があれば、Axiosへの攻撃による影響を大幅に軽減できたはずだ。それぞれの対策は、攻撃の連鎖における異なる段階、すなわちパッケージの実行、認証情報の漏洩、および依存関係の可視化に対処するものである。
1. インストール前のパッケージ単位でのマルウェアスキャン
パッケージレベルのマルウェアスキャンにより、悪意のある依存関係が実行される前に阻止することができます。これはnpm攻撃において重要な意味を持ちます。なぜなら、postinstallフックはインストール中に実行されるため、パッケージが取得された後は手動での確認を行う時間がほとんど残されていないからです。
インストール前にパッケージ、依存関係、ライフサイクルスクリプトをスキャンすることで、パッケージが開発者のエンドポイントやCI/CD環境に到達する前に、既知のマルウェア、不審な動作、脆弱性、およびハードコードされた機密情報を特定することができます。
MetaDefender Software Supply Chain は、ソフトウェアコンポーネント、ベンダー、およびビルドパイプラインを検証OPSWATソフトウェアサプライチェーンセキュリティソリューションです。30以上のアンチウイルスエンジンを横断するMetascanマルチスキャンを含むマルチエンジン脅威検出技術を採用し、パッケージが開発ライフサイクルに入る前に、マルウェア、脆弱性、およびハードコードされた機密情報の有無を検査します。
2. ローテーショントリガーを活用した積極的な秘密情報の管理
積極的なシークレット管理は、侵害に成功された場合の被害を最小限に抑えます。不審なパッケージが特定された場合、チームはローカルの認証情報、SSHキー、トークン、パイプラインのシークレットをすべて漏洩の可能性があるものとして扱い、速やかに更新する対応手順を確立する必要があります。
ハードコードされたシークレットの検出も、同様の目的を果たします。悪意のあるパッケージはメモリやディスクからシークレットを盗み出す可能性がありますが、コードや依存関係にすでに存在しているシークレットがさらされることは、予防可能なリスク要因をさらに一つ加えることになります。
3.Supply Chain と依存関係の監視
サプライチェーンの可視化により、チームは予期せぬパッケージの変更が下流のインシデントに発展する前にそれを検知できるようになります。セキュリティチームは、どのパッケージがインストールされているか、どのバージョンが固定されているか、どのような新しい依存関係が現れたか、そしてそれらのコンポーネントがどこで実行されているかを把握する必要があります。
依存関係の可視化と監視が行われていない場合、侵害の最初の兆候として、最初のインストールからかなり時間が経過した後に、認証情報の悪用やインフラの不正利用が発生する可能性があります。
Software Supply Chain について詳しく知る
Software を確保するには、実行前にパッケージを検査し、新たな依存関係を監視し、パッケージが侵害された際に生じる認証情報の漏洩を最小限に抑えることが重要です。
オンデマンドウェビナー「Software Supply Chain ― 攻撃者が悪用する脆弱な部分」をご覧ください
よくある質問
npmサプライチェーン攻撃とは何ですか？
npmサプライチェーン攻撃とは、通常のソフトウェア開発活動中に、npmエコシステムを通じて悪意のあるコードを配布する攻撃を指します。攻撃者は通常、メンテナンス担当者のアカウントを乗っ取る、偽装されたパッケージを公開する、あるいは開発者やCI/CDシステムが自動的にインストールする依存関係に悪意のある動作を仕込むことで、これを実現します。
攻撃者はどのようにしてAxiosのnpmパッケージを侵害したのでしょうか？
攻撃者は、axiosのメインメンテナのnpmアカウントを乗っ取り、その公開権限を利用して、1.xおよび0.xの両方のリリースブランチに悪意のあるバージョンをリリースしました。また、攻撃者はアカウントのメールアドレスを攻撃者が管理するアドレスに変更し、これによりパッケージに対する支配権を維持しました。
Axiosへの攻撃で使用されたマルウェアは、どのような動作をしたのでしょうか？
Axiosへの攻撃で使用されたマルウェアは、npm installの実行中にポストインストール・フックを利用していました。このフックは攻撃者が制御するサーバーに接続し、macOS、Windows、またはLinux向けのリモートアクセス型トロイの木馬をダウンロードして実行した後、パッケージのメタデータを偽造された内容に置き換えることで、痕跡を消去しようとしました。
なぜコードレビューではAxiosへのサプライチェーン攻撃が見逃されてしまったのか？
コードレビューではAxiosへの攻撃が検出されなかった。その理由は、悪意のあるロジックがAxiosのソースコードに組み込まれていなかったためである。リポジトリレベルで見られる変更はpackage.json内の依存関係エントリのみであったが、実際のマルウェアは、通常のソースコードレビューの範囲外にある外部パッケージを通じて配信されていた。
組織は、インストール前に悪意のあるnpmパッケージをどのように検知すればよいでしょうか？
組織は、パッケージの内容、依存関係ツリー、および実行前のライフサイクルスクリプトをスキャンすることで、インストール前に悪意のあるnpmパッケージを検知できます。マルウェアスキャン、依存関係分析、ポリシーの適用、CI/CDとの統合を組み合わせた効果的な対策により、不審なパッケージが開発環境やビルド環境に到達する前にブロックすることが可能になります。
バージョン固定は、npmのサプライチェーン攻撃を防ぐことができますか？
バージョン固定は、自動アップグレードを制限することで、新たに公開された悪意のあるバージョンへの曝露リスクを軽減します。ただし、固定したバージョン自体がすでに侵害されている可能性や、その他の信頼性の欠如が依然として存在する可能性があるため、バージョン固定だけではサプライチェーンリスクを完全に排除することはできません。バージョン固定は、完全性検証、パッケージ検査、および実行時制御と組み合わせることで、最大の効果を発揮します。
