ハクソク

世界を動かす技術を、日本語で。

ポストモーテム：axios NPM サプライチェーンの侵害

53日前原文(github.com)

概要

  • 2026年3月31日、 axios の2つの悪意あるバージョンがnpmに公開
  • plain-crypto-js 依存関係を通じてリモートアクセス型トロイの木馬を配布
  • 約3時間で削除されたが、 影響を受けたシステムは要対応
  • セキュリティ対策の強化と再発防止策を実施中
  • 詳細な技術分析や対応手順は外部リンクで案内

axios npmリリースにおけるセキュリティインシデント概要

  • 2026年3月31日、 axios@1.14.1 および axios@0.30.4 が npm に公開
  • これらのバージョンは plain-crypto-js@4.2.1 を依存関係として注入
  • plain-crypto-jsは macOS、Windows、Linux 上で リモートアクセス型トロイの木馬（RAT） をインストール
  • 悪意あるバージョンは 約3時間 で削除
  • 公開は メンテナのアカウントが侵害 されたことが原因

影響の確認と初期対応

  • lockfile（package-lock.jsonやyarn.lock）で axios@1.14.1、axios@0.30.4、plain-crypto-js の記載をgrepで確認
  • 該当があれば そのマシンは侵害されたと見なす
    • axiosを 1.14.0 または 0.30.3 へダウングレード
    • node_modules/plain-crypto-js/ を削除
    • すべての シークレット・トークン・認証情報のローテーション
    • sfrclak[.]com や 142.11.206.73:8000 への通信ログ確認
    • CIランナー利用時は ビルド時に注入したシークレットもローテーション
  • 00:21〜03:15 UTCの間に npm install 等を実行していなければ影響なし

詳細な復旧・調査ガイダンス

  • 詳細な対応手順やCI/CD向けガイドは下記外部サイト参照
    • StepSecurity: 技術分析と復旧手順
    • Snyk: アドバイザリとスキャン手法
    • Socket: サプライチェーン攻撃の詳細

攻撃の経緯

  • 約2週間前： ソーシャルエンジニアリング による攻撃開始
  • 3月30日 05:57 UTC： plain-crypto-js@4.2.0 公開
  • 3月31日 00:21 UTC： axios@1.14.1 公開（悪意ある依存関係付き）
  • 3月31日 01:00 UTC頃： axios@0.30.4 公開、外部検知・コミュニティ通報
  • 3月31日 01:38 UTC： DigitalBrainJS がPR提出、npmへ連絡
  • 3月31日 03:15 UTC： 悪意あるバージョン削除
  • 3月31日 03:29 UTC： plain-crypto-js 削除

インシデントからの教訓

  • 個人アカウントからの直接公開はリスク
  • OIDCフロー や イミュータブルリリース の早期導入が必要
  • 自動検知手段がなかった ため、コミュニティの通報に依存
  • オープンソースメンテナ は高度なソーシャルエンジニアリングの標的
  • 継続的な監視とセキュリティ強化 が必須

再発防止策

  • 全デバイス・認証情報の リセット
  • イミュータブルリリース 体制への移行
  • OIDCフロー の導入
  • GitHub Actions のベストプラクティス適用
  • セキュリティ体制の継続的な見直しと改善

広範なユーザー向け要約

  • axios の2つのバージョンが短期間 悪意ある状態で公開
  • リードメンテナのアカウント侵害 によるもので、ソースコード自体の改ざんではない
  • 該当バージョン利用の場合は 即時削除と認証情報のローテーション が必要
  • インシデントは解決済み、 今後もセキュリティ強化を継続

感謝と今後の対応

  • @DigitalBrainJS、オープンソースコミュニティ、npmセキュリティチームへの迅速な対応に感謝
  • 悪意あるバージョンは npmから削除済み
  • 継続的な調査とセキュリティ対策のアップデートを実施予定
  • 質問・意見はスレッドで受付

Hackerたちの意見

3月31日、UTCの午前1時頃：コミュニティのメンバーが侵害を報告する問題を提出。攻撃者は侵害されたアカウントを使ってそれを削除。タイミング的に面白いね。

ここ数週間でサプライチェーン攻撃がすごく増えてる。npmは特に、公共プロジェクトに埋め込まれた悪意のあるコードのセキュリティ対策を強化する必要があると思う。

└

これが現代戦争の現実だよね。多くの国が大規模にマルウェアを仕掛けてる可能性が高い。攻撃の発信元を証明するのも難しいから、関係ない国も今の紛争を利用するのが賢いと思う。例えば、ドイツ語で書いた場合、マルウェアを中国語、ペルシャ語、英語、ヘブライ語に翻訳して、戦争中の国から来ているように見せかけるとか。マルウェアを使った長期的な計画を立てている国は、今の時期にやるだろうね。

└

NPMは、信頼できないコードを自分のマシンで実行できるように設計されてる。だから、絶対にうまくいかないよ。レベルアップするゲームなんてない。ダチョウに飛ぶように頼むようなもんだね。

└

OIDCを設定するためのnpmプロセスがめっちゃイライラする。摩擦が多すぎるんだよね。まず、そのパッケージがレジストリに存在しないといけなくて、APIトークンを作って何かをプッシュしなきゃいけない。そして、その特定のパッケージのためにOIDCを有効にできるのはその後。リポジトリとワークフロー名を追加したら、保存しなきゃいけない。最後に「OIDCの公開をのみ許可する」を切り替える。各アクションの前に2FAコードを入力する必要がある。去年の年末にnpmにイライラしすぎて、その問題をカバーするガイドを一冊書いたよ：https://npmdigest.com/guides/npm-trusted-publishing

いいペイロード分析はもう発表されてる？これが一発限りの情報盗みだったのか、それとも影響を受けたシステムにもっと深く入り込む可能性があったのか、すごく気になる。

└

この記事はペイロードについて調査してるね。これはRATだから、単に認証情報を盗むだけじゃなくて、受け取ったシェルコマンドを実行できるんだ。

知ってることばかりだけど（オーナーが侵害された時点で基本的にどうしようもない）、でも今はソーシャルエンジニアリングの実態を少し垣間見ることができたのが唯一の興味深いニュースだと思う： https://github.com/axios/axios/issues/10636#issuecomment-418...

└

jasonsaaymanとvoxpelliは、「常に警戒しておくべきこと」の視点から有益な記事を書いてた。Jasonは「会議で、私のシステムの何かが古くなっていると言われた」と言ってた。彼らはMicrosoftの会議を使っていて、それがRCEを引き起こしたんだ。もっと詳しく知りたいな。

└

所有者が侵害されるのは、適切に運営されているFOSSプロジェクトでは全然生き残れるよ。適切なコミットやレビュー、プッシュの署名があればね。これも最近のサプライチェーン攻撃も完全に防げたはず。だから、今の時点では被害者を責めるのも全然アリだと思う。これは完全にAxiosチームの責任だよ。Gitのプッシュやコミットの署名用にスマートカードを設定して、そのキーを広く公開して、署名されたマージコミットを義務付ければ、メインに何かが載ることはなくなるし、単一の失敗点もなくなるよ。

このスレッドの面白い点は、すべての正当なv1リリースにはOIDCの出所証明があったのに、悪意のあるものにはなかったこと。でも誰もチェックしないんだよね。もっと簡単に言うと、デプロイ間でロックファイルを比較しているなら、パッチリリースで新しい依存関係が現れるのはかなり明らかな赤信号だよ。

└

npmは、パッケージがレジストリレベルでOIDC専用の公開を選べるようにすれば、半分は解決できると思う。v1ではすでに出所証明があったけど、レジストリはそれなしで悪意のある公開を喜んで受け入れてたんだよね。

└

正直言って、ツールが証明書の検証をしてくれると思ってた。ロックファイルの差分は自分でやらなきゃいけないけどね。

すごく洗練された操作に見えるし、マシンが侵害されたメンテナーには同情するよ。次のバージョンでは、マルウェアが何らかの形でハイバネートして（例えば、if (Date.now()) みたいに）被害を最大化するんじゃないかと心配してる。

└

それってもうそうなってるんじゃない？つまり、侵害されたマシンがコマンドサーバーに登録して、時々ワークロードをチェックするってこと。ハッカーは次の行動を決めるんだよね。侵害したマシンによって、広範囲に攻撃を広げるか（今回みたいに）、それとももっと深く掘り下げてデータを抜き出したり、内部で広げたりするかもしれない。例えば、ビルドノードが侵害されたらね。

問題の根本は、その人がいろんなことに同じデバイスを使ってたことだと思う。NPMがこういう攻撃を防ぐために取れる drastic な対策は、ハードウェアセキュリティを使うことだと思う。NPMは、2FAの代わりにノートパソコンのTPMに基づいたアイデンティティを持つラップトップを調達して設定できる。特定のリポジトリに対しては、ラップトップのTPMにあるプライベートキーで署名された更新だけがNPMにプッシュできるようにNPMサーバーを設定するんだ。各有名なリポジトリには、そのリポジトリ用に特定のラップトップがあるようにする。NPMにアップロードするためのコマンドラインツールだけが入った最小限のLinuxバージョンでラップトップを設定して、ブラウザやデスクトップ環境は一切入れない。そういうラップトップを有名なリポジトリのメンテナーに無料で渡して、更新用に使ってもらう。更新の時には、メンテナーが自分の開発マシンからUSBドライブやCDを使って安全なラップトップにコードを転送して、特別なラップトップからNPMにプッシュするって感じ。

└

ボタンをタップするだけのアプリを作ればいいんじゃない？そうすれば、TOTPシードがパスワードマネージャーに保存されて、'publish'を実行してるノートブックに同居しちゃうこともないし。

このツールで自分のマシンが影響を受けたか確認してみてね: https://github.com/aeneasr/was-i-axios-pwned

└

これが次のマシンを侵害するツールじゃないってどうやってわかるの？

システムのどこかが古くなってた。足りないアイテムをインストールしたよ。「未知のものを自分のマシンにインストールしない」っていう原始的な「極度の警戒」は達成不可能だけど、プロジェクトレベルで本当に効果的な解決策はあるのかな？ もっと多くの人を巻き込む必要があるけど、みんながランダムなものをインストールしないことを期待するのは無理だよね、少なくとも同時には…（でも、もっと多くの人がいるわけでもないかも…）

GitHubスレッドの面白い点は、shaanmajidが指摘したことなんだけど、すべての正当なv1リリースにはOIDCの出所証明があったのに、悪意のあるものにはなかった。でも、誰もチェックしてないんだよね。もっと簡単に言えば、デプロイ間でロックファイルを比較しているなら、パッチリリースで新しい依存関係が現れるのは、証明インフラがなくてもかなり明白な赤信号だよ。

└

重複コメント - 二重投稿？ https://news.ycombinator.com/item?id=47622805