Axiosへのサプライチェーン サイバー攻撃はどう起きたのか-メンテナーアカウント侵害から見る不正公開の手口

セキュリティニュース

投稿日時: 更新日時:

Axiosへのサプライチェーン サイバー攻撃はどう起きたのか-メンテナーアカウント侵害から見る不正公開の手口

2026年3月31日、世界中で利用されているHTTPクライアントライブラリ「Axios」の悪意あるバージョン(1.14.1 および 0.30.4)がnpmに公開される大規模なサプライチェーン攻撃が発生しました。

このインシデントについて、AxiosのリードメンテナーであるJason Saayman氏がGitHubのIssue(#10636)にて詳細な事後報告(ポストモーテム)を公開しました。本記事では、メンテナーのPCがどのようにして乗っ取られ、攻撃に至ったのか、その生々しい手口と、OSSコミュニティに向けた教訓を解説します。

【30秒でわかる本記事の概要】

  • 侵入経路: 攻撃者は「偽のMicrosoft Teams会議」を用いた高度なソーシャルエンジニアリングにより、AxiosメンテナーのローカルPCに遠隔操作マルウェア(RAT)を感染させた。

  • 公開手法: GitHubのソースコードは一切改ざんされず、乗っ取られたローカルPCのnpm CLIから直接、マルウェア入りのバージョンが公開された。

  • 教訓: マシンが乗っ取られた状態では通常の二要素認証(TOTP)は無力であり、CI/CD経由のOIDC(OpenID Connect)による公開や、ハードウェアキーの導入が必須であると警告している。

概要

2026年3月31日、npmで配布されたaxiosの 1.14.1 と 0.30.4 が、侵害されたメンテナーアカウント経由で不正公開されたことが明らかになりました。

Axiosの事後報告によると、不正版には [email protected] という悪意ある依存関係が注入されており、macOS、Windows、Linux向けのRATを導入する仕組みが組み込まれていました。不正版は約3時間公開され、その後削除されています。

この攻撃の本質は、axios本体のソースコードに直接マルウェアを書き込んだことではなく、公開権限を持つメンテナーのアカウントと端末を押さえたうえで、正規リリースの見た目を保ったまま悪意ある依存関係を差し込んだ点にあります。

GitHub Advisoryでも、メンテナーのnpmアカウント侵害によって悪意ある版が公開され、@lightdash/cli のように semver 範囲指定でaxiosを参照するパッケージにも波及し得たとされています。

関連:JavaScript ライブラリ axiosのnpmが乗っ取られる-1.14.1と0.30.4は導入済みなら侵害前提で対応が必要

攻撃の起点:「約2週間」にわたる巧妙なソーシャルエンジニアリング

メンテナーの報告や同Issueに寄せられた他開発者の証言によると、攻撃の入り口はシステム的な脆弱性ではなく、「標的型のソーシャルエンジニアリング」でした。Saayman氏は、3月31日のインシデント発生から「約2週間前」にこのソーシャルエンジニアリングキャンペーンが開始されたと報告しています。

OSS界隈で現在多発しているこの攻撃手法(同Issueでの証言を含む)は、非常に周到かつ精巧です。

「偽の仕事の依頼」や「ポッドキャストの招待」で接触

攻撃者は、ダミーの企業アカウントや、活動実績を偽装したGitHubアカウント(ソックパペット: 1人の人間が複数アカウントを利用する)を用いてメンテナーに接触します。

「共同作業の提案」「仕事の面接」「ポッドキャストへの出演依頼」など、メンテナーが断りにくい、あるいは興味を持つ内容でアプローチします。 別のOSSメンテナーの証言によれば、攻撃者は事前にSNS用の画像やインタビューの質問事項まで用意し、数日間にわたってやり取りを行うことで完全に信用させようとします。

「偽のオンライン会議(Teams等)」によるマルウェア感染

信頼関係を築いた後、オンライン会議(面接やポッドキャストの収録など)を設定します。指定されたリンクをクリックすると、一見すると本物のストリーミングサイトや「Microsoft Teams」などにそっくりな偽サイト(クローンサイト)に誘導されます。

そこで「システムの一部が古いためアップデートが必要」「接続に問題があるためこのアプリを実行してほしい」という偽の警告(ClickFixと呼ばれる手口)が表示されます。メンテナーがこれを正規のプロセスだと信じ込み、提示されたスクリプトをターミナルで実行、あるいは偽のアプリ(署名されていないネイティブアプリ等)をインストールしてしまうことで、PCがインフォスティーラー(情報窃取マルウェア)やRAT(遠隔操作トロイの木馬)に感染します。

この一連の動作により、メンテナーのローカルPCの完全な制御権が攻撃者に奪われる結果となりました。

ソースコードは無傷、ローカル環境からの「直接公開」

今回の攻撃で特筆すべきは、AxiosのGitHubリポジトリ(ソースコード)自体は一切改ざんされていなかったという点です。攻撃者はGitを通じたコミットやプッシュを行っていません。

Saayman氏は「RATがマシンに感染した時点で、攻撃者は私のマシンのすべてに対して完全な一方的制御(unilateral control)を持っていた」と述べています。 攻撃者はPC内に保存されていたnpmの認証トークンを悪用し、GitHub Actionsなどの通常のCI/CDパイプラインを通さず、感染したローカルマシンの「npm CLI」から直接、悪意のあるパッケージを公開しました。

公開されたバージョンには、Axiosのコードの変更ではなく、[email protected] という外部のマルウェアドロッパーが「依存関係」として新たに追加されていました。

OSSコミュニティが共有する「3つの痛恨の教訓と対策」

Saayman氏の報告に対し、著名なセキュリティ研究者であるFeross Aboukhadijeh氏などもコメントを寄せ、影響力の大きいパッケージのメンテナーにとって不可欠な3つの教訓と対策を強調しています。

OIDCベースの公開(Provenance)の導入

最も効果的な対策(highest-leverage change)として、OIDC(OpenID Connect)を利用したnpm provenance(出所の証明)の導入が挙げられています。これにより、長期間有効なクレデンシャル(ローカルに保存されたnpmトークン)に依存するリスクを完全に排除できます。Axiosチームも今後の再発防止策としてこのフローの採用を明言しています。

CI環境からの公開の徹底(ローカル公開の禁止)

個人のローカルPCから直接npmへ公開するワークフローは、回避すべき巨大なリスクでした。Feross氏は「リリースはローカルマシンからではなく、CIから行うべきだ。 メンテナーのノートPCが侵害されたとしても、その被害範囲(ブラスト・ラジアス)に『リリースをプッシュする能力』が含まれるべきではない」と強く推奨しています。

TOTPの限界とハードウェアキーの必須化

Saayman氏のnpmアカウントでは二要素認証(2FA)が有効化されていました。しかし、マシン自体がRATに乗っ取られている状態では、認証アプリ等で生成されるTOTP(ワンタイムパスワード)も攻撃者に傍受され、無力化されてしまいます。 「侵害されたマシン上でのTOTPは2FAとして機能しない」という厳しい現実が浮き彫りになり、必須設定としての2FAに加え、可能な限りハードウェアセキュリティキー(YubiKeyなど)を使用すべきだと警告されています。

情報システム部門が取るべき対応

まず優先すべきなのは、該当バージョンをインストールした端末やCI/CDランナーを侵害前提で扱うことです。Axiosメンテナーは、lockfile確認、クリーン版へのダウングレード、plain-crypto-js の削除、シークレットと認証情報の全面ローテーション、sfrclak[.]com142.11.206.73:8000 への通信確認を推奨しています。これは単なるバージョン戻しではなく、侵害後対応として進める必要があります。

加えて、再発防止の観点では、個人アカウントからの直接公開を減らし、OIDCベースの公開、イミュータブルなリリース設計、公開権限の分離、依存関係の監査、異常公開の即時検知が必要です。Axiosメンテナー自身も、全端末のワイプ、全認証情報のリセット、OIDC採用、イミュータブルなリリース構成、GitHub Actionsの見直しを進めるとしています。

まとめ:OSSメンテナーは「高度な標的」である

「影響力の大きいパッケージのオープンソースメンテナーは、高度なソーシャルエンジニアリングの積極的な標的になっている。レジストリ上だけでなく、個人的な活動においても極度の警戒(Hyper vigilance)が必要だ」

事後報告のIssueは、この重い教訓とともに締めくくられています。インシデント発生時、不正な公開を自動で検知するシステムはなく、コミュニティの報告と別のコラボレーターの迅速な対応(約3時間での公開停止処理)によって最悪の事態は免れましたが、危険は常に隣り合わせです。

今回のAxiosのインシデントは、どんなに優秀な開発者であっても巧妙なソーシャルエンジニアリングの罠に落ちる可能性があること、そして「ローカルPCからの直接公開」という旧来のワークフローが、現代のOSSエコシステムにおいて致命的な弱点になることを、全世界の開発者に改めて突きつけました。

よくある質問(FAQ)

Q. 自社システムがAxiosの攻撃による影響を受けているか確認する方法は?

A. プロジェクトの package-lock.jsonyarn.lock などのロックファイル内で、[email protected] または [email protected]、あるいは悪意ある依存関係である plain-crypto-js が含まれていないかを検索してください。該当バージョンが見つかった場合、そのマシンやCI/CD環境はすでに侵害されている前提で対応する必要があります。

Q. 悪意のあるバージョンのAxiosをインストールしてしまっていた場合、何をすべきですか?

A. 単なるバージョンのダウングレードだけでは不十分です。直ちに plain-crypto-js を削除し、そのマシンまたはCI/CDランナー上に存在していたすべてのシークレットや認証情報(APIキー、トークンなど)をローテーション(再発行)してください。また、sfrclak[.]com または 142.11.206.73:8000 への不審な通信履歴がないかネットワークログを監査する必要があります。

Q. なぜメンテナーは二要素認証(2FA)を設定していたのに不正公開を防げなかったのですか?

A. 今回の攻撃では、メンテナーのPC自体が遠隔操作マルウェア(RAT)に乗っ取られていたためです。ローカルPCが完全な制御下に置かれると、認証アプリ等で生成されるワンタイムパスワード(TOTP)も攻撃者に傍受され、正規の認証セッションをハイジャックされてしまいます。そのため、侵害されたマシン上では通常のTOTPによる2FAは機能しません。

 

参照

Post Mortem: axios npm supply chain compromise