AIを社内導入する企業が増えるなか、ローカル環境やプライベートクラウドで動作するLLMフロントエンドのセキュリティ設計が急速に重要性を増している。2025年7月に公開されたOpen WebUI 0.9.5は、外部へのHTTPリクエストを伴う5つの機能すべてにリダイレクトベースのSSRF対策を実装し、攻撃者が公開URLを経由して内部ネットワークへ侵入する経路を遮断した。同時にiframeのコンテンツポリシー制御やMarkdownレンダリングの個別無効化など、運用管理者とエンドユーザーの両面からリスクを低減する仕組みを加えたリリースである。

オープンソースLLM運用基盤のセキュリティ課題

Open WebUIはDockerを用いてオンプレミスやVPS上に数分でデプロイできるLLMチャットインターフェースであり、2025年に入りGitHubスター数が7万を超えるなど導入が加速している。企業がこの種のツールを選ぶ理由は、APIキーや会話ログをSaaS事業者のサーバーに送信せず、自社管理のLLMエンドポイントと組み合わせられる点にある。しかし利便性の裏で、Web検索や画像読み込み、OAuth認証、コード実行機能などが外部URLへHTTPリクエストを発行する仕様は、SSRF（Server-Side Request Forgery）の入口になり得た。攻撃者が細工したURLをチャット経由で投入し、リダイレクトを使ってAWSのメタデータサービス（169.254.169.254）や内部APIへアクセスさせる手口は、クラウド環境では致命的な情報流出に繋がる。

今回のアップデート以前は、こうしたリダイレクト連鎖をアプリケーションレベルでブロックする仕組みが存在せず、各管理者がリバースプロキシで対処する必要があった。Open WebUI 0.9.5はこの問題をデフォルトで解決し、非公開環境でAIエージェントを動かすための前提条件を一段引き上げた形だ。

全HTTP発信点に適用されたブロックとiframe制御の構造

0.9.5の中核は、新環境変数AIOHTTP_CLIENT_ALLOW_REDIRECTSの導入である。この変数により、Webフェッチ、画像ローディング、OAuthディスカバリ、ツールサーバー実行、コードインタープリタのログイン処理という5つの呼び出し経路すべてで、3xxリダイレクトがデフォルトで拒否される。攻撃者が公開ドメインに設置した短縮URLやリダイレクトスクリプトを踏ませても、内部アドレス（RFC 1918、ループバック、クラウドメタデータエンドポイント）へ到達する前に通信が遮断される設計だ。

さらにIFRAME_CSP環境変数によって、LLMが生成したHTMLやユーザーがアップロードしたファイルをプレビューするsrcdoc iframeにContent-Security-Policyを適用可能になった。Artifactsやツール埋め込み、引用モーダルがiframeで表示される構造を逆手に取ったスクリプト実行を、管理者がポリシーベースで制限できる。

もう一つの構造的な変更は、チャンネル機能におけるストリーミングとツール呼び出しの完全対応である。チャンネル内でモデルをメンションすると、Web検索や画像生成、MCPツール、RAGナレッジ注入まで、通常のチャットと同等のパイプラインがリアルタイムストリーミングで動作する。これはOpen WebUIをSlackライクなAIコラボレーションハブとして使う企業にとって、機能格差を解消する変更だ。

自社ホストAIの信頼境界がもたらす産業構造への影響

Open WebUIのセキュリティ強化は、単なるOSSの機能追加を超えて、エンタープライズAIの調達判断に影響を与える。AnthropicのClaudeやOpenAIのChatGPT Enterpriseが提供するSaaS型の安全策に対し、オープンソーススタックでも同等の信頼境界を確立できるかが、特に金融機関や医療機関での採用を左右するからだ。GitHubの公開データによれば、Open WebUIのフォーク数は1万を超え、企業内にフォークしてカスタマイズする事例が増加している。0.9.5で追加されたTERMINAL_PROXY_HEADERS環境変数は、ターミナルプロキシ応答に任意のレスポンスヘッダーを注入できるため、サンドボックスポリシーを組織ごとに強制したい大企業の要請に応えるものだ。

日本市場では、自治体や金融系システムにおけるオンプレミスLLM導入の検討が2024年後半から活発化している。とくに個人情報保護の観点からクラウド利用を制限する地方銀行や医療機関にとって、リダイレクトSSRFとiframeインジェクションの両方を標準でブロックする今回のアップデートは、セキュリティ評価を通過するための要件を満たす材料となる。

エージェント権限とSSRF対策の限界

今後の焦点は、AIエージェントが自発的に外部へHTTPリクエストを発行するケースでの権限設計である。0.9.5のSSRF対策はアプリケーション層のHTTPクライアントに適用されるが、ツールサーバーがコンテナ外のネットワークに直接アクセスできる構成では、別レイヤーの防御が必要になる。また、チャンネル機能へのフルツール対応により、一通のメンションでコード実行やWeb検索が起動するため、参加者の権限粒度と監査ログの整備が次の課題となる。OAuth認証と連携する組織では、IDプロバイダー側の属性に基づいて、どのツールをどのチャンネルで使えるかというポリシー制御の需要が高まるだろう。