【2026年7月14日発生】AsyncAPIサプライチェーン攻撃の概要と対応策を解説
2026年7月14日、AsyncAPIの正規npmパッケージが侵害され、悪性コードを含むバージョンが公開されました。
攻撃者は、設定に問題のあるGitHub Actionsワークフローを悪用して高権限のPersonal Access Token（PAT）を窃取し、正規リポジトリへ悪性コードをプッシュしました。その後、プロジェクト本来のリリース処理を通じてパッケージがnpmへ公開されています。
本記事では、攻撃の流れ、影響を受けたパッケージ、利用組織が確認すべき内容を解説します。
本記事の要点
- 2026年7月14日、
@asyncapi名前空間の4パッケージ、計5バージョンに悪性コードが混入しました。 - 悪性コードはインストール時ではなく、パッケージの
import／require時に実行されます。 - 対象バージョンを利用していた場合は、開発端末とCI/CD環境を調査し、アクセス可能だった認証情報をローテーションしてください。
⚠️本記事は、2026年7月16日時点の情報となります。
7月16日時点で、悪性バージョン5件はnpmレジストリから削除されています。ただし、既存のロックファイル、キャッシュ、社内ミラー、ビルドイメージに残っている可能性があります。
国内唯一のISMAP登録済
脆弱性管理ツール
脆弱性・EOL・OSSライセンスを一元管理
SBOM・法規制に対応
クラウド・オンプレ環境に対応
目次[非表示]
影響を受けたパッケージ
影響が確認されているのは、次の4パッケージ、計5バージョンです。
パッケージ | 悪性バージョン |
@asyncapi/generator | 3.3.1 |
@asyncapi/generator-helpers | 1.1.1 |
@asyncapi/generator-components | 0.7.1 |
@asyncapi/specs | 6.11.2 、 6.11.2-alpha.1 |
複数の海外セキュリティベンダーは、これら4パッケージの合計ダウンロード数を週約290万〜300万回超と推計しています。集計時点によって数値は異なりますが、広く利用されるパッケージであるため、直接依存だけでなく、別のツールやライブラリを介した間接依存にも注意が必要です。
7月14日11:18 UTCまでに、悪性バージョン5件はnpmレジストリから削除され、各パッケージの latest タグはクリーンなバージョンへ戻ったことが確認されています。新規インストールでは通常これらのバージョンは解決されませんが、過去に生成したロックファイルやキャッシュから再取得・再利用されるリスクは残ります。
攻撃の流れ｜何が起きたのか
今回の起点は、GitHub Actionsにおける「Pwn Request」と呼ばれる種類の問題です。
AsyncAPI Generatorリポジトリには、Pull Requestを契機に pull_request_target で起動しながら、Pull Request側のコードをチェックアウトして実行するワークフローがありました。
pull_request_target は、ベースリポジトリの権限やシークレットを利用できるイベントです。この状態で外部から送られたコードを実行すると、攻撃者のコードからリポジトリのシークレットへアクセスされる危険があります。
攻撃の流れは次のとおりです。
- 攻撃者はAsyncAPI Generatorリポジトリへ多数のPull Requestを作成。
- そのうち1件に、空白で見えにくくした難読化JavaScriptを含める。
- 脆弱なGitHub ActionsワークフローがPull Request内のコードを実行。
- ワークフロー環境から、
asyncapi-botに関連するとみられる高権限PATが窃取。 - 攻撃者は盗んだPATを使い、Generatorリポジトリの
nextブランチへ悪性コミットを直接プッシュ。 - 正規のリリースワークフローが動作し、Generator関連の3パッケージがnpmへ公開。
- その後、攻撃者は
spec-json-schemasリポジトリにも変更を加え、@asyncapi/specsの2バージョンを公開。
悪性Pull Request自体はマージされていません。しかし、Pull Requestを処理するワークフロー内でコードが実行されたため、マージ前に認証情報が窃取されました。
また、悪性パッケージは正規のGitHub Actionsを通じて公開されています。そのため、npm上のprovenanceだけを確認しても、今回のような侵害を見分けられない可能性があります。
悪性コードの挙動
悪性コードは、パッケージのインストール時ではなく、アプリケーションやビルド処理が対象パッケージを import または require した際に動作します。
実行されると、外部から次段階のペイロードを取得し、OSに応じた場所へ保存します。
- Linux：
~/.local/share/NodeJS/sync.js - macOS：
~/Library/Application Support/NodeJS/sync.js - Windows：
%LOCALAPPDATA%\NodeJS\sync.js
7月16日時点の海外ベンダーによる解析では、取得されるペイロードは常駐化し、外部C2と通信して任意のシェルコマンドを実行できるRemote Access Trojan（RAT）として動作します。ファイルの一覧取得・取得・送信などの機能も確認されています。
コード内には、GitHub・npmのトークン、SSH秘密鍵、クラウド認証情報、ブラウザー情報、macOS Keychain、暗号資産ウォレットなどを探索する機能も含まれています。一方、解析された設定では自動的な認証情報収集や自己拡散の機能は無効化されていたとの報告があります。ただし、リモートシェルから同等の操作を実行できるため、対象環境の認証情報は漏えいした可能性があるものとして対応する必要があります。
ペイロードにはMiasmaを示す名称や実装上の特徴が含まれますが、攻撃主体の帰属は確定していません。
今すぐ実施すべき対応
1．対象バージョンの利用有無を確認する
まず、リポジトリ、ロックファイル、SBOMを確認し、対象バージョンが含まれていないか調査します。
npm ls \
@asyncapi/generator \
@asyncapi/generator-helpers \
@asyncapi/generator-components \
@asyncapi/specs \
--all直接依存だけでなく、間接依存、グローバルインストール、CI/CD専用の依存関係も確認してください。悪性バージョンはnpmから削除済みですが、ロックファイル、パッケージキャッシュ、社内レジストリ、コンテナイメージにも残存していないか確認します。
直前の安全なバージョンは、@asyncapi/generator@3.3.0 、 @asyncapi/generator-helpers@1.1.0 、 @asyncapi/generator-components@0.7.0 、 @asyncapi/specs@6.11.1 です。安全性を確認したバージョンへ固定し、ロックファイルを再生成してください。
2．読み込み・実行された環境を調査する
対象バージョンが見つかった場合は、インストールの有無だけでなく、実際に import／require されたかを確認します。
主な調査対象は次のとおりです。
- 開発者のワークステーション
- CI/CD Runner
- ビルド用コンテナ
- 対象時間帯に生成された成果物
sync.jsやmiasma-monitor.serviceの存在- 不審な外部通信
悪性コードが実行された可能性がある環境は隔離し、ログやファイルなどの証拠を保全してください。
主なIoC
- C2 IP：
85.137.53.71（ポート8080、8081） - 常駐ファイル：
~/.local/share/NodeJS/sync.js - systemdサービス：
miasma-monitor.service - 関連ドメイン：
ipfs[.]io、rentry[.]co - SHA1（generator）：
22bf76fe317ea6769bd38619bd440e42d119bd6b - SHA1（generator-helpers）：
a7e18d96efd3cdb127ef4cdcad9e3ad26c482bf2 - SHA1（generator-components）：
9890950adcbc2478e7a080234f053214adbad44e - SHA1（specs）：
c70e105e212ff3c1daa04bb2a62507717f296b0b - SHA1（Stage 2）：
c8cb3f6d5b90c46686d2bf531dc1a5786e27edc5
3．認証情報をローテーションする
ペイロードが認証情報を標的とするため、実行が疑われる環境からアクセスできた認証情報は、別の安全な端末から失効・再発行します。
特に次を優先してください。
- GitHub Token・PAT
- npmトークン
- SSH秘密鍵
- クラウド認証情報
- CI/CDシークレット
その後、既知の安全な依存関係を使用し、クリーンな環境で成果物を再構築してください。
影響範囲を迅速に特定することが重要
ここまで紹介した対応を組織全体で確実に進めるには、対象パッケージを利用しているすべてのプロジェクトと環境を把握する必要があります。1つのシステムへの対応が完了しても、別のリポジトリやビルド環境に同じパッケージが残っていれば、影響調査は完了しません。
しかし、管理するリポジトリやシステムが多い場合、すべてのロックファイルを手作業で確認するには時間がかかります。特に、対象パッケージが別のライブラリを介して間接的に導入されていると、利用していること自体に気づけない可能性があります。
そのため、インシデント発生時に影響範囲を迅速に把握できるよう、平時からOSSの利用状況、バージョン、依存関係を一元的に管理しておくことが重要です。
脆弱性管理クラウド「yamory」で影響対象を確認しませんか？
サプライチェーン攻撃の初動で必要なことは、「どのプロジェクトが対象パッケージを利用しているか」を迅速に把握することです。
株式会社アシュアードが提供する脆弱性管理クラウド「yamory」では、プロジェクトで利用するライブラリとバージョンを確認でき、依存関係をツリー構造で可視化できます。直接依存だけでなく、間接依存として取り込まれたライブラリも迅速に確認することが可能です。
- 重大サプライチェーン攻撃が発生したとき、すぐに該当パッケージが自社システムで使われているかを確認したい。
- ITリスクを一元管理できるサービスを探している。
というご担当者様。
ぜひこの機会に、ISMAP登録済みのセキュアな基盤で、ITリスク管理をスタートしませんか？
国内唯一のISMAP登録済
脆弱性管理ツール
脆弱性・EOL・OSSライセンスを一元管理
SBOM・法規制に対応
クラウド・オンプレ環境に対応
■参考文献
