2026年7月14日、イベント駆動アーキテクチャの仕様記述に使われるOSS標準「AsyncAPI」がnpm（JavaScriptの標準パッケージレジストリ）で配布する4パッケージ5バージョンに、悪性コードが混入していたことが判明した[1][2]。影響を受けたパッケージの合計週間ダウンロード数は300万件を超える[2]。侵入経路はGitHub Actions（GitHubのCI/CD機能）のワークフロートリガーpull_request_target（フォークからのPRでも、ベースリポジトリ側の権限とシークレットで実行されてしまうトリガー）の設定不備だった。攻撃者はこの穴から特権PAT（Personal Access Token、長期有効な認証トークン）を窃取し、npmアカウント自体を破らずに正規のリリースパイプラインを乗っ取って悪性パッケージを公開した。CI/CDの認可設計は経営層の目に触れにくいが、ワークフロー1本の設定ミスが週間300万件規模の配布網を乗っ取る事故に直結する。本稿は侵害の連鎖を分解し、自組織のGitHub Actionsで点検すべき認可境界を整理する。
予備知識
- pull_request_target: フォークからのPRでも、ベースの権限とシークレットで実行されるトリガー
- PAT（Personal Access Token）: ユーザーやbotアカウントに発行される長期有効な認証トークン
- import-time実行: インストール時ではなくrequire/importされた瞬間に悪性コードが起動する方式
pull_request_targetを含むトリガー設計や権限管理の実践知識が、本件の侵入経路を事前点検する土台になる
何が起きたか——4パッケージ5バージョンが週300万ダウンロード規模で汚染された
AsyncAPI侵害の被害規模を、公表された数字で確認する。攻撃者は本命のPRを紛れ込ませるため、まず36件のスパムPRを送りつけて監視の目を分散させた[2]。その中の1件（PR #2155）がドキュメント修正を装いつつ、脆弱なワークフローを起動させる仕掛けだった。悪性コミット作成が2026年7月14日05:08 UTC、generator 3.3.1・generator-components 0.7.1・generator-helpers 1.1.1の3パッケージが07:10 UTCに公開され、specsのalpha版が08:06 UTC、安定版6.11.2が08:30 UTCに同一ペイロードで公開された[1]。最初のダウンストリーム取得（Yarnキャッシュへの流入）は08:49 UTCに観測され、悪性コミットから2時間弱で利用者の環境に流れ始めた[1]。specsは他の多くのAsyncAPIツールの推移的依存であり、直接利用者を超えて影響が及ぶ。
CI/CDを起点とした供給網侵害の全体像と防御の枠組みを体系的に補強できる
pull_request_targetはなぜ危険なのか——ベースリポジトリの権限をフォークPRに渡す仕組み
pull_request_targetの危険性は、通常のpull_requestトリガーとの権限差にある。pull_requestは隔離環境で動きシークレットを持たないが、pull_request_targetはベース側のGITHUB_TOKENとシークレットを保持したまま実行される。ワークフロー側で明示的にPRのコミットをチェックアウトすると、攻撃者のコードがその特権コンテキストで走る[1][2]。業界では「Pwn Request」と呼ばれる既知の誤用パターンである。AsyncAPIではmanual-netlify-preview.ymlというドキュメントプレビュー用ワークフローがこの条件に該当し、加えてactions/checkoutの既定動作でチェックアウト時の認証情報がジョブ終了後まで残留する点も悪用された[1]。
| トリガー | シークレット | フォークコード実行権限 |
|---|---|---|
| pull_request | なし | 制限あり |
| pull_request_target（未チェックアウト） | あり | 影響小 |
| pull_request_target（チェックアウト） | あり | 事実上フル権限 |
2026年6月16日、インドの通信キャリアRcom（AS18101、旧Reliance Communications）が、BGP（Border Gateway Protocol、経路情報をAS間で交換するインターネットの基幹プロトコ[…]
窃取したPATが招いた二次被害——正規パイプラインの悪用とimport-time実行の壁
窃取されたのはasyncapi-botという高権限PATだった[1][2]。攻撃者はこのPATで自動公開用ブランチへ直接pushし、コードレビューを経ずにAsyncAPI自身のリリースパイプラインに悪性コミットを取り込ませた。npm側のトークンを盗む必要がなく、公開物が正規パイプライン経由のため外形的に通常のリリースと区別しにくい。ペイロードはインストール時ではなくrequire/import時に起動する「import-time実行」を採用し、npm install --ignore-scriptsでは防げない[1]。検出マルウェアはTrojan:JS/MiasmStealer.SC等に分類され、AWS・GCP・K8s設定・npm/GitHubトークンを収集し、.vscode/tasks.json等への書き込みで持続化を試みる。第二段はIPFS経由で配布され、C2にはNostrリレーやlibp2pメッシュも使われた[1]。
2026年6月22日、CDN大手Cloudflareのネットワークが劣化し、X、Reddit、Microsoft Teams、Zoomなど数多くのサービスで遅延やタイムアウトが発生した[1][2]。原因は設定変更のミスではなく、北米[…]
CI/CDの認可境界をどう設計し直すか——pull_request_target棚卸しの実務手順
事後対応ではなく、恒常的な点検体制として設計し直す視点が要る。第一に、全リポジトリでpull_request_target:を使うワークフローを棚卸しし、同一ジョブでPRコミットのチェックアウトとシークレットアクセスが同居していないか確認する。第二に、フォークのビルド工程とシークレットを使う公開・デプロイ工程を別ワークフローに分離し、後者はビルド済み成果物のみを受け取る設計に改める。第三に、外部コントリビューターのPRでシークレットを要するジョブはEnvironment保護ルールで人手承認を挟む。第四に、長期有効PATを、有効期限が短く権限範囲を絞ったFine-grained PATやGitHub Appのトークンへ置き換える。
| 項目 | 誤った構成 | 推奨構成 |
|---|---|---|
| トリガー | PRコミットを直接チェックアウト | ビルドとデプロイを分離 |
| シークレット共有 | フォークPRから直接参照可能 | Environment保護＋人手承認 |
| 認証トークン | 長期有効な高権限PAT | 短命・最小権限のFine-grained/App |
| checkout設定 | 既定（認証情報が残留） | persist-credentials: false |
MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]
よくある質問（FAQ）
Q1. pull_request_targetを使うワークフローは全て危険か。
そうではない。危険なのは、シークレットにアクセスできる状態のままPRのコミットを明示的にチェックアウトして実行する構成に限られる。
Q2. npm install –ignore-scriptsで今回のマルウェアは防げたか。
防げない。ペイロードはインストールスクリプトではなくimport/require時に起動するため、スクリプト無効化は対策にならない。
Q3. 別記事のMiasma事件（OIDC信頼公開の悪用）と同一の攻撃か。
被害者もマルウェア系統も別である。関連する系統は確認されているが、侵入経路はOIDCの信頼された公開ではなくpull_request_targetの設定不備によるPAT窃取であり、区別して扱う必要がある。
まとめ
AsyncAPI侵害の教訓は、npmトークンの管理を固めても、その手前にあるCI/CDワークフローの認可設計が破られれば防御全体が無意味になるという点にある。攻撃者は正規のリリースパイプラインをそのまま使い、外形的に見分けのつかない形で悪性パッケージを配布した。まず自組織のGitHub Actionsでpull_request_target:を使うワークフローを洗い出し、同一ジョブでPRコミットのチェックアウトとシークレットアクセスが同居していないか確認してほしい。その1本の設定が、週間数百万ダウンロード規模の事故につながる入口になり得る。
出典
[1] Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/2026/07/15/unpacking-asyncapi-npm-supply-chain-compromise-import-time-payload-delivery/[2] Datadog Security Labs — https://securitylabs.datadoghq.com/articles/compromised-asyncapi-npm-packages/
