AI：Axiosに仕掛けられたサプライチェーン攻撃とは？npmの悪意ある依存関係と開発者が取るべき対策

2026年、npmで週1億回以上ダウンロードされているHTTPクライアントライブラリ「Axios」に、悪意のある依存関係が仕込まれた。攻撃者が狙ったのはAxiosのソースコード自体ではない。パッケージの「公開プロセス」に潜む隙間だった。漏洩した1つのnpmトークンから始まった攻撃は、認証情報の窃取とリモートアクセス型トロイの木馬（RAT）の配布にまで発展している。

影響を受けたバージョンをインストールしていた開発者は、正規のアップデートだと信じて悪意あるコードを自分のプロジェクトに取り込んでしまった形になる。「自分が使っているライブラリは安全だろう」──その前提が崩れた事件として、すべてのJavaScript開発者が知っておくべき内容だ。

Axiosサプライチェーン攻撃の全容──何が起きたのか

Axiosは、ブラウザとNode.jsの両方で動作するHTTPクライアントライブラリとして、JavaScript開発者にとって最も馴染み深いパッケージの一つだ。GitHub上のスター数は10万を超え、npmでの週間ダウンロード数は1億回以上。フロントエンドからバックエンドまで、あらゆるJavaScriptプロジェクトで採用されている。

そのAxiosが、サプライチェーン攻撃の標的になった。

攻撃の時系列と影響範囲

影響を受けたのは、Axiosのバージョン 1.14.1 と 0.30.4 の2つ。いずれも通常のアップデートとしてnpmに公開されたが、依存関係に plain-crypto-js という見慣れないパッケージが追加されていた。

このplain-crypto-jsは、攻撃のために新規に作成・公開されたマルウェアパッケージ。つまり、Axiosの利用者が npm install や npm update を実行した瞬間、正規のアップデートに見せかけてマルウェアが自動的にインストールされる仕組みになっていた。

攻撃の起点となったのは、長期間有効なまま放置されていたnpmの公開用トークンの漏洩だ。攻撃者はこのトークンを入手し、Axiosのメンテナーになりすましてパッケージを公開した。Axiosチームのリポジトリ自体が侵害されたわけではなく、npmの公開権限だけが乗っ取られた形になる。

発覚後、Axiosチームは該当バージョンをnpmから削除（unpublish）し、影響範囲の調査を開始。同時に、以前から議論されていたTrusted Publishingの導入を急ぐ方針を打ち出している。

週1億回以上ダウンロードされているパッケージだけに、影響を受けた可能性のあるプロジェクト数は膨大になる。ただし、該当バージョンがnpm上に存在していた期間は比較的短く、CI/CDパイプラインで自動更新を止めていたプロジェクトや、lockfileでバージョンを固定していたプロジェクトは被害を免れた可能性が高い。

ここが今回の事件から得られる最初の教訓でもある。lockfileの運用とバージョン固定の習慣が、攻撃の被害範囲を大きく左右するという事実だ。

注入されたコードの挙動

plain-crypto-jsに含まれていた悪意あるコードは、大きく分けて2段階の攻撃を実行するものだった。

第1段階：認証情報の窃取。 パッケージのインストール時に実行されるpostinstallスクリプトが起動し、環境変数やホームディレクトリに保存された .npmrc ファイルから認証トークンを収集する。CI/CD環境では、AWS認証情報やAPIキーなど、環境変数に格納された機密情報も対象になっていた。

第2段階：RAT（遠隔操作トロイの木馬）の設置。 窃取した情報を外部サーバーに送信するだけでなく、攻撃者がリモートからコマンドを実行できるバックドアを設置する。これにより、初回の攻撃後も持続的にシステムへアクセスできる状態が作られた。

一般的なマルウェアと今回の攻撃で決定的に異なるのは、配布経路の信頼性にある。怪しいメールの添付ファイルや不審なWebサイトからダウンロードするのではなく、開発者が日常的に信頼して使っているパッケージマネージャーを通じて配信された。セキュリティソフトが検知しにくいだけでなく、開発者自身も「いつものnpm installの一部」として疑いを持ちにくい。

実際に、プロジェクトのdependenciesに直接plain-crypto-jsを追加した開発者はいない。Axiosの依存関係として間接的にインストールされたため、node_modules の奥深くに潜んだ状態で動作していた。日常的にpackage-lock.jsonの差分を確認する習慣がなければ、気づくのは極めて困難だったはずだ。

この「正規の配布チャネルを悪用する」手法こそが、サプライチェーン攻撃の本質的な恐ろしさと言える。

なぜAxiosが狙われたのか──npmサプライチェーン攻撃の仕組み

Axiosが標的になったのは偶然ではない。サプライチェーン攻撃の構造を理解すると、むしろ「狙われるべくして狙われた」ことが見えてくる。

npmの依存関係が攻撃対象になる理由

JavaScriptのエコシステムには、他の言語と比べても際立った特徴がある。依存関係の「深さ」だ。

npmでパッケージをインストールすると、そのパッケージが依存している別のパッケージも自動的にダウンロードされる。さらに、その依存先が持つ依存関係も連鎖的に取得される。結果として、たった1つのパッケージを追加しただけで、node_modulesフォルダには数十から数百のパッケージが格納されることも珍しくない。

この依存ツリーの深さが、攻撃者にとっては格好の侵入経路になる。開発者がpackage.jsonに記載した直接的な依存関係は意識していても、その先にある間接的な依存関係まで逐一チェックしている人はほとんどいないからだ。

加えて、npmのデフォルト動作として、パッケージのインストール時にpostinstallスクリプトが自動実行される仕組みがある。ビルドツールのコンパイルやネイティブモジュールのセットアップに使われる正当な機能だが、攻撃者にとっては「インストールするだけでコードを実行させられる」入り口でもある。

Axiosのような週1億DLのパッケージを乗っ取れば、そこに依存するプロジェクトすべてに一括で悪意あるコードを配布できる。効率という観点では、攻撃者にとってこれ以上ないほど魅力的なターゲットだった。

npmトークンの漏洩経路として多いのは、GitHubリポジトリへの誤コミットやCI/CDのビルドログへの意図しない出力。.npmrc ファイルをうっかり .gitignore に含め忘れたまま公開リポジトリにプッシュするケースは、Secret Scanningの普及した現在でも後を絶たない。今回のAxiosの事例でも、長期間ローテーションされていなかったトークンが攻撃者の手に渡ったとされている。

過去のnpmサプライチェーン攻撃事例との比較

npmを標的としたサプライチェーン攻撃は、今回が初めてではない。過去の事例と比較すると、手口が年々巧妙化していることが分かる。

event-stream事件（2018年） は、サプライチェーン攻撃の危険性を広く知らしめた最初の大規模事例だ。メンテナンスを放棄していた開発者から引き継ぎを申し出た第三者が、パッケージに暗号通貨ウォレットを狙うマルウェアを仕込んだ。「メンテナーの善意」を悪用するという、社会的な手口が特徴的だった。

ua-parser-js事件（2021年） では、週間800万DLのパッケージが乗っ取られ、暗号通貨マイナーとパスワード窃取ツールが埋め込まれた。こちらもnpmアカウントの侵害が原因で、攻撃者は正規のメンテナーとしてパッケージを更新している。

今回のAxiosの事件を過去2つの事例と並べると、いくつかの進化が見て取れる。

まず、攻撃対象の規模が格段に大きくなっている。event-streamの週間DL数は約200万、ua-parser-jsが約800万だったのに対し、Axiosは1億超。影響範囲のスケールが桁違いだ。

次に、攻撃の多段化が進んでいる点。event-streamは特定のウォレットを狙ったピンポイント攻撃だったが、Axiosの事例では認証情報の窃取とRATの設置という2段構えになっていた。初回の攻撃で情報を抜き取るだけでなく、バックドアを残して持続的なアクセスを確保する手法は、国家レベルのAPT攻撃にも通じる高度なものだ。

そして、攻撃の発見を遅らせる工夫も見られる。「plain-crypto-js」というパッケージ名は、一見すると暗号化関連のユーティリティに見えなくもない。node_modulesの中に紛れていても、名前だけでは不審だと気づきにくい命名がされていた。

これらの事例が示しているのは、npmエコシステムにおけるサプライチェーン攻撃が「例外的な事故」ではなく、構造的かつ繰り返し発生するリスクだという現実だ。そしてその手口は、事件のたびに洗練されている。

では、開発者として何ができるのか。次のセクションでは、今回のAxios事件を踏まえて、個人やチームが今日から実践できる5つの具体的な防御策を取り上げる。

開発者が今すぐ実践すべき5つの防御策──Axiosの教訓を活かす

サプライチェーン攻撃の手口がわかったところで、問題は「自分のプロジェクトをどう守るか」に尽きる。ここでは、個人開発者からチーム開発まで幅広く適用できる5つの対策を、優先度の高い順に紹介していく。

トークン管理の見直しとTrusted Publishingの導入

今回のAxios事件で最初の突破口になったのは、漏洩した長期有効のnpmトークンだった。この一点だけでも、トークン管理がいかに重要かがわかる。

まず確認すべきは、自分のnpmアカウントに紐づいているトークンの一覧。npmの公式サイトにログインし、Access Tokensのページを開くと、現在有効なトークンがすべて表示される。作成日時が古く、用途を思い出せないトークンがあれば即座に無効化してほしい。「いつか使うかも」と残しておくトークンが、攻撃者にとっては宝の山になる。

次のステップとして検討したいのが、Trusted Publishing（信頼できる公開体制） の導入だ。これはGitHub Actions経由でパッケージを公開する仕組みで、長期トークンを使わずに済む。公開のたびにOIDC（OpenID Connect）で一時的な認証情報が発行されるため、トークンが漏洩するリスク自体を排除できる。

Axiosのリポジトリでも、この仕組みの導入がオープンイシューとして議論されていた。皮肉なことに、導入が間に合わなかったために今回の事件が起きたとも言える。設定自体はGitHub Actionsのワークフローファイルに数十行を追加する程度で、npmの公式ドキュメントに手順が記載されている。パッケージを公開する立場にある開発者なら、最優先で対応すべき項目だ。

依存関係の監査とロックファイルの徹底運用

npm audit を定期的に実行している開発者は少なくないが、それだけでは今回のような攻撃を防げなかった可能性が高い。なぜか。npm auditが検知するのは、既知の脆弱性データベース（GitHub Advisory Database等）に登録された問題だけだからだ。新たに公開された悪意あるパッケージは、報告が上がるまでの空白期間にはすり抜けてしまう。

そこで併用したいのが、Socket.devやSnykといったサードパーティの監査ツール。Socket.devは依存パッケージのソースコードを静的解析し、ネットワーク通信やファイルシステムへのアクセスなど、「パッケージの振る舞い」を検出する。名前やバージョン番号ではなく、コードの挙動そのものをチェックするため、未知のマルウェアにも対応しやすい。

もう一つ、地味だが効果の大きい対策がロックファイルの運用強化だ。package-lock.json（yarnならyarn.lock）をリポジトリにコミットし、プルリクエスト時にそのdiffをレビューする習慣をつけるだけで、不審な依存関係の追加に気づきやすくなる。

実際、Axiosの事件でもpackage.jsonに「plain-crypto-js」が新たな依存として追加されていた。ロックファイルのdiffを定期的に確認していたチームなら、「見覚えのないパッケージが増えている」と異変を察知できた可能性がある。

GitHub Dependabotとプライベートレジストリの活用

GitHubが提供するDependabotは、依存パッケージの脆弱性を自動で検知し、修正バージョンへのアップデートをプルリクエストとして作成してくれる機能だ。リポジトリの「Settings」→「Code security」から数クリックで有効化できるため、まだ設定していないなら今日中に済ませてほしい。

加えて、GitHubのSecret Scanningも併せて有効にしておくと安心感が増す。リポジトリ内にnpmトークンやAPIキーが誤ってコミットされた場合、自動で検知して通知してくれる。今回のAxios事件の根本原因がトークン漏洩だったことを考えると、この機能の価値は大きい。

企業やチームでの開発なら、さらに一歩進んでプライベートレジストリ（社内パッケージリポジトリ）の導入を検討すべきだ。Sonatype NexusやJFrog Artifactoryといったツールを使えば、npmの公開レジストリとの間にプロキシを設置し、承認済みのパッケージだけを社内に配信する運用が可能になる。

日本の開発現場では、セキュリティポリシー上インターネットへの直接アクセスを制限しているケースも多い。そうした環境では、すでにプロキシレジストリを導入している可能性があるが、「ただ通しているだけ」で承認プロセスが形骸化しているケースも散見される。今回の事件を機に、プロキシレジストリの設定を見直し、新規パッケージの追加時に人間のレビューを挟むフローを整備するのが望ましい。

ここまでの5つの対策を整理すると、以下のようになる。

1. npmトークンの棚卸しと長期トークンの廃止──すべての開発者が今日から実行可能
2. Trusted Publishingの導入──パッケージ公開者は最優先で対応
3. npm audit＋Socket.dev/Snykによる多層監査──週次の定期実行を推奨
4. ロックファイルのコミットとdiffレビュー──PR運用に組み込む
5. Dependabot・Secret Scanningの有効化＋プライベートレジストリの導入──チーム単位で対応

すべてを一度に導入する必要はない。まず1と4から始めて、段階的に他の対策を追加していくのが現実的な進め方だ。

オープンソースのセキュリティはどう変わるか──GitHubとnpmの最新動向

個々の開発者ができる対策を見てきたが、エコシステム全体としてはどのような方向に進んでいるのか。GitHubとnpmが推進している取り組みを俯瞰してみる。

npm provenanceとSigstoreによる署名検証

2023年にGAとなったnpm provenanceは、パッケージの「出自」を証明する仕組みだ。具体的には、「このパッケージはどのソースコードから、どのCI/CD環境でビルドされたか」を暗号学的に検証可能な形で記録する。

技術的な基盤として使われているのがSigstoreというオープンソースプロジェクト。従来のコード署名は、開発者が秘密鍵を管理する必要があり、鍵の紛失や漏洩がそのまま信頼の崩壊につながっていた。Sigstoreは短命の証明書を使い、署名のログを透明性のある公開台帳（Rekor）に記録する。開発者が長期的な鍵管理に煩わされない設計が特徴だ。

npmのパッケージページで「Provenance」バッジが表示されているパッケージは、このビルド元証明が付与されている。利用者としては、依存パッケージを選ぶ際にこのバッジの有無を確認する習慣をつけると、リスクの低減に役立つ。

ただし、2026年4月時点でprovenanceを導入しているパッケージはまだ全体の一部に過ぎない。主要なパッケージから順次対応が進んでいるものの、エコシステム全体に行き渡るには時間がかかる。「provenanceがあるから安全」ではなく、「provenanceがないパッケージには追加の注意を払う」という使い方が現実的だろう。

OSSメンテナーの負担とセキュリティの両立

サプライチェーンセキュリティを強化すればするほど、メンテナーの負担は増える。Trusted Publishingの設定、provenance対応のためのCI/CD整備、脆弱性レポートへの対応──これらすべてが、多くの場合は無償で活動しているOSSメンテナーの肩にのしかかっている。

Axiosのケースでも、Trusted Publishingの導入が「オープンイシュー」のまま攻撃を受けた。メンテナーが怠慢だったわけではなく、限られたリソースの中で優先順位をつけた結果、セキュリティ対応が後回しになった可能性が高い。

この問題に対して、GitHubはGitHub Sponsorsによるメンテナーへの資金提供や、Security Advisoriesの自動生成など、メンテナーの負荷を下げるための機能を拡充している。また、OpenSSFのAlpha-Omega Projectのように、重要なOSSプロジェクトに対してセキュリティ専門のリソースを直接投入する取り組みも始まっている。

とはいえ、根本的な課題は残ったままだ。世界中の企業が依存しているOSSの多くが、個人や少人数のボランティアによって維持されている。この構造が変わらない限り、サプライチェーン攻撃のリスクはゼロにならない。

開発者として現実的にできるのは、自分が使っているOSSプロジェクトの健全性を定期的にチェックすること。メンテナーの活動状況、イシューへの対応速度、セキュリティポリシーの有無──こうした指標は、OpenSSFのScorecardプロジェクトでスコアとして確認できる。依存パッケージを「入れたら終わり」にせず、継続的にモニタリングする姿勢が、今の時代には求められている。

まとめ──「信頼」を前提にしない開発環境へ

Axiosへのサプライチェーン攻撃は、「有名なパッケージだから安全」という思い込みの危うさを突きつけた。週1億DLを超える人気ライブラリですら、たった一つのトークン漏洩で侵害される。この事実を受け止めた上で、開発環境の「信頼モデル」を見直す必要がある。

ネットワークセキュリティの世界では「ゼロトラスト」が当たり前になりつつあるが、同じ考え方をパッケージ管理にも適用する時期に来ている。すべてのパッケージを疑えという話ではない。「信頼を検証可能な形で確認する」プロセスを、日々の開発フローに組み込むということだ。

どこから手をつけるべきか迷ったら、まずは2つのアクションから始めてほしい。一つは npm audit の実行。もう一つは、自分のnpmアカウントに紐づいた トークンの棚卸し だ。どちらも5分あれば終わる作業だが、この5分が将来の大きなインシデントを防ぐ第一歩になる。

チーム開発の現場であれば、ロックファイルのdiffレビューをPR運用に組み込むところから始めるのが効果を感じやすい。プライベートレジストリやTrusted Publishingの導入は、その次のステップとして検討すれば十分間に合う。

「うちのプロジェクトは小規模だから大丈夫」──そう考えたくなる気持ちはわかる。だが、攻撃者はあなたのプロジェクトではなく、あなたが使っているパッケージを狙っている。プロジェクトの規模に関係なく、依存関係を持つすべての開発者がこのリスクの当事者だ。

よくある質問（FAQ）

Q1. 自分のプロジェクトがAxiosの影響を受けたか確認する方法は？

package.jsonまたはpackage-lock.jsonでAxiosのバージョンを確認する。影響を受けたのはバージョン1.14.1と0.30.4の2つ。ターミナルで npm ls axios を実行すれば、プロジェクト内で使用中のバージョンが一覧表示される。該当バージョンがインストールされていた場合は、直ちに1.14.2以降（または0.30.5以降）にアップデートし、環境変数やCI/CDで使用しているシークレットの変更を検討してほしい。特に.npmrcにトークンを直接記載していた場合は、トークンの無効化と再発行が必須だ。

Q2. npm auditで「問題なし」と出たら安全と考えてよい？

残念ながら、それだけでは不十分だ。npm auditが参照するのは既知の脆弱性データベースであり、報告されていない脅威は検知できない。今回のAxios事件でも、攻撃が発覚してデータベースに登録されるまでの間は、npm auditを実行しても何も検出されなかった。npm auditは「既知の穴がないか確認する」ツールであり、「安全を保証する」ツールではない。Socket.devやSnykなど、パッケージの振る舞いを分析するツールとの併用を推奨する。

Q3. Trusted Publishingは個人開発者でも使える？

使える。GitHubアカウントとnpmアカウントを持っていれば、個人でもTrusted Publishingを設定可能だ。必要なのは、GitHub Actionsのワークフローファイルにnpmへの公開設定を追加し、npm側でGitHubリポジトリとの連携を許可する作業のみ。npmの公式ドキュメントに「Using OIDC for npm Publish」として手順が掲載されている。規模の大小を問わず、パッケージを公開するすべての開発者に導入を勧めたい。個人開発者こそ、トークン管理に割けるリソースが限られるため、自動化の恩恵が大きいからだ。