← ブログ一覧

axiosのサプライチェーン攻撃から学ぶnpmの守り方

2026年3月31日、JavaScriptの定番HTTPクライアント axios がサプライチェーン攻撃を受けた。週間ダウンロード数が約1億にのぼるパッケージだけに、npm史上最大級のインシデントとなった。

この記事では、何が起きたのか、なぜ起きたのか、そして同じ被害に遭わないために何ができるかをまとめる。

何が起きたか

攻撃者がaxiosのリードメンテナー(jasonsaayman)のnpmアカウントを乗っ取り、バックドア入りの2バージョンを公開した。

  • axios@1.14.1latestタグ(npm install axiosで入るデフォルト)
  • axios@0.30.4legacyタグ

どちらのバージョンにも plain-crypto-js@4.2.1 という偽パッケージが依存に追加されていた。このパッケージの postinstall スクリプトが自動実行され、C2サーバー(sfrclak.com:8000)からOS別のリモートアクセストロイ(RAT)をダウンロード・実行する仕組みだった。

つまり、npm install しただけでマルウェアに感染する。macOS、Windows、Linuxすべてが対象だった。

悪意あるバージョンは約3時間で削除されたが、その間にインストールを実行した環境は影響を受けた可能性がある。

なぜ起きたか — ソーシャルエンジニアリングの手口

4月2日に公開されたメンテナー本人のポストモーテムによると、攻撃は巧妙なソーシャルエンジニアリングから始まった。

  1. 攻撃者が実在する企業の創業者になりすまし、メンテナーに接触
  2. 偽のSlackワークスペースに招待(本物に見えるチャンネル活動やソーシャルコンテンツを作り込んでいた)
  3. Microsoft Teamsのミーティングに誘導(複数人が参加しているように偽装)
  4. この一連のやり取りの中でメンテナーのPCにRATマルウェアを感染させた
  5. 窃取した認証情報でnpmアカウントを掌握し、メールアドレスを攻撃者のProtonMailに変更
  6. バックドア入りのaxiosを公開

MicrosoftはこのグループをSapphire Sleet、GoogleはUNC1069と呼んでいるが、いずれも北朝鮮に帰属する国家支援グループと分析している。

ポイントは、npmレジストリやaxiosのコードに脆弱性があったわけではないということ。人間が攻撃された。どんなに堅牢なシステムでも、認証情報を持つ人間が突破されれば終わる。

自分のプロジェクトを守るためにできること

1. lockfileをコミットしてnpm ciを使う

今回の攻撃で被害を免れたプロジェクトの多くは、lockfileが正しく管理されていたケースだった。

# CI/CDでは必ず npm ci を使う
npm ci

npm install はlockfileを無視して新しいバージョンを解決することがある。npm ci はlockfileの内容を厳密に再現するため、lockfileが汚染されていなければ悪意あるバージョンが入り込む余地がない。

lockfileは必ずリポジトリにコミットする。 これが最も効果的な防御線になる。

2. バージョンレンジを使わず正確にピン留めする

// NG: パッチバージョンが自動で上がる
"axios": "^1.14.0"

// OK: このバージョンだけがインストールされる
"axios": "1.14.0"

^(キャレット)や~(チルダ)を使ったバージョンレンジは便利だが、悪意あるパッチバージョンが自動的に入るリスクがある。今回の1.14.1がまさにそのケースだった。

3. postinstallスクリプトを無効化する

# .npmrc
ignore-scripts=true

今回のRATは postinstall フックで実行された。ビルドに必要なネイティブモジュール(node-gypなど)がなければ、ライフサイクルスクリプトを無効化しておくとこの種の攻撃をまるごとブロックできる。

4. 新しいリリースに「待ち」の時間を設ける

Socket などのツールには、公開から一定時間が経過していないパッケージを拒否する機能がある。今回のように悪意あるバージョンが数時間で削除されるケースでは、3日程度のクールダウンポリシーが効果的だった。

5. npm auditを定期的に実行する

npm audit

既知の脆弱性をチェックする基本だが、今回のようにゼロデイで公開される攻撃には即座に対応できないことも覚えておく必要がある。他の対策と組み合わせて初めて意味を持つ。

もし影響を受けていたら

  • 該当システムを即座にネットワークから隔離する
  • そのマシン上のすべての認証情報を無効化して再発行する(APIキー、SSHキー、npmトークン、GitHubトークン、クラウド認証情報など)
  • axiosを安全なバージョン(1.14.0または0.30.3)にダウングレードする

まとめ

今回の攻撃は、コードの脆弱性ではなく人間への攻撃が起点だった。npmエコシステムの信頼モデルが「メンテナーのアカウントが安全である」ことを前提にしている以上、この種のリスクは今後も消えない。

自分たちにできるのは、信頼の境界を自分のプロジェクト内に引くことだ。lockfileをコミットし、バージョンをピン留めし、ライフサイクルスクリプトを無効化する。地味だが、今回の攻撃に対してはこれらの基本的な対策が実際に機能した。

GitHubのDependabotを使えば、脆弱性の検知から自動修正、新規リリースへのクールダウンまで無料で設定できる。詳しくは「GitHubの無料セキュリティ機能で依存パッケージを守る方法」で解説している。

参考リンク