出典: Jack_the_sparow via Shutterstock
攻撃者は、NGINXウェブサーバーを管理するために広く使用されているnginx-uiインターフェースの重大な欠陥を積極的に悪用しています。
この欠陥は、CVE-2026-33032として追跡されており、(CVSS: 9.8)nginx-uiのModel Context Protocol (MCP)の不安全な実装に由来し、攻撃者がほとんど認証なしでNGINXサーバー設定に許可されていない変更を加える方法を提供します。
認証の失敗
オープンソースプロジェクトのメンテナーは、Pluto Securityの研究者が脆弱性を報告した後、3月初旬にnginx-ui (v2.3.4)の修正版をリリースしました。
多くの組織と開発者は、設定ファイルを手動で編集するのではなく、ウェブベースのインターフェースを通じてNGINX設定の管理を一元化するためにnginx-uiを使用しています。このプロジェクトは11,000を超えるGitHubスターと約430,000のDockerプルを獲得しており、開発者とDevOpsコミュニティ内での人気と可視性の兆候です。nginx-uiの最近のバージョンは、多くの最新アプリケーションと同様に、MCPをサポートし、外部ツールとAIエージェントがNGINX設定を直接管理できるようにしています。
Pluto Securityの研究者は、nginx-uiのMCPメッセージエンドポイント、つまりコマンド実行リクエストを処理するURL (/mcp_message)が認証をまったく実行していないことを発見しました。これは、それに到達できる攻撃者が、有効な認証情報を提供することなく、任意の管理コマンドを発行し、nginx-uiの管理機能を直接制御できることを意味していました。
この脆弱性は、nginx-uiメンテナーによると、任意のネットワーク攻撃者が「認証なしにすべてのMCPツールを呼び出すことを許可し、nginxの再起動、nginx設定ファイルの作成/変更/削除、および自動設定リロードのトリガーを含む。完全なnginxサービスの乗っ取りを実現する」ことができます。
Plutoがnginx-uiのMCPフローで発見したことは、クライアントがまずMCPエンドポイント (/mcp)に接続してセッションを確立し、セッションIDを受け取り、その後、別の/mcp_messageエンドポイントを通じてコマンドを送信することでした。/mcp経由のセッション確立には、いわゆるnode_secretを通じた認証が必要でした。これは、信頼できるクライアントのみがMCPセッションを開始できるようにするためです。
しかし、Plutoのセキュリティ研究ディレクターであるYotam Perkalによると、その保護さえも弱く実装されていました。秘密自体は、最初のブート時に生成され、ユーザーごとの認証情報ではなく、共有秘密としてプレーンテキストで保存される静的なUniversally Unique Identifier (UUID)だったためです。したがって、理論的には認証はMCPセッションへのアクセスを制限することを意図していましたが、実際には、それはほとんど安全価値を提供していませんでした。
Perkalによると、node_secretを取得することも多くの場合非常に簡単でした。これは、nginx-ui内の別の脆弱性(CVE-2026-27944)のおかげで、app.iniと復号化キーを含むバックアップが露出していたためです。攻撃者がnode_secretを取得すると、MCPセッションを確立できたため、その後さらなる認証なしに/mcp_messageを通じて任意のコマンドを発行でき、nginx-ui管理NGINX環境の完全な制御を効果的に有効にしました。
同様に、nginx-uiの/mcp_messageエンドポイントのIPホワイトリスト保護はデフォルトで空であり、任意のIPからの接続を許可しています。つまり、リモート攻撃者は脆弱性を悪用できます。Perkalは「Shodanを通じて2,600を超える公開されているnginx-uiインスタンスを識別しました。すべてデフォルトポート9000で到達可能です」と述べています。「v2.3.3より前のバージョンを実行している場合、完全なチェーン(認証なしのバックアップダウンロード + MCPの乗っ取り)は、ゼロの認証情報とゼロのネットワーク近接性が必要でした。」
以前のCVE-2026-27944欠陥をパッチしたバージョンv2.3.3に更新した可能性のある人々については、攻撃者はおそらく何らかの事前ローカルネットワークアクセスを持つ必要があるだろうと、彼は付け加えました。
潜在的に深刻な結果
「NGINXは通常、本番サービスの前にリバースプロキシとして機能しているため、その設定を侵害することは、その背後にあるすべてを侵害することを意味します」とPerkalは述べています。「この脆弱性を悪用する攻撃者は、NGINX設定を完全に制御できます。」最悪のシナリオでは、攻撃者がサーバーブロックを書き直して、すべてのトラフィックを攻撃者が制御するエンドポイント経由でプロキシし、転送中のすべてのリクエスト、レスポンス、および認証情報をキャプチャできます。
また、無効な設定を書き込み、NGINXをダウンさせるリロードをトリガーし、その背後にあるすべてのアプリケーションとAPIも同様に起動させることもできます。この脆弱性は、完全なアーキテクチャ偵察も可能にし、既存のすべての設定を読む能力を含み、バックエンドトポロジー、アップストリームサーバー、TLS証明書パス、および内部サービスアドレスを表示できます。Perkalは指摘しています。
この脆弱性は、組織がAIエージェントとの相互作用を容易にするために既存のアプリケーションにMCPサポートを追加するときに出現している新しいリスクと露出のもう1つの例です。研究者は最近数ヶ月で、プロトコル自体の複数の脆弱性、およびウェブ上で増殖し始めた多くのMCPサーバーの脆弱性を発掘しています。
「既存のアプリケーションにMCPを追加するとき、アプリケーションの最も強力な操作を新しいHTTPエンドポイント経由で公開しています」とPerkalは言っています。「コアアプリケーションは数年の戦闘テスト済み認証(JWT、セッション管理、RBAC)を持つかもしれませんが、MCPエンドポイントは新しく、1つを逃すのは簡単です」と彼は言っています。
MCPが使用するHTTPストリーミングメカニズムは、通信を2つのエンドポイント間で分割するため、特に注意が必要です。「開発者は直感的に『接続』エンドポイントを保護しますが、実際の破壊的な操作が発生する『メッセージ』エンドポイントは保護しない」とPerkalは述べました。「チームは、アプリケーションが持つセキュリティ姿勢が、それが使用するMCPに適用されると仮定すべきではありません。」
翻訳元: https://www.darkreading.com/application-security/critical-mcp-integration-flaw-nginx-risk
