Miasmaサプライチェーン攻撃：@redhat-cloud-servicesのnpmパッケージで悪意あるコードを確認

著者

2026年6月1日

0 分で読めます

2026年6月1日、研究者は、Red Hat Hybrid Cloud Consoleを支えるフロントエンドコンポーネントとAPIクライアント群である、@redhat-cloud-services npm名前空間で公開された少なくとも32件のパッケージリリースに、悪意あるコードが埋め込まれていることを確認しました。侵害されたリリースにはpreinstallスクリプトが含まれており、パッケージのインストールと同時に難読化されたペイロードを実行して、開発者やクラウドの認証情報を収集し、被害者が公開できる他のパッケージへの拡散を試みます。対象パッケージの週間ダウンロード数は合計で平均約8万件に上り、影響はRed Hatのパイプラインにとどまりません。

このキャンペーンはMiasmaと名付けられました。ペイロードは、TeamPCPが今年初めにオープンソース化した(Mini) Shai-Huludワームをわずかに改変した派生版です。@redhat-cloud-servicesのパッケージをインストールしたことがある場合、またはそれに依存するプロジェクトをビルドした場合は、現在進行中のインシデントとして対処し、影響を受けたマシンで扱われたシークレットはすべて漏えいしたものと考えてください。

要点

概要：公開済みnpmリリースに埋め込まれた悪意あるコード（自己拡散型ワーム＋認証情報窃取）。
名前空間：@redhat-cloud-services（Red Hat Hybrid Cloud ConsoleのフロントエンドコンポーネントとAPIクライアント）。
規模：名前空間内の少なくとも32件のパッケージリリース、週間ダウンロード数は合計約8万件。2回に分けて公開。
CVE：未割り当て。Snykのアドバイザリで追跡中。Snykは主要アドバイザリを9.3 （Critical、CVSS v4.0）と評価し、エクスプロイトの成熟度をAttackedとしています。
根本原因：侵害されたRed Hat従業員のGitHubアカウントから、npm公開用OIDCトークンを要求する悪意ある孤立コミットがプッシュされ、有効なSLSA来歴情報を伴うパッケージが公開されました。
状況：開示から数時間以内に、悪意あるバージョンの大半がnpmから取り消されましたが、分析の継続中に少数が公開状態のまま残っていました。調査は継続中です。
対処：影響を受けたバージョンを避けるよう固定し、スクリプトを無効にして再インストールしてください。また、影響を受けたワークステーションやCIランナーからアクセス可能だった認証情報をすべてローテーションしてください。

何が起きたのか

@redhat-cloud-services名前空間のパッケージは、Hybrid Cloud Consoleのビルド時依存関係です。共有Reactコンポーネント（@redhat-cloud-services/frontend-components、frontend-components-utilities、frontend-components-notifications）、生成されたAPIクライアント（rbac-client、host-inventory-client、compliance-clientなど約24件）、および関連ツールが含まれます。中には単独でも相当数のダウンロードがあるパッケージもあります。報告された規模を簡単に確かめると、npmダウンロードAPIによれば、@redhat-cloud-services/typesなどの最大規模のパッケージは、週あたり数万件に達しています。

1# https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes
2curl -s "https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes"
3# {"downloads":15060, ... }

対象パッケージについて、直近の完全な1週間（2026年5月25日から31日）のダウンロード数を合計すると約79,000件となり、今回のインシデントで示された約80,000件という数字と一致します。不正な改変は、2026年6月1日に初めて確認されました。

悪意あるリリースは6月1日に2回に分けて公開されました。アドバイザリが発行された時点で、npmは問題のあるバージョンの大半を取り消していましたが、分析中にいくつかが公開状態のまま残っていました。

技術的な詳細

インストール時に実行されるトリガー

侵害されたリリースにはそれぞれ、インストール時に実行されるフックが追加されています。npmはpreinstallスクリプトをnpm install時に自動実行し、自分のコードが実行される前に処理するため、依存関係を解決するだけでペイロードが起動します。

1{
2  "scripts": {
3    "preinstall": "node index.js"
4  }
5}

このスクリプトが呼び出すindex.jsは、異例なほど大きく、強く難読化されたJavaScriptファイルです。作成者はeval()とROT方式の文字列デコードを使ってロジックを隠していました。これは過去のShai-Hulud亜種でも見られた手法です。デコードすると、ペイロードは複数段階からなる認証情報収集ツール兼ワームです。

ペイロードの動作

機能の中核部分は(Mini) Shai-Huludのフレームワークと一致しますが、ギリシャ神話への言及が、元のDuneをテーマにした装飾要素（spartanの使用など）に置き換えられています。攻撃者が新たに作成したリポジトリにはMiasma: The Spreading Blightという説明が付いており、調査時の有用な手がかりになります。

実行されると、ペイロードは次の処理を行います。

ローカル環境やCI環境からシークレットと認証情報を収集します。環境変数、~/.npmrcのトークン、SSHキー、GitHubトークン、CI/CDシークレットが対象です。
クラウドIDを列挙します。この亜種で注目すべき変更点は、感染ホストが引き受けられるすべてのIDを列挙する、GCPとAzure向けの新しい収集機能が追加されたことです。固定されたシークレットだけが対象ではありません。以前の亜種は認証情報の窃取に重点を置いていましたが、今回はクラウドのコントロールプレーン自体の把握とアクセスを狙っています。
自己拡散します。侵害されたIDで公開できる他のパッケージをレジストリに問い合わせ、同じペイロードを含めて再公開します。これにより、メンテナー1人の侵害がワームへと発展します。

根本原因：侵害されたアカウントと有効な来歴情報

ここは、立ち止まって詳しく見るべき点です。悪意あるコードは、タイポスクワッティングや汚染された推移的依存関係を通じて入り込んだわけではありません。証拠によると、Red Hat従業員のGitHubアカウントが侵害され、それを使って2つのRedHatInsightsリポジトリに悪意ある孤立コミットが直接プッシュされ、コードレビューを回避していました。

これらのコミットにより、次の処理を行う最小限のGitHub Actionsワークフローが追加されました。

すべてのブランチへのプッシュをトリガーに実行。
id-token: writeを使ってGitHub OIDC IDトークンを要求。
難読化されたペイロード（_index.js）を実行し、パッケージをnpmに公開。

正規のリポジトリのActionsコンテキスト内で公開処理が実行されたため、リリースには有効なSLSA来歴証明が付与されていました。来歴情報は技術的には正確でした。つまり、パッケージが実際にそのリポジトリのワークフローでビルドされたことを示していました。しかし、そのワークフロー自体が不正なものだったことまでは示せません。この点は、数週間前にTeamPCPがTanStackに対して悪用したケースと同じで、偽造されていながら有効な来歴情報により、悪意あるパッケージが単純な検証をすり抜けました。また、Trivy GitHub Actionの侵害で見られたランナー側でのトークン窃取にも通じます。来歴情報の検証は必要ですが、それだけでは不十分です。

影響分析

直接のダウンロード数では、実際の影響を過小評価しています。これらはエンタープライズコンソールのビルド時依存関係であるため、インストールの大半は開発者のワークステーションやCIランナーで行われます。まさに、長期間有効なクラウド認証情報、レジストリトークン、GitHub PATが豊富に存在する環境です。ワームの動作により影響はさらに拡大します。影響を受けたバージョンをインストールした開発者が、他のパッケージを公開する権限を持っていれば、次の拡散を引き起こす可能性があります。

2026年6月1日の最初の悪意ある公開以降、次のいずれかが実行されていた場合、影響を受けている可能性があります。

ワークステーションまたはCIランナーで、影響を受けた@redhat-cloud-servicesのバージョンを解決するnpm install / npm ciを実行した。
新たに追加されたクラウドID収集機能を踏まえると、ランナーがGCP、AWS、AzureのIDを持つクラウド環境でビルドを実行した。

攻撃の実行に、利用者側での特別な設定は必要ありません。preinstallフックはデフォルトで実行されます。前提条件は、影響を受けたバージョンをインストールしていることだけです。

検出方法

1. ロックファイルから影響を受けたバージョンを探す。package-lock.json / pnpm-lock.yaml / yarn.lockで、次の名前空間を検索してください。

1grep -r "@redhat-cloud-services" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

解決されたバージョンを、「参考資料」セクションに記載されているSnykのアドバイザリと照合してください。Snykの主要アドバイザリでは@redhat-cloud-services/frontend-componentsの<=7.7.2が対象です。パッケージごとに対象バージョンの境界は異なるため、各アドバイザリを確認してください。

2. Snykでスキャンする。Snykのデータベースには、悪意あるリリースに関するアドバイザリがすでに登録されているため、通常のテストで検出できます。

1snyk test --file=package-lock.json

組織では、資産の検出とリスクベースの優先順位付けにより、影響を受けたバージョンを取り込んだすべてのプロジェクトとランナーを見つけられます。また、すべてのインストールを片っ端から追うのではなく、各環境で実際にどれほどの認証情報が露出したかに応じて、修復の優先順位を付けられます。

3. 侵害の痕跡を調査する。パッケージを削除しても、ペイロードがすでに実行された可能性があります。次の点を確認してください。

GitHub組織内に作成された、見覚えのない新しいリポジトリ。特にMiasma: The Spreading Blightという説明が付いたもの。
認識していないGitHub Actionsワークフロー。特にid-token: writeを要求し、すべてのブランチへのプッシュをトリガーとする最小限のワークフロー。
自分で作成していない新しい個人アクセストークン、デプロイキー、npmトークン。
ビルドランナーからGCPおよびAzureのIDメタデータへの異常な読み取り。

修復

ここでは手順の順番が重要です。このマルウェアファミリーは永続化の仕組みを仕込み、一部の亜種では破壊的なトリガーを設置することが知られています。監視対象のトークンを失効させる前に、まずホストをクリーンアップしてください。

1. 問題のあるバージョンのインストールを止める。依存関係を既知の安全なリリースに固定または上書きするか、影響を受けたパッケージを一時的に削除してください。その後、ロックファイルで対象バージョンが解決されなくなったことを確認します。

2. スクリプトを無効にして再インストールする。影響を受けた可能性のある依存関係ツリーを再構築する際は、インストールスクリプトをブロックして、残存する悪意あるバージョンが再び実行されないようにしてください。

1rm -rf node_modules
2npm install --ignore-scripts

環境全体のデフォルト設定として適用できます。

1npm config set ignore-scripts true

（ビルド手順が実際に必要なパッケージのみ、個別に再度有効にしてください。）

3. 永続化の仕組みを取り除く。認証情報に触れる前に、攻撃者が仕込んだフックを監査して削除してください。.claude/settings.jsonや.vscode/tasks.json.など、エディターやエージェントの設定も対象です。

4. アクセス可能だったすべての認証情報をローテーションする。影響を受けたマシンから見えるすべてのシークレットが漏えいしたものとみなし、優先順位を付けてローテーションしてください。npmトークン、GitHub PATとSSHキー、次にクラウド認証情報の順です。新しい収集機能を踏まえ、固定キーだけでなく、CIランナーが引き受けられるロールを含め、GCP、AWS、AzureなどのクラウドIDにも特に注意してください。

5. GitHubをクリーンアップする。不正なリポジトリやワークフローを削除し、前述のOIDCを使った公開パターンがないか最近のActions実行履歴を確認してください。また、自分のアカウントで予期しないパッケージが公開されていないことを確かめます。

6. パイプラインを強化する。今後は、保護されたブランチでレビューを必須にして孤立コミットからの公開を防ぎ、OIDCの信頼範囲をリポジトリ全体ではなく特定のブランチとワークフローに限定し、npmで公開時の保護を伴う2FAを必須にしてください。また、来歴証明だけを信頼せず、動作チェックと組み合わせてください。依存関係の許可リスト、SBOMの生成、新しいリリースを採用する前の公開後クールダウン期間も、この種の攻撃が悪用する時間を短縮できます。詳しくは、Snykのnpmセキュリティのベストプラクティス10選とCI/CDパイプラインを保護する8つのヒントをご覧ください。

時系列

2026年6月1日：@redhat-cloud-services名前空間で、悪意あるリリースの第1波が公開されました。
2026年6月1日（UTC午後1時頃）：侵害が公表され、悪意あるバージョンの大半が取り消される。2件は公開状態のまま。
2026年6月1日（UTC午後2時頃）：従業員アカウントの侵害と、有効なSLSA来歴情報を伴うOIDC経由のパッケージ公開という根本原因が公表される。
2026年6月1日（UTC午後2時20分～3時頃）：悪意あるコミットの第2波が確認され、対象に追加。新たなGCP/Azure ID収集機能の詳細も明らかになる。
2026年6月2日：既存パッケージで新たに発見された侵害バージョンを追加。
継続中：影響を受けたパッケージに関するSnykのアドバイザリが公開中。調査は継続しています。

Snyk Vulnerability DBをチェック

信頼できるデータと実用的なインサイトで、安全なソフトウェア開発を支援します。

パッケージを確認する