Lava、数千台の露出したGPUサーバーと高深刻度のNVIDIAモニタリング欠陥を発見

AIモデルの背後にあるインフラは、誰も侵入する前に驚くほど多くの情報を明らかにすることがあります。公開されたモニタリングエンドポイントは、サーバー内のGPU、その利用率、そしてそれらを取り巻くソフトウェアを開示する可能性があります。同じモニタリングサービスの欠陥は、可視性を可用性リスクへと変えることがあります。

Lavaが10月8日に発表した新たな調査は、両方の問題を記述しています。同社は、認証なしで12,000台以上のユニークGPUを報告している、約2,100台の公開されたNVIDIA DCGM Exporterホストを特定しました。調査中に、Lavaは未認証の攻撃者がリソースを枯渇させ、GPUモニタリングをクラッシュさせる可能性のある高深刻度の脆弱性も発見しました。

NVIDIAはこの問題にCVE-2026-47483を割り当て、8.2, 高と評価し、アップデートをリリースしました。今回の調査は、AIインフラのあまり注目されない部分、すなわち高価な計算資源を監視するサービス自体が保護を必要とすることに光を当てています。

研究者が見つけたこと―そして数値が示す意味

LavaのMichael Katchinskiyによるオリジナルリサーチは、2026年3月から5月に実施された4つのスキャンを記述しています。その合計は、現在も露出しているシステムのリアルタイム数ではなく、調査期間中の観測結果を表しています。

ホストは認証なしでGPUテレメトリを返しました。Lavaは、H100、H200、Blackwell Ultra B300に加え、RTX 4090および5090システムなどのデータセンター向けアクセラレータを観測しました。同社は、観測されたGPUのハードウェア価値が市場概算に基づき1億ドル以上であると推定しました。この数値はハードウェアの価値を示すものであり、攻撃による損失を意味するものではありません。

露出したDCGMホストの約4分の1は、内部のGoプロファイリングエンドポイントも公開していました。このサブセットは重要です。公開されたメトリクスエンドポイントと到達可能な脆弱なプロファイリングインターフェースは関連していますが、別個の発見です。12,000台以上のGPUすべてをこの脆弱性の確認された被害者と表現するのは誤解を招きます。

Lavaは、公開されたデプロイメントを攻撃したのではなく、制御された環境でリソース枯渇を再現したと述べています。この研究は潜在的な攻撃経路を示していますが、観測された組織が実際に悪用されたり、モデルデータが盗まれたことを証明するものではありません。

GPUモニタリングがステータスライト以上の情報を明らかにする理由

DCGMはData Center GPU Managerの略です。NVIDIAのDCGM Exporter ドキュメントでは、エクスポーターが選択されたGPUテレメトリフィールドを収集し、Prometheusが利用できる形式で提供すると説明しています。そのメトリクスエンドポイントは、通常、モニタリングシステムがGPUノードの状態とアクティビティを追跡するために使用されます。

温度、利用率、メモリ使用量、消費電力、エラーイベントは、計算の動作状況を示すため、オペレーターにとって有用です。同じ情報が第三者にアクセス可能になると、インベントリや偵察の情報源となります。

露出した応答はハードウェアモデルや運用の詳細を明らかにすることがあります。繰り返しの読み取りは、繁忙期や繰り返しのアクティビティに関する手がかりを提供します。これらの手がかりは特定のモデルが訓練中またはサービス中であることを証明するものではありませんが、外部者が環境に何が含まれ、いつ稼働しているかを絞り込むのに役立ちます。

この区別は保持すべき重要な点です。GPUテレメトリを読むことは、モデルの重みや訓練データ、プロンプトを読むこととは異なります。それでもインフラ情報は価値があります。どのコンポーネントやバージョンが存在するかを攻撃者が把握すれば、ブラックボックスサーバーに直面している者よりも具体的な出発点を得られます。

脆弱性はモニタリングサービスを標的とする

NVIDIAのセキュリティブリテンは、DCGM Exporterの /debug/pprof エンドポイントを特定します。 同時に未認証のプロファイリングリクエストは、制御不能なリソース消費を引き起こし、サービス拒否や情報漏洩の可能性があります。このアドバイザリは、LavaのMichael Katchinskiyの報告に感謝しています。

プロファイリングは正当な診断機能です。開発者がアプリケーション内部のCPUやメモリの挙動を調査するのに役立ちます。セキュリティ上の問題は、潜在的にコストのかかる内部関数が、適切な制御なしに信頼できない呼び出し元から利用可能になると発生します。

Lavaによると、研究者は当初、オペレータの設定ミスを疑い、その後NVIDIAの公式コンテナで同様の挙動を再現しました。彼らはリソース枯渇がエクスポーターをクラッシュさせ、GPUの健康状態の可視性を失わせることを実証しました。CPUおよびメモリの圧迫は、サーバーを共有する訓練や推論ワークロードにも影響を及ぼす可能性があります。

エクスポーターがクラッシュしても、GPUワークロード自体が必ずしも停止するわけではありません。即時の影響はモニタリングの喪失であり、隣接するワークロードへの干渉はリソース分離とデプロイ状況に依存します。これはGPUインフラストラクチャに関するソフトウェアサービスの脆弱性であり、GPUシリコン自体の欠陥を示す証拠ではありません。

この違いは運用上重要です。ワークロードが減速する際にモニタリングが消失すると、対応者は観測システム自体が故障しているかどうかを調査する必要があります。すべての欠損メトリックを単なる計測上の不便とみなすと、リソース消費インシデントの認識が遅れる可能性があります。

露出はGPU層を超えて広がります

Lava の発表では、12,096 台の公開アクセス可能な Node Exporter ホストが記載されています。Node Exporter はサーバーおよびオペレーティングシステム情報を報告するもので、DCGM Exporter と同様の役割を果たすわけではありません。公開されたデータにはハードウェアとソフトウェアの詳細が含まれており、外部の者が GPU ワークロードを取り巻くシステムを理解するのに役立ちます。

これらの数は別々に扱う必要があります。Node Exporter の観測は、CVE-2026-47483 に対して脆弱と確認されたホスト数の別のカウントではなく、より広範なインフラ露出の発見です。数値を統合すると、どのサービスがどのリスクを表すかが不明瞭になります。

より広い意味合いとして、AI のセキュリティにはモニタリングおよび管理層も含める必要があります。モデルへのアクセス制御は、モデル横に配置されたメトリクスサービスを自動的に保護するわけではありません。組織は推論 API を保護しつつ、同じインフラ上の別サービスをインターネットに公開したままにすることが可能です。

パッチ適用とアクセス制限は異なる課題に対処します

セキュリティアップデートはすでに提供されています。NVIDIA のブリテンは DCGM Exporter 4.8.2 を更新版として特定し、さらに DCGM 4.5.3 も一覧に挙げています。運用者は現在のアドバイザリと、導入環境に対してサポートされているリリースの組み合わせを確認すべきであり、これら二つのコンポーネントバージョン番号を互換的に扱うべきではありません。

アップグレードは開示された欠陥への対処です。ただし、アップデートだけでメトリクスエンドポイントが適切に制限されているとは限りません。パッチ適用されたエクスポーターが、アクセス制御なしで公開されたままであれば、依然としてテレメトリを漏洩させる可能性があります。

Prometheus security modelは、適切な対策なしにコンポーネントのHTTPエンドポイントをパブリックネットワークに公開することに対して明確に警告しています。そのガイダンスはメトリクス、API、Goプロファイリングインターフェースを対象とし、これらのサービスが過負荷になる可能性があることも認識しています。

AI インフラを見直すチームにとって、実践的な手順は次の通りです。

• 導入されているモニタリングサービスをインベントリ化する。 どのエクスポーター、Prometheus サーバー、診断インターフェースが稼働しているか、所有者は誰か、どのようにアクセス可能かを把握します。
• ベンダーのセキュリティアップデートを適用する。 まだ展開されていない設定ファイルだけでなく、実際にデプロイされているソフトウェアまたはコンテナのバージョンを確認します。
• モニタリングへのアクセスを制限する。 プライベートネットワークと適切なファイアウォール、セキュリティグループ、アクセス制御を使用し、テレメトリが必要なモニタリングインフラにのみ提供されるようにします。
• プロファイリング要件を見直す。 Lava は、プロファイリングが明示的に必要な場合以外は無効にすることを推奨しています。現在のバージョンではオプトイン方式です。 --enable-pprof 無効にすることを推奨します。現在のバージョンではオプトイン方式です。
• 修正後の可視性を検証する。 権限付与された収集が依然として機能し、予期しないエクスポーターの障害が検知されていることを確認します。

これらの手順は、ソフトウェアに欠陥があるかどうか、信頼できない第三者がアクセスできるかどうか、モニタリング障害が検知されるかどうかという別々の質問に対応します。一つを解決しても他の問題は解決しません。

AI インフラには明確なセキュリティオーナーが必要です

GPU の容量は、プロバイダーが運用するインフラと顧客が導入するサービスの両方にまたがることが多いです。有用なセキュリティレビューは、各コンポーネントを誰が保守し、ネットワーク露出を誰が管理し、公開エンドポイントが報告された際に誰が対応するかを特定します。これらの割り当てがないと、モニタリングサービスが両チームの間に位置し、互いに相手が保護することを期待してしまいます。

Lava の研究から得られる中心的な教訓は実務的です。AI 計算を保護するには、計算を測定・管理するシステムも保護しなければなりません。新たな調査結果は過去の大規模露出を文書化し、NVIDIA のアドバイザリは開示された脆弱性への対策手順を示しています。運用者にとっての優先事項は、現在のデプロイを確認し、修正を適用し、内部の観測サービスを意図した信頼境界内に保つことです。