Red HatのNPMパッケージが侵害されました

2026年6月1日原文(github.com)

概要

Red Hat Cloud Services 関連の npmパッケージ が複数侵害された事例影響を受けた パッケージ名とバージョン の一覧 サプライチェーン攻撃 のリスク顕在化 開発者・運用者 への迅速な対応推奨 npmパッケージ管理 のセキュリティ強化の重要性

Red Hat Cloud Services関連npmパッケージの侵害概要

2024年6月時点で Red Hat Cloud Services 関連の npmパッケージ が複数侵害された事例
攻撃者による 不正なコード挿入 や 情報漏洩 リスクの発生
侵害されたバージョンを利用した場合、 機密情報漏洩やシステム乗っ取り の可能性
npmリポジトリ 経由で配布されたため、広範な影響範囲
開発者・運用担当者 による迅速な対応が求められる状況

影響を受けたパッケージ一覧

下記の パッケージ名 と バージョン が侵害対象
- @redhat-cloud-services/chrome 2.3.1
- @redhat-cloud-services/compliance-client 4.0.3
- @redhat-cloud-services/config-manager-client 5.0.4
- @redhat-cloud-services/entitlements-client 4.0.11
- @redhat-cloud-services/eslint-config-redhat-cloud-services 3.2.1
- @redhat-cloud-services/frontend-components 7.7.2
- @redhat-cloud-services/frontend-components-advisor-components 3.8.2
- @redhat-cloud-services/frontend-components-config 6.11.3
- @redhat-cloud-services/frontend-components-config-utilities 4.11.2
- @redhat-cloud-services/frontend-components-notifications 6.9.2
- @redhat-cloud-services/frontend-components-remediations 4.9.2
- @redhat-cloud-services/frontend-components-testing 1.2.1
- @redhat-cloud-services/frontend-components-translations 4.4.1
- @redhat-cloud-services/frontend-components-utilities 7.4.1
- @redhat-cloud-services/hcc-feo-mcp 0.3.1
- @redhat-cloud-services/hcc-kessel-mcp 0.3.1
- @redhat-cloud-services/hcc-pf-mcp 0.6.1
- @redhat-cloud-services/host-inventory-client 5.0.3
- @redhat-cloud-services/insights-client 4.0.4
- @redhat-cloud-services/integrations-client 6.0.4
- @redhat-cloud-services/javascript-clients-shared 2.0.8
- @redhat-cloud-services/notifications-client 6.1.4
- @redhat-cloud-services/patch-client 4.0.4
- @redhat-cloud-services/quickstarts-client 4.0.11
- @redhat-cloud-services/rbac-client 9.0.3
- @redhat-cloud-services/remediations-client 4.0.4
- @redhat-cloud-services/rule-components 4.7.2
- @redhat-cloud-services/sources-client 3.0.10
- @redhat-cloud-services/topological-inventory-client 3.0.10
- @redhat-cloud-services/tsc-transform-imports 1.2.2
- @redhat-cloud-services/types 3.6.1

推奨される対応策

影響バージョンの 即時アンインストール および 安全なバージョンへのアップデート
npm audit や 依存関係チェックツール による脆弱性検査の実施
CI/CDパイプライン でのセキュリティチェック強化
不審な挙動 や 情報漏洩 の有無をシステム監査で確認
公式アナウンス や セキュリティフィード の定期的な確認

npmパッケージ管理におけるセキュリティ強化の重要性

サプライチェーン攻撃 への警戒強化
パッケージの署名検証 や 信頼できるソースのみ利用 の徹底
アクセス権限管理 や 多要素認証 の導入
セキュリティインシデント発生時の対応手順 の整備
継続的な教育・啓発 による組織的なセキュリティ意識向上

Hackerたちの意見

「これを防ぐ方法はない」と言ってるのは、これが定期的に起こる唯一のパッケージマネージャーだね。編集：一部の人は、これは防御策だってことを理解してないみたい。

└

すべてのプログラミング言語のパッケージマネージャーは脆弱だよ。Arch Linuxのユーザーレポジトリと全く同じ注意点がある。信頼できるメンテイナーが責任を持っているわけじゃないから、誰でもアカウントを作ってパッケージをプッシュできちゃう。

└

今日の大規模な攻撃は、いくつかのパッケージエコシステムに広がってる：TrapDoorやShai-Huludがnpm、pypi、composer、cratesを同じマルウェアで攻撃してる。

└

PyPIとCargoは、100%この同じ種類の妥協に脆弱だよ。NPMがダメだって言うのは、他の全てがダメだってことじゃないからね。

└

このジョーク、よく聞くよね。パッケージマネージャーの話で、インストールの緩さが問題なんだよ、NPMだけじゃない。CargoやPyPi、Nuget、PHPも最近はそうだし。NPMだけの問題じゃないんだよね。ここでよく言われるのは、Nodeに対する偏見があるからだと思う。でも、この問題はNPMだけに限ったことじゃないよ。

└

ちょっと背景を説明するね。「どのパッケージマネージャーも攻撃される可能性がある！」って言ってる人が多いけど、npmは設計上、すべてのパッケージが更新後にログインユーザーとして任意のコードを実行できるんだ。これって、めちゃくちゃ危険なデフォルトだよ。pnpmは、必要なパッケージだけを「オプトイン」できるようにしてる（例えば、うちのプロジェクトでは30個中4つとか）。それに、最小年齢や信頼のダウングレード禁止みたいな他のセキュリティ設定もたくさん追加されてる。攻撃者はパッケージの機能を更新することで攻撃できるけど、npmは特に問題で、呼び出しユーザーとしてサンドボックス外のスクリプトを実行しちゃう。これって、プロジェクトだけじゃなくて、マシンやネットワーク全体を危険にさらすことになる。こういうことは何年も前から知られてたのに、何の対策も取られてないんだよね。

└

正直、今は多くのパッケージマネージャーでこういうことが起きてるよね。pypiやcomposerも含めて。

└

これを削除して書き直してるんだけど、もっと明確にするためにね。HNが最初のコメントをひどくダウンモッドしたけど、俺が正しいって分かってるし、みんなが間違ってると思うから。だから、明確に言うと：- pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer（制限あり） - Maven ...これらは全部スクリプトを許可してる。俺たちはその参照を理解してるけど、正確じゃないよ：ほとんどのパッケージマネージャーはスクリプトを許可してるし、npmは最も成功したパッケージマネージャーなんだ。npmはスクリプトを許可すべきじゃないけど、悪用はどこにでもあるからね。

└

実は、そのタイトルのブログ記事があるよ。 https://kevinpatel.xyz/posts/no-way-to-prevent-this/ https://news.ycombinator.com/item?id=48155690

└

PyPI、5月11日。[1] Crates.io、5月22日。[2] Composer、5月22日。[3] [1] https://www.tenable.com/blog/mini-shai-hulud-frequently-aske... [2] https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra... [3] https://phoenix.security/laravel-lang-composer-supply-chain-...

うちの会社はyarn 4を使ってて、リリースから最初の数日間はnpmパッケージのインストールを防ぐオプションがあるんだ。大体これでその期間内（1〜3日）に捕まってるみたい。

└

みんながこのポリシーを採用したらどうなるの？ 2週間に変更するだけ？

Hacker Newsで議論の続きを見る

ハクソク