nginx-uiのMCPエンドポイント認証欠如（CVE-2026-33032）が実攻撃に、パッチなし

nginx-uiをセルフホストしている環境は今すぐ対応が必要だ。CVE-2026-33032（CVSS 9.8）は、Webブラウザからnginxを管理できるオープンソースツール「nginx-ui」に存在する認証バイパスで、2026年4月時点で実際の攻撃が確認されている。パッチはまだ公開されていない。

発見はPluto Securityのyotampe氏で、脆弱性は “MCPwn” とも呼ばれている。
Shodan（インターネット接続デバイスの検索エンジン）の調査では約2,600〜2,689件のインスタンスがインターネットに露出しており、中国・米国・インドネシア・ドイツ・香港に多く分布している。

nginx-uiとは

nginx-uiは、nginxのWebベース管理インターフェースを提供するオープンソースツールだ。ブラウザ上でnginx設定ファイルの編集・追加・削除、nginxの起動・停止・再起動を行えるほか、証明書の管理（Let’s Encrypt連携）や設定のシンタックスハイライト、アクセスログのリアルタイム表示などの機能を持つ。Go製で、デフォルトはポート9000でリッスンする。個人VPSからチームのインフラ管理まで幅広く利用されている。

問題のバージョン2.x系では、Anthropicが策定したMCP（Model Context Protocol）の統合が追加された。AIエージェントがnginxをツールとして操作できるようにする機能だが、このエンドポイントの実装に重大な欠陥があった。

脆弱性の技術的詳細

エンドポイント間の認証の非対称性

nginx-ui v2.3.5以前は、MCP関連のHTTPエンドポイントを2つ公開している。

エンドポイント	IPホワイトリスト	認証（AuthRequired）
/mcp	適用	必須
/mcp_message	適用	なし

両エンドポイントは同じハンドラ mcp.ServeHTTP() を呼び出す。つまり、/mcp_message を経由すれば /mcp が要求する認証を完全に回避できる。

IPホワイトリストの「フェイルオープン」挙動

もう一方の制御であるIPホワイトリストにも致命的な設定デフォルト値の問題がある。ホワイトリストが空（デフォルト状態）の場合、ミドルウェアは「全許可」として動作する。

// IPホワイトリストミドルウェアの実装（概略）
if len(settings.AuthSettings.IPWhiteList) == 0 {
    c.Next()  // ← リストが空 = 全IPを許可
    return
}

結果として、デフォルト設定のまま稼働しているインスタンスは、IPアドレスによる制限もなく、認証もなく、インターネット上の誰からでも /mcp_message エンドポイントにアクセスできる状態になっている。

CVSSベクタ

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• 攻撃元（AV）: ネットワーク（リモートから）
• 攻撃複雑度（AC）: 低
• 必要権限（PR）: なし
• ユーザー操作（UI）: 不要
• 機密性（C）・完全性（I）・可用性（A）: すべて高

CVSS v3.1で9.8というスコアは「認証なし・ネットワーク越し・操作不要・完全乗っ取り可能」の組み合わせが揃って初めて出る数値だ。

攻撃で利用できるMCPツール

/mcp_message 経由で未認証のまま呼び出せるMCPツールの一覧を示す。

カテゴリ	ツール名	操作内容
設定管理	nginx_config_add	設定ファイルの新規作成
設定管理	nginx_config_modify	既存設定の書き換え
設定管理	nginx_config_delete	設定ファイルの削除
設定管理	nginx_config_rename	ファイル名変更
設定管理	nginx_config_read	設定の読み取り（バックエンド構成の漏洩）
ディレクトリ操作	directory_create	ディレクトリ作成
サービス制御	nginx_restart	nginxの再起動
サービス制御	nginx_reload	設定の即時反映
監視	ステータス確認	サービス稼働状況の取得

これらを組み合わせると、攻撃者は次のことが可能になる。

• リバースプロキシ設定を挿入してHTTPリクエストを傍受・改ざん
• 設定ファイルから内部のバックエンドサーバーのアドレスや構成を読み取る
• 意図的に壊れた設定をプッシュしてnginxをサービス停止させる
• 正常な設定を削除してサービスを崩壊させる

攻撃チェーンの例

graph TD
    A[攻撃者] -->|JSON-RPC 2.0リクエスト<br/>ポート9000| B[/mcp_messageエンドポイント]
    B -->|IPホワイトリスト空<br/>= 全許可| C[認証チェックをスキップ]
    C -->|nginx_config_addを呼び出し| D[悪意ある設定ファイルを注入]
    D -->|nginx_reloadを呼び出し| E[設定を即時反映]
    E --> F[トラフィック傍受<br/>認証情報窃取]
    E --> G[バックエンド構成の漏洩]
    E --> H[サービス停止<br/>設定の破壊]

実際の攻撃はJSON-RPC 2.0形式のリクエスト1本から始まる。認証ヘッダー不要、ユーザーの操作も不要で、公開インスタンスであれば外部から即座に実行できる。

現状とGitHub Advisory

脆弱性は2026年3月28日にGitHub Security Advisory（GHSA-h6c2-x2m2-mwhf）として公開された。
執筆時点（2026年4月16日）でパッチは存在しない。米国サイバーセキュリティ・インフラセキュリティ庁（CISA）とVulnCheckはどちらも実際の悪用を確認したと報告している。

修正のために必要なコード変更はシンプルだ。/mcp_message ルートに AuthRequired() ミドルウェアを追加すればよい。

// 修正後のルーティング（例）
r.Any("/mcp_message", middleware.IPWhiteList(), middleware.AuthRequired(), handler)

加えて、IPホワイトリストが空の場合のデフォルト動作を「全許可」から「全拒否」に変更することも同時に必要だ。現状のフェイルオープン設計は、IPホワイトリストを防御として期待している運用者を誤解させる。

緩和策

パッチが出るまでの当面の対応として以下を検討する。

即時対応

nginx-uiをインターネットに直接公開している場合は、今すぐファイアウォールで9000番ポートへの外部アクセスを遮断する。
管理インターフェースはVPN経由かローカルネットワーク内からのみアクセスできる構成にすべきだ。

MCPエンドポイントの無効化

nginx-uiの設定でMCP統合を無効化できる場合は無効にする。AIエージェントからの操作を利用していないなら、エンドポイントを公開する理由はない。

ネットワーク分離

ShodanやCensysでインスタンスが公開されていないか確認する。
管理ツールのポートがパブリックIPに直接バインドされているケースは、この脆弱性に限らずリスクが高い。

ログ監査

既に侵害されている可能性を想定して、nginx-uiのアクセスログで /mcp_message への不審なPOSTリクエストを確認する。
過去のアクセス記録と設定ファイルの変更履歴を照合して、意図しない設定変更がないかチェックしたい。

MCPサーバーのセキュリティ問題は以前から指摘されている。
オープンソースMCPサーバー50件のスキャン調査では61%で入力バリデーション欠如が検出されており、「エンドポイントに認証を付け忘れる」タイプの問題はnginx-uiに限った話ではない。
MCPを実装したツールを導入する際は、公開エンドポイントと認証の有無を自分で確認しておきたい。