title: "Mastra npm 144パッケージがバックドア化｜AI開発の依存管理が狙われたサプライチェーン攻撃（Sapphire Sleet）" description: "2026年6月、AIエージェント開発フレームワークMastraのnpmパッケージ140本超がバックドア化され、Microsoftは北朝鮮系Sapphire Sleetに帰属した。AI機能を内製・外注で開発する企業が今すぐ確認すべきnpm依存管理、postinstall制御、CI/CD波及、影響確認手順とチェックリストを整理する。" keyword: "Mastra npm サプライチェーン攻撃 バックドア AI開発 依存管理 北朝鮮" slug: "mastra-npm-supply-chain-backdoor-sapphire-sleet-20260625" date: "2026-06-25" updatedAt: "2026-06-25" category: "セキュリティ" tags: ["サプライチェーン攻撃","npm","AI開発","Mastra","DevSecOps"] author: "GXO株式会社" lead_summary: "AI開発フレームワークMastraのnpmパッケージ140本超がバックドア化。AI機能を開発する企業の依存管理リスクを整理する。"
Mastra npm 144パッケージがバックドア化｜AI開発の依存管理が狙われたサプライチェーン攻撃（Sapphire Sleet）
結論：AI開発の「足元」であるnpm依存が、国家支援型攻撃の標的になった
2026年6月17日、AIエージェント開発フレームワーク「Mastra」のnpmパッケージ140本超（報道では142〜145本と幅がある）が、悪意あるバージョンに差し替えられた。Microsoftは6月19日、この攻撃を北朝鮮系の脅威アクター Sapphire Sleet（別名 BlueNoroff／APT38の関連系統として報じられる） に高い確度で帰属している。
押さえるべき結論は、製品の脆弱性ではなく**「自社が利用する開発部品（npmパッケージ）そのものが乗っ取られた」**という点である。AIチャットボット、RAG、AIエージェントを内製または外注で開発している企業は、自社コードを一行も書き換えなくても、npm install を一度実行しただけで認証情報を窃取されうる構造に置かれた。
押さえるべき1点：AI開発のセキュリティは「作ったアプリ」だけでなく「ビルドに使う依存パッケージとCI/CDパイプライン」まで含めて設計する必要がある。
この記事は、AI機能を開発・運用する企業の情シス、開発リーダー、セキュリティ担当に向けて、何が起きたか／なぜAI開発でnpmが攻撃面になるのか／自社の影響をどう確認するかを、一次情報をもとに整理する。依存管理・CI/CDまで含めた堅牢な開発体制づくりはDevSecOpsによるセキュア開発体制で、外注で作ったAI機能のサプライチェーンリスクの第三者点検はセキュリティの脆弱性診断で扱う領域である。サプライチェーン攻撃の被害パターンを類型で押さえたい場合はセキュリティ失敗図鑑も参照されたい。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
何が起きたか（時系列）
Microsoft Security Blog（2026年6月17日公開）および各セキュリティベンダーの報告にもとづくと、攻撃の流れは次の通りである。
| 時点（UTC） | 出来事 |
|---|---|
| 6月16日 07:05頃 | 攻撃者が easy-day-js（人気ライブラリ dayjs を装ったタイポスクワット）の「無害なおとり版」1.11.21 を公開 |
| 6月17日 01:01頃 | 同パッケージの「武器化版」1.11.22 を公開。postinstallフックに難読化されたドロッパーを仕込む |
| 6月17日 01:20頃 | 乗っ取った正規メンテナーアカウント（ehindero）を使い、Mastra系140本超のパッケージに easy-day-js を新規依存として注入し、latest タグで再公開（再公開のバーストはこの後しばらく続いた） |
| 6月19日 | MicrosoftがSapphire Sleetへの帰属を公表 |
ここで巧妙なのは、悪意ある中身はMastra本体に直接入っていない点である。Mastra側のパッケージは easy-day-js@^1.11.21 という依存指定（パッチバージョン1.11.21以上を許容）を持たされていた。そのため、攻撃者が後から武器化版 1.11.22 を公開すると、npmのSemVer解決によって新規インストール時に自動で武器化版へ更新された。利用者から見れば、いつも通り npm install を実行しただけで攻撃コードが走る状態だった。
時刻は出典により幅がある。Microsoftの一次ブログは武器化版
easy-day-jsの公開を6月17日 01:01 UTC頃、Mastra系パッケージ群の再公開を01:20 UTC頃と記述している。一方、複数の二次解析は再公開のバーストを約88分（おおむね01:12〜02:36 UTC）と報じている。いずれにせよ、短時間のうちに大量のパッケージが一斉に差し替えられた点が本質である。
攻撃の起点は、Mastraに過去に関与していた元コントリビューターの ehindero アカウントだったと報じられている。そのアカウントの公開（publish）権限が、関与終了後も剥奪されずに残っていたことが、大量再公開を許した根本原因の一つとして指摘されている。
ペイロードは何を狙ったか
easy-day-js の postinstall フックは、難読化されたドロッパーを実行する。Microsoftの一次報告および複数ベンダーの解析を総合すると、挙動には次が含まれる。
- TLS検証の無効化、追跡マーカーの設置、C2（指令）サーバへの通信
- C2サーバから第2段ペイロードを取得し、ランダム名の
.jsとして書き出して、ウィンドウ非表示の独立Nodeプロセスとして起動 - ブラウザ（Chrome／Edge／Brave）の履歴・拡張機能の収集、ホスト調査（インストール済みアプリ・実行中プロセス）
- 暗号資産ウォレット拡張機能（166種のID）の探索
報道・ベンダー解析によると、第2段ペイロードはWindows／macOS／Linuxに対応したクロスプラットフォームRATで、LLMのAPIキーやクラウド認証情報の窃取も狙うとされる。Sapphire Sleetは金融・暗号資産・ブロックチェーン領域を主標的とする攻撃者として知られる。
C2との通信が確認された端末では、Sapphire Sleetが従来用いてきた手口（PowerShellバックドア、永続化、Microsoft Defenderの除外設定、SYSTEM権限を得る悪性Windowsサービス）に類する追跡が報告されている。
重要な含意：開発端末やCI/CDのビルド環境には、LLM APIキー、クラウド認証情報、CI/CDトークン、DB接続文字列が揃っていることが多い。AI開発環境はまさにこの攻撃者が欲しい資産の宝庫であり、AIフレームワークの依存が狙われたのは偶然ではない。
なぜAI開発でnpm依存が「攻撃面」になるのか
AIアプリ開発は、JavaScript／TypeScriptエコシステム（npm）の上に成り立つことが多い。AIエージェント、RAG、チャットボットを作るとき、自社が書くコードは全体のごく一部で、大半は外部パッケージである。ここに構造的なリスクがある。
| 観点 | 従来の社内システム開発 | AIアプリ開発の現状 |
|---|---|---|
| 依存の数 | 比較的限定的 | 数百〜数千の間接依存を引き込みやすい |
| 更新頻度 | 安定後は固定しやすい | フレームワークが活発で頻繁に更新される |
| 攻撃者の動機 | 個別企業の情報 | 開発端末・CIにあるAPIキー・クラウド鍵 |
| 信頼の前提 | ベンダー契約・検収 | 「人気がある＝安全」という暗黙の信頼 |
| 侵入経路 | アプリの脆弱性 | ビルド時のpostinstall・間接依存 |
ポイントは三つある。
- 直接依存だけ見ても足りない。今回の悪意あるコードは、Mastra本体ではなく「Mastraが依存する
easy-day-js」という一段下に隠れていた。package.jsonのトップだけ見ても気づけない。 postinstallは任意コードを実行できる。npmのライフサイクルスクリプトは、インストールの一環として開発者の端末・CIで自由にコードを走らせられる。AIアプリ開発のように依存が多い環境ほど、この実行点が増える。- ダウンロード数の多さは安全の保証ではない。Mastraの中核パッケージは週あたり相当数（一部報道で
@mastra/core約91.8万DL／週）の利用があったが、人気があるからこそ被害が広がった。「みんな使っているから安全」という前提は、サプライチェーン攻撃では逆に作用する。
自社の影響をどう確認するか（実務手順）
「うちはMastraを使っていないから無関係」と即断しないこと。AI機能を外注している場合、自社が把握していないところで依存に入っている可能性がある。以下の手順で確認する。
1. Mastra系・easy-day-js の混入確認
package-lock.json/pnpm-lock.yaml/yarn.lockをeasy-day-jsで全文検索するnpm ls @mastra/coreなどで Mastra系パッケージの導入有無とバージョンを確認する- 自社リポジトリだけでなく、外注先・委託先の納品物にも同じ確認を依頼する
具体的な悪性バージョン番号やインジケータ（IOC）は、Microsoftおよびnpm公式アドバイザリの最新情報を一次情報として参照すること。本記事掲載後に追加・更新される可能性がある。
2. インストール時のコード実行（postinstall）を制御する
- 当面の緊急対応として、CI/CDや本番ビルドで
npm install --ignore-scriptsを用い、ライフサイクルスクリプトの自動実行を止める運用を検討する - どうしてもスクリプト実行が必要なパッケージは、許可リスト方式で限定する
3. 依存をピン留め（固定）する
^や~のような範囲指定は、今回のように「後から武器化された新バージョン」を自動で引き込むリスクがある- ロックファイルを必ずコミットし、CIでは
npm ci（ロックファイル厳守）を使う - 重要な本番ビルドでは、依存バージョンを完全固定し、更新は人がレビューしてから行う
4. CI/CDと認証情報の波及を点検する
- ビルド環境に置かれているLLM APIキー、クラウド鍵、CIトークン、DB接続情報を洗い出す
- 該当端末・CIで近日中にインストールが走っていた場合は、**侵害前提で当該シークレットをローテーション（再発行）**する
- ビルド環境からの外向き通信（C2宛て）の有無をログで確認する
5. SBOMと継続監視を整える
- ソフトウェア部品表（SBOM）を生成し、どのパッケージ・バージョンを使っているかを可視化する
- 依存の脆弱性・改ざんを継続監視する仕組み（依存スキャン、署名・来歴検証）を開発フローに組み込む
チェックリスト：AI開発の依存管理セルフ点検
| 項目 | 確認内容 | できている／要対応 |
|---|---|---|
| 依存の可視化 | 直接・間接依存を含めて一覧化（SBOM）している | |
| ロックファイル | lockファイルをコミットし、CIで npm ci を使っている | |
| バージョン固定 | 本番依存を範囲指定でなく固定し、更新を人がレビューしている | |
| スクリプト制御 | postinstall等の自動実行を制限・許可制にしている | |
| 外注の納品物 | 委託先の依存・ロックファイルも点検対象に含めている | |
| シークレット分離 | 開発端末・CIの鍵を最小権限・短命化している | |
| ローテーション手順 | 侵害疑い時に鍵を即ローテーションする手順がある | |
| publish権限の棚卸し | 自社が公開するパッケージのメンテナー権限を定期棚卸ししている | |
| 継続監視 | 依存改ざん・脆弱性を継続検知する仕組みがある | |
| インシデント窓口 | 侵害検知時の社内連絡・対応フローが決まっている |
このうち半分以上が「要対応」なら、AI開発のサプライチェーンは現状ほぼ無防備に近い。一度PoCが動いたAIアプリほど、本番化の前にこの点検を通すべきである。
よくある質問（FAQ）
Q. Mastraを使っていなければ安心ですか。 A. 必ずしも安心とは言えません。AI機能を外注している場合、納品物の依存にMastra系が含まれている可能性があります。また、今回の手口（人気ライブラリのタイポスクワット＋postinstall）はMastra固有ではなく、他のパッケージでも再現しうる汎用的な攻撃です。
Q. npm audit を通していれば防げましたか。
A. 限界があります。npm audit は既知の脆弱性データベースに依存するため、公開直後の改ざんパッケージは検知が遅れることがあります。範囲指定の自動更新を許す設定では、監査が追いつく前にインストールが走り得ます。
Q. 結局いちばん効く対策は何ですか。
A. 単一の銀の弾丸はありません。実務上効果が高いのは「ロックファイル＋固定バージョン＋npm ci」「postinstallの実行制御」「開発・CI環境の鍵の最小権限化と侵害時の即ローテーション」の組み合わせです。
Q. 自社でAIプロダクトを公開している場合、特有のリスクは。 A. あります。今回の根因の一つは、関与終了後も残っていたメンテナーのpublish権限でした。自社がnpm等にパッケージを公開している場合、メンテナー権限の棚卸しと、二要素認証・公開時の来歴（provenance）付与を整備すべきです。
Q. AI開発を外注しています。発注側として何を確認すべきですか。 A. 「使用OSSと依存の一覧（SBOM）」「ロックファイルのコミット運用」「脆弱性・改ざん監視」「インシデント対応窓口」を契約・検収条件に含めることを推奨します。コードの完成だけを検収条件にすると、依存リスクが見落とされがちです。
読むべき人
- AIチャットボット・RAG・AIエージェントを内製している開発リーダー、情シス
- AI機能の開発を外注している事業部・購買・情シス（納品物の依存が見えていない方）
- npm／JavaScriptエコシステムでビルドしているCI/CDの管理者
- 自社プロダクトをnpm等に公開しているチーム（メンテナー権限を持つ立場）
いつGXOに相談すべきか
- AIアプリを本番化する前に、依存管理・CI/CD・シークレット管理を含めて堅牢性を点検したい
- 外注で作ったAI機能の依存・サプライチェーンリスクが見えておらず、第三者に確認させたい
- 今回のような事案を受けて、開発フローにSBOM・依存監視・postinstall制御を組み込みたい
- 侵害の可能性があり、影響範囲調査と鍵のローテーション、再発防止設計を急ぎたい
GXOでは、AIアプリ・AIエージェント開発を、機能だけでなく**依存管理・CI/CD・シークレット管理・監査ログまで含めたセキュアな開発（DevSecOps）**として設計します。「PoCは動いたが本番審査に通るか不安」という段階の相談を多く扱っています。
開発の堅牢性そのものは、セキュアな開発・サプライチェーン対策（DevSecOps）で整理しています。AI機能の新規開発・刷新はAI開発、すでに動いているシステムの弱点確認はセキュリティ診断（脆弱性診断）、社内データを安全に扱うRAG構築はRAG開発をご覧ください。
なお、AI開発の依存管理を社内で点検するためのサプライチェーン対策チェックリストを無料ダウンロードできる。稟議や外注先への確認依頼の添付資料として活用してほしい。
関連記事
- npmサプライチェーン攻撃 2026年版｜provenanceでも汚染される防御設計チェックリスト
- axios npm汚染の影響確認とインシデント対応
- Agentjacking｜社内MCP接続したAIエージェントが乗っ取られる新攻撃と対策
SNSで刺さる論点
- AI開発のセキュリティは「作ったアプリ」だけじゃない。
npm installを1回叩いた瞬間が一番危ない - 人気140本超のAIパッケージが88分でバックドア化。「みんな使ってるから安全」は逆に危険
- 悪意あるコードは本体ではなく「依存の依存」に隠れていた。
package.jsonのトップだけ見ても気づけない - 外注でAIを作っている会社こそ要注意。自社が把握していない依存にリスクが潜む
参考資料
- Microsoft Security Blog「From package to postinstall payload: Inside the Mastra npm supply chain compromise by Sapphire Sleet」（2026年6月17日）https://www.microsoft.com/en-us/security/blog/2026/06/17/postinstall-payload-inside-mastra-npm-supply-chain-compromise/
- The Hacker News「144 Mastra npm Packages Compromised via Hijacked Contributor Account」https://thehackernews.com/2026/06/144-mastra-npm-packages-compromised-via.html
- BleepingComputer「Microsoft links Mastra AI supply chain attack to North Korean hackers」https://www.bleepingcomputer.com/news/security/microsoft-links-mastra-ai-supply-chain-attack-to-north-korean-hackers/
- StepSecurity「Mastra npm Supply Chain Attack: 140+ Packages Backdoored via easy-day-js Typosquat」https://www.stepsecurity.io/blog/mastra-npm-packages-compromised-using-easy-day-js
本記事は2026年6月25日時点の公開情報をもとに作成。具体的な悪性バージョン番号やインジケータ（IOC）、影響範囲は、Microsoftおよびnpm公式アドバイザリの最新情報を一次情報として確認すること。報道のみで裏取りできていない数値・挙動は本文中で「報道によると」と明示している。
npm install一回で認証情報を抜かれる前に、依存管理を点検しませんか
GXOでは、AIアプリ・AIエージェント開発を、機能だけでなく依存管理・CI/CD・シークレット管理・監査ログまで含めたセキュアな開発として設計します。内製・外注いずれの相談も歓迎です。
セキュアな開発・サプライチェーン対策を見る AI開発・依存管理の相談をする
※ 外注で作ったAI機能の依存が見えていない場合も相談可 | 情シス・開発・セキュリティ担当の同席歓迎
