この記事はセキュリティ速報・解説記事です。 2026年6月17日、人気のAIエージェントOSS Mastra のnpmスコープで、144パッケージが侵害される大規模なサプライチェーン攻撃が発生しました。 Microsoftはこの攻撃を高い確度で北朝鮮の国家アクター Sapphire Sleet に帰属させています。 本稿は2026年6月22日（JST）時点で、Microsoft Security Blog・The Hacker News・BleepingComputer・Orca Securityの一次解析をもとに、攻撃の流れと緊急対処を整理します。
特に重要なのは、これが AI開発者を直接狙った 攻撃である点です。 窃取ペイロードはLLMのAPIキーとクラウド認証情報を標的にしており、Claude Code・各種エージェント開発でAPIキーを扱う開発者にとって他人事ではありません。
npmサプライチェーン攻撃全体の防御フレームワークと恒久対策については サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト をご覧ください。
- ・AIエージェントOSSMastraのnpm 144パッケージが、88分の自動化キャンペーンで侵害された（2026-06-17）。
- ・起点はメンテナ垢「ehindero」の乗っ取り。脆弱性ではなく正規の公開権限が悪用された。
- ・dayjs偽装のeasy-day-jsがpostinstallで起動し、TLS検証を無効化してC2からRATを投下。
- ・標的はLLM APIキー・クラウド認証情報。scdevサービスで永続化し再起動後も生存。
- ・npm install / update を実行した全端末・CIが対象。importの有無は無関係。
1. 何が起きたか — 88分で144パッケージが汚染
2026年6月17日、AIエージェント構築フレームワークとして広く使われるOSS Mastra のnpmスコープで、144パッケージ（一部報道では145）が一斉に侵害されました。 特筆すべきはそのスピードで、わずか88分の単一の自動化キャンペーン で汚染版が公開されています。
そもそもMastraは、TypeScriptでAIエージェントやワークフローを構築するためのオープンソースフレームワークで、エージェント開発の現場で広く採用が進んでいます。 依存として多くのプロジェクトに取り込まれているため、メンテナ垢を1つ落とすだけで一気に多数の開発環境へ到達できる——攻撃者から見て「費用対効果」の高い標的でした。 人気と依存の広さが、そのまま攻撃対象としての価値になってしまった構図です。
Microsoft Threat Intelligenceはこの活動を、高い確度で北朝鮮の国家アクター Sapphire Sleet に帰属させました。 Sapphire Sleetは、脅威インテリジェンス各社により APT38 / BlueNoroff / Stardust Chollima / TA444 としても追跡されているグループです。 暗号資産の窃取や開発者を狙ったソーシャルエンジニアリングで知られ、近年はサプライチェーンを経由した認証情報窃取に軸足を移しています。
この攻撃は「Mastraを使っているか」ではなく「侵害期間に npm install / update を実行したか」で被害が決まる。パッケージをアプリでimportしていなくても、依存ツリーに引き込まれた時点でpostinstallが走る。CI/CDパイプラインも例外ではない。
2. 攻撃の起点 — メンテナ垢乗っ取りとdayjs偽装（easy-day-js）
今回の侵害は、ソフトウェアの脆弱性ではなく アカウント乗っ取り が起点です。 Mastraエコシステム全体に公開（publish）権限を持つnpmメンテナアカウント 「ehindero」 が乗っ取られ、その正規の権限で汚染版が公開されました。
汚染版には、人気ライブラリ dayjs を偽装したtyposquatパッケージ「easy-day-js」 が混入されていました。 名前が紛らわしく、依存ツリーの奥に紛れ込むと気づきにくいのが狙いです。
攻撃の流れを図にすると次のようになります。
Mastra全体の publish 権限を取得"] --> B["汚染版を正規ルートで publish
144パッケージ・88分"] B --> C["dayjs偽装 easy-day-js を混入"] C --> D["npm install / update で
postinstall フックが実行"] D --> E["難読化ドロッパー起動
TLS証明書検証を無効化"] E --> F["C2へ接続し2段目を取得
隠しプロセスとして実行"] F --> G["認証情報窃取RAT
LLM APIキー・クラウド資格情報を窃取"] G --> H["PowerShellバックドア展開
scdevサービスで永続化・再起動耐性"]
正規のメンテナアカウントから公開されたため、レジストリ上は 見かけ上ふつうの更新 として配布されました。 署名やprovenanceの仕組みを破ったのではなく、正当な公開権限がそのまま悪用された 点が、この攻撃の防ぎにくさの核心です。
3. ペイロードの中身 — TLS検証無効化からscdev永続化まで
easy-day-jsがインストールされると、postinstallフック が連鎖的に次を実行します。
・難読化されたドロッパースクリプトを起動
・TLS証明書の検証を無効化（通信内容の検査・遮断を回避）
・攻撃者管理のC2インフラへ接続
・2段目のペイロードをダウンロード
・デタッチされた隠しプロセス として実行
2段目は 認証情報窃取型のRAT で、Microsoftの解析によれば標的は LLMのAPIキー・クラウド認証情報・その他の機密データ です。 さらにSapphire Sleetは、別インフラから PowerShellバックドア を展開し、端末の完全掌握に進みます。
主要な痕跡（IoC）と挙動を整理すると次のとおりです。
| 指標 / 挙動 | 内容 |
|---|---|
| 侵害メンテナ垢 | ehindero（Mastra全体の公開権限） |
| 悪性パッケージ | easy-day-js（dayjsのtyposquat） |
| 初動 | postinstallフック → 難読化ドロッパー |
| 回避 | TLS証明書検証の無効化 / Microsoft Defenderの除外設定追加 |
| 標的データ | LLM APIキー・クラウド認証情報・各種シークレット |
| 永続化 | サービス scdev をインストール（SYSTEM権限・再起動後も生存） |
| 最終状態 | 対話的リモートアクセス（フルコントロール） |
注目すべきは Defenderの除外設定追加 と scdevによる永続化 です。 単発の情報窃取で終わらず、検知回避とSYSTEMレベルの居座りまで作り込まれており、一度踏むと端末の信頼性が根本から失われる 設計になっています。
ここで効いている2つの回避テクニックの意味を補足します。 TLS証明書検証の無効化 は、企業のプロキシやセキュリティ製品が行う「通信内容の検査（TLSインスペクション）」を回避し、C2との通信を成立させやすくするための仕込みです。 Defenderの除外設定追加 は、以後ダウンロードする2段目ペイロードや永続化サービスがスキャン対象から外れるようにするもので、最初の足場を取った直後に検知の網を自分で広げていく 動きです。 この2つが揃うことで、一般的なEDRやネットワーク監視の初期検知をすり抜けやすくなります。 つまり postinstall の一瞬で「通信の検査回避」と「端末側の検知回避」を同時に仕込む、効率重視の設計になっているわけです。
4. 誰が影響を受けるか — importの有無は無関係
被害範囲の判定基準はシンプルです。
侵害版が公開された後（2026-06-17前後）に、npm install または npm update を実行した開発者ワークステーションやCI/CDパイプラインは、潜在的に侵害対象。
ここで重要なのは、Mastraのパッケージをアプリケーションコードでimportしているかどうかは関係ない という点です。 postinstallはインストール時点で走るため、依存ツリーに引き込まれただけで実行されます。 普段Mastraを直接使っていなくても、間接依存やtyposquatの easy-day-js を経由して巻き込まれる可能性があります。
特にCI/CDは要注意です。
クリーンビルドのたびに npm install を走らせる構成では、ビルドサーバーがそのまま標的になります。
CIに置かれた デプロイ用クラウド認証情報やレジストリトークン が、もっとも価値の高い窃取対象になり得ます。
具体的に危ないのは、たとえば次のような構成です。
キャッシュを使わずに毎回まっさらな環境で npm install を実行し、環境変数にデプロイ用のクラウドキーやnpm公開トークンを渡しているCIジョブ。
ここでpostinstallが走れば、ジョブの実行コンテキストにある すべての環境変数（＝鍵の束）が一度に抜かれる 危険があります。
しかもCIは自動で何度も回るため、開発者が異変に気づく前に窃取が完了します。
「人の端末より、無人で鍵を持つCIの方が危ない」という意識を持っておくべきです。
5. 緊急対処と検知
まずは「踏んでいないか」の確認から始めます。 lockファイルとインストール履歴を起点に調べます。
# 1) lockファイルに easy-day-js や侵害版が無いか検索
grep -nE "easy-day-js|@mastra" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
# 2) 依存ツリーに easy-day-js が引き込まれていないか
npm ls easy-day-js 2>/dev/null
# 3) 永続化サービスの確認（Windows）
sc query scdev
該当が疑われる場合の対処は、「資格情報のローテーション」を最優先 に進めます。
・当該端末・CIから触れた LLM APIキー（Anthropic / OpenAI 等）を即時失効・再発行
・クラウド認証情報（AWS/GCP/Azureのアクセスキー・トークン）をローテーション
・npm / GitHub のトークン を失効し、MFAを再確認
・侵害が確定した端末は クリーンインストールを前提 に隔離（scdev等の永続化を考えると駆除より再構築が安全）
・lockファイルを侵害前のコミットに戻し、依存を固定し直す
最も効くのは
npm install --ignore-scripts の既定化。lifecycle script（postinstall等）の自動実行を止めれば、今回のような「インストールしただけで発火」型の初動を断てる。どうしてもscriptが必要なパッケージだけ個別に許可する運用にする。侵害が確定した場合は、駆除（クリーニング）ではなく 再構築を前提 に動くのが安全です。 scdevのような永続化サービスとDefender除外が仕込まれている以上、「消したつもりで残る」リスクが高いためです。 おすすめの復旧順序は次のとおりです。
- 隔離：該当端末・CIランナーをネットワークから切り離す（C2通信と横展開を止める）
- 鍵の失効：その端末から到達可能だった全シークレット（LLM APIキー・クラウド認証・npm/GitHubトークン・SSH鍵）を失効。盗まれた前提で動く
- 影響調査：失効した鍵の利用ログを確認し、不正利用（高額な推論課金・不審なリソース作成）が無いか点検
- 再構築：端末はOSからクリーンインストール。CIランナーはイメージから作り直す
- 依存の巻き戻し：lockファイルを侵害前のコミットへ戻し、
easy-day-jsを含まないことを確認してから復旧 - 再発防止：
--ignore-scripts既定化とpublishトークンのMFA・短命化を、復旧と同時に入れる
このうち最優先は 2の鍵の失効 です。 端末の再構築は時間がかかりますが、その間にも盗まれた鍵は悪用され続けます。 「まず鍵を止める、次に端末を直す」の順序を崩さないことが、被害を最小化する鍵になります。
6. なぜ「AIフレームワーク」が狙われたのか
今回の標的がAIエージェントフレームワークだったのは、偶然ではありません。 ThreatLockerが指摘するように、攻撃の本質は「AIそのもの」ではなく 開発者が握っている資格情報の価値 にあります。
AI開発のワークステーションには、いま最も換金性・悪用価値の高い鍵が集まっています。
・LLM APIキー：そのまま高額な推論コストを焼かれる、あるいは転売される
・クラウド認証情報：計算資源の不正利用（暗号資産マイニング等）や横展開の起点
・npm/GitHubトークン：次のサプライチェーン攻撃の踏み台
Sapphire Sleetは金銭・諜報を目的に動く国家アクターであり、AI開発者は 「鍵の束を持ち歩く高価値ターゲット」 として狙われています。 人気が高く依存の広いAIフレームワークのメンテナ垢を1つ落とせば、一気に多数の開発者へ到達できる——この「到達効率」がAIエコシステムを狙う動機になっています。
加えて、AI開発の現場特有の事情も攻撃を後押ししています。
新しいフレームワークやSDKを次々と試すために 依存を頻繁に追加・更新する 文化があり、npm install を回す頻度が高い。
ローカルとCIの両方でAPIキーやクラウド認証を扱うため、鍵が分散して常駐 しやすい。
こうした「動きの速さ」が、サプライチェーン攻撃にとっては好都合な土壌になっています。
利便性のために緩めた設定（lifecycle scriptの自動実行、依存の自動追従）が、そのまま攻撃面になっているのが実情です。
同種の手口は他のエコシステムでも続いており、本サイトでも npmサプライチェーン侵害「Miasma」｜redhat-cloud-services 31パッケージに自己増殖ワーム や、MCPを狙った Hades｜MCPサプライチェーンを這う自己増殖ワーム で取り上げてきました。 攻撃の「型」は共通しており、対策も共通します。
7. 2026年のnpmサプライチェーン攻撃の系譜
今回のMastra侵害は、突発的な事件ではなく 2026年に連続している一連のnpm/レジストリ攻撃の最新形 です。 近い時期の主要事案を並べると、共通する「型」と、Mastra事案の特徴がはっきりします。
| 事案 | 時期 | 起点 | 特徴 |
|---|---|---|---|
| Shai-Hulud（自己増殖ワーム） | 2026前半〜 | 窃取トークンの連鎖悪用 | 盗んだ認証情報で次々と公開し自己増殖 |
| Miasma（@redhat-cloud-services） | 2026-06-01 | 従業員GitHub/CIの悪用 | preinstallで別ランタイム実行・認証情報窃取 |
| Mastra（本件） | 2026-06-17 | メンテナ垢ehinderoの乗っ取り | postinstall→RAT→scdev永続化・LLM鍵窃取 |
並べると、3つに共通する設計思想が見えてきます。
・正規の公開ルートを使う：脆弱性ではなく、乗っ取った正規アカウント/CIから公開する。だから署名やprovenanceをすり抜ける
・lifecycle scriptで初動を取る：preinstall / postinstall を使い、「インストールしただけで発火」させる
・狙いは認証情報：npm・GitHub・クラウド・そして今回はLLM APIキーまで。窃取した鍵で次の攻撃に連鎖する
Mastra事案が際立つのは、スピード（88分）、国家アクターの関与（Sapphire Sleet）、そして 永続化の作り込み（scdev・Defender除外） の3点です。 情報窃取で終わらず端末掌握まで設計されている点は、金銭・諜報目的の国家アクターらしい徹底ぶりと言えます。
そしてもう一つの新しさが、標的にLLM APIキーが明示的に含まれている ことです。 AI開発が普及し、開発者の手元に高価値な推論APIの鍵が常駐するようになった結果、サプライチェーン攻撃の「換金先」としてLLM鍵が組み込まれ始めた——その象徴的な事例が本件です。
8. 恒久対策 — このシリーズに共通する教訓
単発の駆除で終わらせず、再発を防ぐ構えに落とし込むことが重要です。 これまでのnpm/MCPサプライチェーン攻撃と共通する、効果の高い対策を挙げます。
・publishトークンの短命化・MFA必須化・人手承認ゲート：メンテナ垢の乗っ取りが起点になる以上、ここが最重要
・CIでの ignore-scripts 既定化：lifecycle scriptの自動実行を止め、「入れただけで発火」を断つ
・依存のバージョンピン留めと即時更新の抑制：^ や latest での自動追従をやめ、更新は検証してから
・lockファイル差分のレビュー：見覚えのないパッケージ（typosquat）が増えていないかをPRで監視
・シークレットの最小権限・短命化：盗まれても被害を限定できるよう、APIキー・クラウド認証を絞る
・EDR/監視のチューニング：Defender除外の追加や不審サービス（scdev等）の作成を検知できるようにする
これらは一つひとつは地味ですが、「メンテナ垢が落ちても被害を最小化する」 という前提に立った多層防御です。 署名やSBOMは「誰が出したか」を保証するだけで「中身が安全か」は保証しません。 今回のように正規の公開者が乗っ取られるケースでは、実行時の最小化（ignore-scripts）と資格情報の最小化 が最後の砦になります。
まとめ
2026年6月17日のMastra npmサプライチェーン攻撃は、AI開発者の資格情報を直接狙った、国家アクターによる高速・大規模なサプライチェーン侵害 でした。
確認できた事実を整理すると、次のようになります。
・AIエージェントOSS Mastra のnpm 144パッケージが、88分の自動化キャンペーンで侵害された
・起点はメンテナ垢「ehindero」の乗っ取り。脆弱性ではなく正規の公開権限の悪用
・dayjs偽装の easy-day-js がpostinstallで起動し、TLS検証を無効化してC2からRATを投下
・標的はLLM APIキー・クラウド認証情報。scdevサービスで永続化し再起動後も生存
・npm install / update を実行した全端末・CIが対象。importの有無は無関係
・Microsoftは高確度で北朝鮮Sapphire Sleet（APT38/BlueNoroff）に帰属
いま最初にやるべきは2つ。①lockファイルに easy-day-js が無いか確認、②侵害期間にnpm install/updateした端末・CIのLLM APIキーとクラウド認証を即ローテーション。恒久対策はCIの
--ignore-scripts 既定化とpublishトークンのMFA・短命化。AI開発端末は「鍵の束を持つ高価値ターゲット」だと自覚して守るのが前提になる。参照ソース
・From package to postinstall payload（Microsoft Security Blog）
・144 Mastra npm Packages Compromised via Hijacked Contributor Account（The Hacker News）
・Microsoft links Mastra AI supply chain attack to North Korean hackers（BleepingComputer）
・144 Mastra npm Packages Compromised via Supply Chain Attack（Orca Security）
・サプライチェーンセキュリティ2026（本サイト・ピラー）
