---
# System prepended metadata

title: axios 乗っ取りのハナシ

---

# 2603に起きた「axios乗っ取り事件」について検索し、日・英 両ソースをあたって、時系列で何が起きたのか、リスクの程度、今後起きうる同様な事象の推測と解説をして。加えて、node.jsのサプライチェーンで次に危ないかもしれないモジュールの傾向を推定してみて。

日本語ソースは主にトレンドマイクロJP、LRQA JP、Qiita/SQATの整理記事、英語ソースは axios 公式 post mortem、Google Threat Intelligence Group、Datadog、Microsoft、Socket、OpenJS/GitHub 公式を重視して読んだ。なお、攻撃者名は Google が **UNC1069**、Microsoft が **Sapphire Sleet** と呼んでいて、**別名だがどちらも北朝鮮系クラスタとして扱っている** 点は押さえておいたほうがいいです。 ([Google Cloud][1])

## まず結論

これは「axios という1個のライブラリが改ざんされた」事件というより、**高影響 npm メンテナーの端末をソーシャルエンジニアリングで落とし、レジストリへの書き込み権限を奪って、数時間だけ正規パッケージを RAT 配布装置に変えたサプライチェーン攻撃**です。影響バージョンは `axios@1.14.1` と `axios@0.30.4`、混入した偽依存は `plain-crypto-js@4.2.1` で、`postinstall` により Windows / macOS / Linux 向けペイロードが自動実行されました。 ([GitHub][2])

## 時系列で何が起きたか

### 1) 事前段階

axios 公式 post mortem では、**3月31日の約2週間前からリードメンテナーに対するソーシャルエンジニアリングが始まっていた**とされています。後続報道と Socket の調査では、偽の企業担当者を装い、LinkedIn → Slack → Teams 風会議へ誘導し、エラー修正名目でアプリ導入やコマンド実行を促す手口が共有されています。 ([GitHub][2])

### 2) 悪性依存の準備

Datadog と Qiita整理では、まず **2026-03-30 05:57 UTC（JST 14:57）** に `plain-crypto-js@4.2.0` が公開され、**2026-03-30 23:59 UTC（JST 08:59）** に悪性 `postinstall` を含む `plain-crypto-js@4.2.1` が公開されました。これは benign 風の先行版を置いてから悪性版へ差し替える流れで、検知回避ともっともらしさ作りの色が濃いです。 ([securitylabs.datadoghq.com][3])

### 3) axios 本体の不正公開

**2026-03-31 00:21 UTC（JST 09:21）** に `axios@1.14.1`、**同 01:00 UTC 頃（JST 10:00 頃）** に `axios@0.30.4` が、侵害されたメンテナーアカウントから公開されました。Datadog によると前者は `latest`、後者は `legacy` に向けられ、**バージョン固定していない新規 install が悪性版を拾いやすい状態**でした。コード本体はほぼ変えず、`package.json` に `plain-crypto-js@^4.2.1` を足した“manifest-only” 改ざんだったのも厄介です。 ([GitHub][2])

### 4) インストール時の感染

Google、Microsoft、Datadog、Trend Micro の分析は一致していて、`plain-crypto-js` は **Axios の実行時には不要なファントム依存**でした。狙いは `postinstall` で `setup.js` を無言実行し、C2 から OS 別の第2段階 RAT を落とすこと。しかも実行後に自分の `package.json` をクリーンなデコイへ戻し、痕跡を消すアンチフォレンジックまで入っていました。 ([Google Cloud][1])

### 5) 発見と削除

公式 post mortem では **01:00 UTC 頃に最初の外部検知**、同時刻帯に GitHub issue が立つものの、**攻撃者が侵害済みアカウントで issue を削除**したと書かれています。その後 **01:38 UTC（JST 10:38）** に collaborator の DigitalBrainJS が PR を立てて npm に直接連絡し、悪性版は **03:15 UTC / 03:29 UTC** に除去された、と公式は記しています。Datadog 側フォレンジックは **03:25 UTC に `plain-crypto-js` が security placeholder 化、~03:40 UTC に axios 側が除去**としていて、**数分〜20分程度の時刻差**があります。これは観測点の違いによるものだと思って見たほうがいいです。 ([GitHub][2])

## この事件のリスクの程度

### 結論: エコシステム視点では「かなり高い」、個別案件では「条件次第」

**高い**理由は3つです。
**1つ目**は、axios が週1億級ダウンロードかつ依存先が非常に多い中核パッケージだったこと。Google は 1.x と 0.x の系統でそれぞれ極めて大きい週次ダウンロードを挙げ、Datadog は 174,000 以上の dependent packages を指摘しています。 ([Google Cloud][1])

**2つ目**は、**感染条件が「その版を install するだけ」**だったことです。Axios 本体コードを呼ぶ前に `postinstall` で発火するため、CI ランナーでも開発端末でも、**ビルド時点で秘密情報に届く**可能性がありました。Microsoft も、影響版を入れた組織は即時に secrets / credentials を rotate すべきと明言しています。axios 公式も、lockfile で該当版や `plain-crypto-js` が出たら **そのマシンを compromised と扱え**と言っています。 ([Microsoft][4])

**3つ目**は、**端末 compromise 型なので 2FA や Trusted Publishing だけでは止め切れない**ことです。Socket は、RAT が端末に入ると `.npmrc`、ブラウザセッション、AWS 認証情報など post-authentication state を持っていけるため 2FA は効きにくい、と説明しています。axios 公式も「個人アカウントから直接 publish していたこと自体がリスクだった」と反省点に挙げています。 ([Socket][5])

ただし、**“全 Node.js プロジェクトが自動で被弾した”わけではない**です。axios 公式は、**クリーン版に pin 済みで、2026-03-31 00:21〜03:15 UTC の間に fresh install していなければ問題ない**としています。Datadog も Windows/Linux ペイロードには不具合があり、Linux 版はコンテナ環境でクラッシュすると書いています。つまり、**被害半径は非常に広いが、実際の感染成功率は raw ダウンロード数よりは低い**、が妥当な見方です。 ([GitHub][2])

## この事件で見えた本質

本件の本質を、**「npm のトークン問題」単体ではなく、“人間の端末が supply chain の最上流になっている”ことが露出した事件**だと見ています。GitHub は 2025年後半に npm の token 有効期限短縮、classic token 廃止、passkey/WebAuthn 推奨、Trusted Publishing(OIDC) 拡大を進めていますし、2026-04-06 には CircleCI まで Trusted Publishing 対応が広がりました。ですが Socket と OpenJS はどちらも、**端末 compromise や CI compromise まで含めると OIDC だけで全解決ではない**と示しています。 ([The GitHub Blog][6])

## 今後起きうる同様事象の推測

ここからは **推測** です。ただし根拠はかなり強いです。Socket は、この axios 事件が単発ではなく、**Node.js エコシステムの高影響メンテナーを狙う組織的キャンペーンの一部**だったと報告しています。実際に Node.js core、Lodash、Express、Fastify/Pino/Undici、dotenv、mocha などの周辺メンテナーが同様の手口で狙われたと出ています。OpenJS は npm が 17M 開発者と月間約370Bダウンロードを抱え、平均 JavaScript プロジェクトが約683の transitive dependencies を引くと説明しており、**1個の深い依存を落とす価値が極端に高い**です。 ([Socket][5])

なので、次に起きそうなのはこうです。
**1. 偽の面談・ポッドキャスト・協業打診から会議誘導する人間狙い。** LinkedIn/Slack/Teams/StreamYard 風 UI を使い、最後に「音声が出ないので update して」「この curl を打って」で端末へ RAT を入れる流れは既に複数報告されています。 ([Socket][5])

**2. ソースをほぼ変えず、manifest だけ変える publish。** Datadog と Microsoft が指摘した通り、今回の axios 本体はソース差分がほぼなく、依存追加だけで成立しました。今後も “diff が小さくレビューをすり抜けやすい改ざん” が増えるはずです。 ([securitylabs.datadoghq.com][3])

**3. まず benign 版を置いてから悪性化する依存。** `plain-crypto-js@4.2.0` → `4.2.1` の流れは、検知モデルや人間の警戒心に対する“ならし運転”として理にかなっています。 ([securitylabs.datadoghq.com][3])

**4. CI/CD と release path の一点突破。** OpenJS は CI-based publishing の利点を認めつつ、bot publish・private audit logs・CI compromise のリスクを明示しています。今後は maintainer 端末だけでなく、release repo、actions secrets、package publish step 自体が狙われやすいです。 ([OpenJS Foundation][7])

## 「次に危ないモジュール」をどう見るか

**特定のモジュールを“次に乗っ取られる”と断定するのは不誠実**。現時点で「この package が危険」と言い切れる一次証拠はありません。なので以下は **断定ではなく、監視優先候補** です。根拠は、**実際にそのメンテナーが標的化されたこと**と、**依存の深さ・配布面積・CI/秘密情報への近さ**です。 ([Socket][5])

### 監視優先候補 1

**Lodash と、その周辺の深い汎用ユーティリティ層**。
John-David Dalton が標的化されたと Socket が書いており、Lodash は 137M 超の週次ダウンロードとされています。こういう「ほぼ何にでも入る汎用ユーティリティ」は、1回の改ざんで爆発半径が大きいです。 ([Socket][5])

### 監視優先候補 2

**ECMAScript polyfills / shims 一群**。
Jordan Harband が維持する多数の polyfills / shims は、Socket が “JavaScript エコシステムの基盤” と表現しています。個別名より、**“言語互換を支える小粒だが深い依存群”** 全体が危ないと見るべきです。 ([Socket][5])

### 監視優先候補 3

**Express / Fastify / Pino / Undici などのサーバー実行系 plumbing**。
Wes Todd、Matteo Collina、Node.js core 関係者が標的化されたとされ、Fastify/Pino/Undici は年あたり billions of downloads 級だと Socket は述べています。これらは**実運用サーバー・CLI・AI ツールチェーンに食い込む層**なので、改ざん時の downstream impact が大きいです。 ([Socket][5])

### 監視優先候補 4

**dotenv のような “秘密情報のすぐ隣” にいるパッケージ**。
Socket は dotenv について「実質ほぼすべての Node.js プロジェクトで使われる」と書いています。こういうパッケージは、もし install-time 実行や runtime 改ざんが入ると、**環境変数・トークン・CI secret との距離が短い**のが怖いです。 ([Socket][5])

### 監視優先候補 5

**テスト/ビルド/品質周辺: mocha, type-fest, npm-run-all2, StandardJS, buffer など**。
Socket は Feross 系パッケージ、Pelle Wessman 系パッケージのメンテナーも狙われたと報告しています。ここは本番 runtime だけでなく、**開発端末と CI ランナーの両方で通る**ため、感染経路として非常に効率がいいです。 ([Socket][5])

### 監視優先候補 6

**Node.js core の releaser / maintenance path 自体**。
Socket は Node.js core collaborator / releaser も標的に入っていると書いています。モジュール名というより、**release authority** が次の本命です。ここが落ちると個別 package を超えた深刻度になります。 ([Socket][5])

## WD/実務視点での読み替え

Web 制作や Node ベースの業務システム運用なら、今回の教訓はかなり明確です。
**「有名ライブラリだから安全」ではなく、「深い依存ほど監視と install policy が必要」** です。特に CI/CD、静的サイト生成、SSR、画像最適化、lint/test、env 読み込みなど、**公開サイトのビルド経路に入る Node.js 依存は“アプリ本体と同等の本番資産”として扱う**べきです。OpenJS が言う通り、npm は現代の Web/CI/AI ツールチェーンの基盤そのものです。 ([OpenJS Foundation][7])

## いま現実的にやるべきこと

短く切ると、優先順位はこれです。
**1. lockfile と SBOM で `axios@1.14.1` / `0.30.4` / `plain-crypto-js@4.2.1` の有無を確認。** 見つかったら、その端末や runner を clean 扱いしない。 ([GitHub][2])

**2. 影響端末・CI の secrets 全 rotation。** npm token、GitHub token、cloud creds、`.env`、package registry auth を全部含める。 ([GitHub][2])

**3. 新規 publish 直後の依存をすぐ取得せず、 cooldown を入れる。** Datadog は dependency cooldown を推奨しています。短時間の悪性 publish に効きます。 ([securitylabs.datadoghq.com][3])

**4. install scripts を許可制で見る。** 今回は `postinstall` が起点でした。少なくとも “新規依存に install/postinstall が入ったらアラート” は入れる価値があります。 ([Google Cloud][1])

**5. maintainer / release 側は OIDC trusted publishing、短命 token、passkeys、publish アラート、immutable release を進める。** ただし OIDC を万能薬と思わず、端末防御も並行でやる。 ([GitHub][2])

---

[1]: https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package "North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack | Google Cloud Blog"
[2]: https://github.com/axios/axios/issues/10636 "Post Mortem: axios npm supply chain compromise · Issue #10636 · axios/axios · GitHub"
[3]: https://securitylabs.datadoghq.com/articles/axios-npm-supply-chain-compromise/ "
  Compromised axios npm package delivers cross-platform RAT | Datadog Security Labs
"
[4]: https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/ "Mitigating the Axios npm supply chain compromise | Microsoft Security Blog"
[5]: https://socket.dev/blog/attackers-hunting-high-impact-nodejs-maintainers "Attackers Are Hunting High-Impact Node.js Maintainers in a C..."
[6]: https://github.blog/changelog/2025-09-29-strengthening-npm-security-important-changes-to-authentication-and-token-management/ "Strengthening npm security: Important changes to authentication and token management - GitHub Changelog"
[7]: https://openjsf.org/blog/publishing-securely-on-npm "Publishing More Securely on npm: Guidance from the OpenJS Security Collaboration Space | OpenJS Foundation"