AsyncAPIのnpmエコシステムは2026年7月14日、信頼されたGitHub Actions駆動のリリースワークフローを通じてMiasma関連のNode.jsバックドアを配布する、連携型のサプライチェーン侵害の被害に遭いました。この攻撃により、価値の高い開発者環境やCI/CD環境がリモートアクセス、認証情報の窃取、さらなる横展開の危険にさらされることになりました。
悪意のあるバージョンが配布されたのは、@asyncapi/[email protected]、@asyncapi/[email protected]、@asyncapi/[email protected]、そして@asyncapi/specsの6.11.2および6.11.2-alpha.1で、これらを合わせると週間ダウンロード数はおよそ290万件に上ります。
このJavaScriptバックドアはランタイムモジュールに注入されており、インストール時ではなく、該当パッケージがインポートされた際に実行される仕組みになっています。これにより、依存関係の解決からかなり時間が経過した後でも、ビルドやドキュメント生成の実行、CI/CDジョブの中で「サイレント」に起動できてしまいます。
研究者らによると、攻撃者はAsyncAPI自身のOIDCベースの信頼済みパブリッシャー・ワークフローを悪用しており、生成された成果物には正当なSLSAプロベナンス証明が付与されていました。そのため下流の利用者から見ると、これらのパッケージは通常のリリースと見分けがつかない状態になっていました。
この点から、今回の事案はプロベナンスを維持したまま侵害が成立する典型例だと言えます。パイプライン自体は本物であるにもかかわらず、コミットやワークフローのコンテキストはすでに乗っ取られていたのです。
AsyncAPIの侵害では、Miasma関連のNode.jsローダーが展開され、これがデタッチドプロセスを起動し、暗号化された第2段階のペイロードをIPFSから取得していました。これは、npmエコシステムで確認された過去のMiasmaの攻撃波と一致する挙動です。
JFrogによるMiasmaの分析では、永続化、リモートコマンド実行、ファイル操作、ペイロードの更新、柔軟なコマンド&コントロール通信といったRAT型の機能が挙げられています。
今回のキャンペーンでは、攻撃者はEthereumスマートコントラクトを参照しており、これが更新可能な設定ストアとして機能し、代替のエンドポイントやNostrリレー、BitTorrent DHTブートストラップノードを露出させていました。これらはパッケージを再公開することなくローテーションできる仕組みです。
このコードベースには、キャンペーンを他のパッケージにも拡散させることを狙った機能など、ワーム的な特性が残されています。ただし、AsyncAPIにおける設定は、あらゆる環境で完全に自律したワームというよりも、主にリモートアクセスツールとして振る舞っていました。
この違いはインシデント対応者にとって重要です。侵害の兆候を見極める上では、ダウンロード数だけでなく、実行状況やコマンド&コントロールの通信活動の方が信頼できる指標となります。
Cato NetworksがGBhackersと共有した報告書によると、攻撃者はAsyncAPIのGitHub Actionsワークフローの脆弱性を悪用してプッシュアクセス権限を取得し、正規の@asyncapi名前空間の下でトロイの木馬化したリリースを公開していたとのことです。
Hacking& Cracking
今回のAsyncAPIの事案は、TeamPCP、Mini Shai-Hulud、Miasmaが信頼された開発ツールやパッケージエコシステムを標的にしてきた、2026年を通じたより大きなサプライチェーン攻撃の流れの延長線上にあります。
AsyncAPIのサプライチェーン攻撃
これに先立つ2026年3月には、TeamPCPがTrivy、KICS GitHub Action、LiteLLM、その他のCI/CD中心のツールへの侵害と関連付けられており、クラウドやビルドパイプライン内ですでに信頼されているコンポーネントを狙っていました。
4月から5月にかけては、Mini Shai-Huludがnpm、PyPI、Packagist、その他のエコシステムへと拡大しました。Cloud Security Allianceは、開発者の認証情報や公開権限、CI/CDのID情報を組織的に収集する動きだったと説明しています。
その後の攻撃波では、@redhatスコープのnpmパッケージにMiasmaが持ち込まれ、さらに後にはPhantom Gyp手法が採用されました。これは悪意のあるbinding.gypファイルを使い、package.json内に目立ったライフサイクルフックを持たせないままインストール時に実行を獲得する手法で、数十件のパッケージと数百のバージョンに影響を及ぼしました。
攻撃の帰属については依然として不透明な部分が残ります。コードやTTP(戦術・技術・手順)、インフラの重複からは何らかの作戦上の連続性がうかがえますが、Mini Shai-Huludのコードが公開されていることから、複数の攻撃者がそのツールを再利用したり派生させたりできる状況にあります。
Cato CTRLのサプライチェーン・インテリジェンスエージェントは、セキュリティ研究やエコシステムの情報開示を常時監視し、影響を受けるパッケージ、悪意のあるバージョン、インフラの痕跡情報を関連付けています。
AsyncAPIに関する報告を受けて、同エージェントはこの事案をアナリストによるレビューの優先対象とし、Miasmaのコマンド&コントロールIPアドレスの迅速な検証、Catoのグローバルブロックリストへの追加、そしてCato SASE Cloud Platform全体でのネットワークレベルでの適用を数時間以内に実現しました。
このワークフローは、ペイロードがIPFSやEthereumコントラクト、BitTorrentオーバーレイといった耐障害性の高いインフラを利用している場合でも、エージェント型のインテリジェンスとグローバルに分散した対策を組み合わせることで、情報開示から防御までの時間を大幅に短縮できることを示しています。
影響を受けたAsyncAPIのバージョンを取得または実行した可能性のある組織は、開発者のワークステーション、CI/CDランナー、ドキュメント生成システム、ビルド環境が侵害にさらされている可能性があるものとして扱う必要があります。
最低限の対応として、マニフェストやロックファイル内で脆弱なバージョンを特定し、侵害されたモジュールが実際にインポートされたかどうかを確認し、デタッチドNode.jsプロセスやsync.js形式のローダーを探索し、送信先の通信を分析し、該当環境で利用可能な認証情報をローテーションすべきです。
今回のキャンペーンがIPFS、BitTorrent、pastebin的なサービスを利用していたことを踏まえると、防御側はipfs[.]io、BitTorrentの通信シグネチャ、rentry[.]coのようなサイトについても、業務上の正当な必要がない限りポリシーによる制限を検討すべきでしょう。
𝗔𝗜 𝗦𝗢𝗖 𝘃𝘀 𝗠𝗗𝗥 𝘃𝘀 𝗠𝗦𝗦𝗣 2026年に最適なのはどれか? コスト、自動化、対応力を比較: 無料ガイドをダウンロード
翻訳元: https://gbhackers.com/asyncapi-supply-chain-attack/
