【2026年6月17日発生】AIエージェントフレームワークMastraを狙ったnpmサプライチェーン攻撃の特徴と対応策を解説

2026年6月17日(UTC)未明、TypeScript製のAIエージェントフレームワーク Mastra の npm スコープ @mastra/* を起点とした、大規模なサプライチェーン攻撃が発生しました。攻撃者は侵害したメンテナーアカウントを使い、わずか1時間半ほどの間に141パッケージを悪意あるバージョンへ再公開しました。これらパッケージの週間ダウンロード数は合計で110万を超えます。

用いられた手口の一つひとつは過去のnpmサプライチェーン攻撃でも確認されてきたものですが、利用が拡大しているAIエージェント開発フレームワークが標的となった点で注目されます。AIエージェントの開発・CI環境にはLLMのAPIキーやクラウド認証情報が集中しており、窃取された場合の影響は小さくありません。

本記事では、Mastra公式の GitHub Issue をもとに、攻撃の特徴・脅威・確認方法・対応策を解説します。

国内唯一のISMAP登録済
脆弱性管理ツール

サマリー

今回の攻撃の4つの特徴

① メンテナーアカウントの侵害

正規コントリビューター ehindero の npm アカウントが乗っ取られ(登録メールが @tutamail.com へ変更)、@mastra/core ・ mastra ・ create-mastra を含む141パッケージの publish 権限が悪用されました。

② タイポスクワットによる悪性依存の注入

各パッケージに、日付ライブラリ dayjs を模した悪性パッケージ easy-day-js を依存として追加。前日に公開した「おとり」バージョンと ^ 指定により、悪性版へ自動解決させました。

③ npm のインストール時スクリプト( postinstall )による起動

④ ドロッパーによる本体展開と情報窃取

ドロッパーは TLS 検証を無効化して C2 サーバから RAT 本体を取得・起動します(ドロッパー自身は実行後に削除)。RAT の挙動は分析が継続中ですが、最終的には暗号資産や LLM の API キー・クラウド認証情報などの窃取を狙うものとみられます。

今回は、組織のパッケージ群へ一括で publish できる権限が侵害されたため、広範囲のパッケージが一度に汚染された点が被害を大きくしています。また、攻撃者は前日からパッケージを準備しておくなど攻撃を検知されないための活動がみられます。

一方で攻撃の実行は postinstall に依存しており、スクリプトの無効化やクールダウン戦略という基本的な防御で十分に対処可能な攻撃であり、過去の対策を実施していれば被害を回避できた可能性が高いといえます。

事象の解説

時系列タイムライン

最初に汚染が確認されたのは、週間123万ダウンロードを持つ @mastra/schema-compat でした。攻撃開始から npm による削除まで約6時間、この間にCI/CDや開発端末で install を実行した環境は侵害の可能性があります。

影響を受けたパッケージ

@mastra/* スコープを中心に141パッケージが影響を受けました。代表的な汚染バージョンは以下の通りです。

※いずれも publisher は乗っ取られた ehindero

このほか  @mastra/server ・ @mastra/rag ・ @mastra/openai ・ @mastra/claude など、各種LLMプロバイダ連携・DBアダプタ・音声・オブザーバビリティ系の連携パッケージも広範に含まれます。正確な侵害バージョン一覧は、Mastra公式 Issue および各アドバイザリを参照してください。

攻撃メカニズム

メンテナーアカウントの乗っ取り

正規コントリビューター ehindero の npm アカウントが乗っ取られ、紐づくメールが @tutamail.com へ変更されました。攻撃者はこの publish 権限を用いて @mastra/* を一斉に再公開しています。 easy-day-js を公開した sergey2016 も同じ @tutamail.com ドメインを使っており、同一の攻撃者によるものと見られます。

タイポスクワット easy-day-js の注入

各 @mastra/* パッケージの package.json に easy-day-js@^1.11.21 が1行追加されました。前日に公開済みのおとり 1.11.21 により正当に見せかけつつ、キャレット指定で悪性の 1.11.22 に自動解決させる設計です。 easy-day-js の 1.11.22 には postinstall フックが仕込まれ、node setup.cjs を実行します。

dayjs に酷似した名称や、おとりバージョンによる正当性の偽装、後述するドロッパーの自己削除には、人によるレビューや事後調査をすり抜ける意図が共通して見られます。

多段ペイロード

• カスタムBase64・配列ローテーション・XORエンコードによる3層の難読化
• 環境変数 NODE_TLS_REJECT_UNAUTHORIZED=0 でTLS証明書検証を無効化
• C2(23.254.164[.]92:8000/update/49890878)から本体をダウンロードし、/tmp 配下のランダム名ファイルに保存
• Stage 2 の C2 アドレスを引数に渡してデタッチ済みバックグラウンドプロセスとして起動
• 実行後、自分自身を削除して痕跡を消去
• 一時ディレクトリ(os.tmpdir())にビーコン/マーカーを書き込み(.pkg_history = インストール先の絶対パス、.pkg_logs = パッケージ名)

Stage 2 の本体は npm パッケージには同梱されておらず、ドロッパーが実行時に C2(23.254.164[.]123:443)から取得します。この「本体を後から取りに行く」設計は、攻撃者にとって次の利点があります。

• レジストリ上の静的スキャン回避: 公開された tarball に含まれるのはドロッパーのみで、悪性の本体コードは含まれません。npm 上のコードをいくら静的解析しても、RAT 本体は見つかりません。
• ペイロードの差し替え・標的の選別: 本体をサーバ側で配信するため、攻撃者は標的や時間帯に応じて配信内容を変えたり、解析環境には無害なものを返したりできます。tarball から得られる IoC だけでは「実際に何が動いたか」を特定できません。
• 痕跡の最小化: ドロッパーの自己削除と相まって、調査側に残る材料が少なくなります。

各社の報告では、暗号資産の窃取や、後述する環境変数・認証情報の窃取を最終目的とする RAT とされていますが、詳細は分析が継続している段階です。

影響範囲

侵害された環境では、暗号資産ウォレットに加え、上記のStage 2 が取得する環境変数やローカル認証情報が窃取されるおそれがあります。Mastra はAIエージェントを構築するフレームワークであるため、開発・CI環境には次のような機密情報が集中しているケースが多く、被害が拡大しやすい点に注意が必要です。

窃取されるおそれのある情報

• LLM の API キー(OpenAI / Anthropic(Claude) など)
• クラウド認証情報(AWS / GCP / Azure)
• データベース接続情報・各種トークン
• CI/CD のシークレット

npm が悪意あるバージョンを削除した後も、削除前に install を実行した端末では、すでにドロッパーが起動し情報窃取が行われた可能性があります。「パッケージが削除されたから安全」とは判断できません。

影響を受けたかどうかの確認方法

以下のいずれかに当てはまる場合、影響を受けた可能性があります。

ロックファイル( package-lock.json / pnpm-lock.yaml / yarn.lock )や node_modules に easy-day-js が含まれているかが、最も明確な判定シグナルです。

緊急対応（感染が疑われる場合）

手順 1. 影響範囲の確認

① ロックファイル・依存ツリーの確認

# 悪意ある依存 easy-day-js の混入を確認(最重要)
grep -rn "easy-day-js" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null
grep -rn "easy-day-js" node_modules/*/package.json 2>/dev/null

# @mastra/* の解決バージョンを確認し、汚染バージョン一覧と照合
grep "@mastra/" package-lock.json | grep -v node_modules

② 悪意あるファイル・痕跡の確認

# 実行された痕跡(最重要): ドロッパーが残すビーコン/マーカー。
# setup.cjs と違い削除されず残るため、「実際に動いたか」の判定に有効。
# os.tmpdir() 配下: Linux は通常 /tmp、macOS は $TMPDIR
for d in /tmp "$TMPDIR"; do ls -la "$d/.pkg_history" "$d/.pkg_logs" 2>/dev/null; done

# ドロッパー本体: ただし実行後は fs.rmSync で自己削除されるため、
# 検出できるのは --ignore-scripts 等で未実行のまま残っている場合のみ。
find node_modules -name "setup.cjs" -path "*easy-day-js*" 2>/dev/null

③ ネットワークログの確認

CI/CDログや端末の通信ログから、C2への接続痕跡を探してください。

• 23.254.164.92(Stage 1 ドロッパーC2 / ポート8000)
• 23.254.164.123(Stage 2 RAT C2 / ポート443)
• TLS検証が無効化された不審なアウトバウンド通信

手順 2. シークレットの即時ローテーション

汚染環境からアクセス可能だったすべてのクレデンシャルを 「変更」ではなく「失効(Revoke)」 させた上で、新しいキーを発行してください。AIエージェント環境では特に LLMのAPIキー の失効を忘れないでください。

• LLM API キー(OpenAI / Anthropic 等)
• AWS / GCP / Azure のアクセスキー
• データベース認証情報・各種トークン
• npm publish トークン / GitHub PAT
• SSH秘密鍵、CI/CDのシークレット
• 端末上の暗号資産ウォレット(窃取前提で別端末へ移管)

自衛の強化

--ignore-scripts の徹底

今回の攻撃は postinstall フックに依存しているため、 npm install --ignore-scripts を徹底していれば、ドロッパーの実行を防げました。CI/CD では原則 npm ci --ignore-scripts を用い、ビルドに本当に必要な lifecycle script のみを明示的に許可する運用が有効です。

.npmrc に以下を設定することで、デフォルトでスクリプト実行を抑止できます。

ignore-scripts=true

クールダウン戦略

今回の侵害は、おとりの翌日に悪性版が公開され、約6時間で削除されました。新規公開直後のバージョンを即座に取り込まないだけで、この種の攻撃の大半を回避できます。

.npmrc で公開後の最低経過日数を設けるのが有効です。

# npm: 公開から7日未満のバージョンを取り込まない
min-release-age=7

• pnpm / Yarn でも同等の minimumReleaseAge 設定が利用可能
• 社内プロキシレジストリで新規バージョンの取り込みを遅延
• 依存更新PR(Renovate / Dependabot)の自動マージは、公開から一定期間経過後に限定

Provenance(SLSA署名)の確認

今回の汚染バージョンは npm Provenance を持っていませんでした。

@mastra/core@1.42.0 以前が GitHub Actions の OIDC 経由で公開されていたのと対照的です。Provenance attestation の有無を取り込み基準に組み込むことで、手動公開された不正バージョンを弾きやすくなります。

【今後の見通し】npm 本体でもライフサイクルスクリプトの自動実行が抑制される予定

以下は現時点で利用できる対策ではありませんが、今後の参考として補足します。近年 postinstall を悪用する攻撃が相次いだことを受け、npm 本体もインストール時スクリプトを既定で実行しない方向へ移行します。2026年7月リリース予定の npm v12 では、preinstall / install / postinstall などのライフサイクルスクリプトがデフォルトで実行されなくなる見込みです。

実行が必要なパッケージは npm approve-scripts で明示的に許可する運用に変わり、あわせて Git 依存の自動解決も既定で無効化されます。

今回のような postinstall を起点とする攻撃は、この変更によって大幅に成立しにくくなる見込みです。GitHub は事前準備として npm 11.16.0 以降への更新を推奨しており、v12 移行を待たずに、現時点から --ignore-scripts 運用へ寄せておくことが望ましいといえます。

また、可能であればよりセキュリティ設計が強固なpnpmへの移行も検討してください。

pnpmの移行メリットについては、ブログ「axios npmパッケージ侵害を防ぐ対応策を徹底解説」の対応策1をご確認ください。

サプライチェーンの脆弱性を可視化する 脆弱性管理クラウドyamoryのご紹介

株式会社アシュアードが提供する脆弱性管理クラウド「yamory」は、システム内に潜む脆弱性などのITリスクの検知から対応の優先度付けまでを自動で行う、国産のクラウドサービスです。

yamoryを使えば、重大な脆弱性が発生したときでも、「どのプロジェクトで、どのバージョンの該当パッケージが利用されているか」を即座に特定することが可能です。

幅広いレイヤーのITリスクを一元管理

クラウド・オンプレミス環境に問わず、インフラからアプリレイヤー内のITリスク（脆弱性・EOL・OSSライセンスリスク・クラウド設定不備）を一元管理することができます。

分かりやすいダッシュボードで結果を可視化

お使いのシステム環境に合わせて、検出したITリスクの対応優先度を自動で判別し、結果をダッシュボードに可視化。専門家でなくてもリスクの状況をひと目で把握することができます。

間接依存関係にあるライブラリの脆弱性も瞬時に発見

ライブラリの依存関係をツリー構造で可視化。間接依存関係にあるライブラリの脆弱性も瞬時に発見することができます。

政府認定のクラウドセキュリティ評価制度『ISMAP』に登録された唯一の脆弱性管理ツール

yamoryは、政府情報システムのためのセキュリティ評価制度『ISMAP』において、
「唯一、SBOM・脆弱性管理ツールとして登録された国産クラウドサービス」です。

経済産業省が策定した「ソフトウェア管理に向けたSBOMの導入に関する手引」においても、唯一の有償国産ツールとして紹介され、数多くの企業様に導入いただいております。

• 重大サプライチェーン攻撃が発生したとき、すぐに該当パッケージが自社システムで使われているかを確認したい。
• ITリスクを一元管理できるサービスを探している。

というご担当者様。
ぜひこの機会に、ISMAP登録済みのセキュアな基盤で、ITリスク管理をスタートしませんか？

国内唯一のISMAP登録済
脆弱性管理ツール

■参考文献

• Endor Labs「Mastra npm Org Compromised: Multiple Packages Trojanized to Drop a Remote Payload via easy-day-js」 https://www.endorlabs.com/learn/mastra-npm-org-compromised-multiple-packages-trojanized-to-drop-a-remote-payload-via-easy-day-js
• StepSecurity blog「Mastra npm Packages Compromised Using easy-day-js」 https://www.stepsecurity.io/blog/mastra-npm-packages-compromised-using-easy-day-js
• Mastra 公式 GitHub Issue #18044 https://github.com/mastra-ai/mastra/issues/18044
• Mastra 公式 GitHub Issue #18048 https://github.com/mastra-ai/mastra/issues/18048
• Socket blog「140+ Mastra npm Packages Compromised in Coordinated Supply Chain Attack」 https://socket.dev/blog/mastra-npm-packages-compromised
• safedep「Mastra npm Scope Takeover: 141 Packages Drop a RAT」 https://safedep.io/mastra-npm-scope-takeover-supply-chain-attack/
• The Hacker News「GitHub to Disable npm Install Scripts by Default to Stop Supply Chain Attacks」 https://thehackernews.com/2026/06/github-to-disable-npm-install-scripts.html