CVE-2026-67598

Emlog Pro — AI アシスタントにおける TLS 証明書検証の無効化

ネットワーク隣接型 MITM → LLM プロバイダー API キーの盗難 & AI レスポンス注入

サマリー · 攻撃フロー · 影響を受けるコード · 証明 · 修復策 · タイムライン · 参考情報

📋 概要

🔎 サマリー

Emlog Pro には、管理者向けの AI アシスタント (admin/ai.php + include/service/ai.php) が同梱されており、 設定された LLM プロバイダーに対して送信 HTTPS 呼び出し(チャット、ストリーミング、画像生成)を行います。 さらに、@em-help コマンド用の Bing スクレイピングヘルパーも備えています。

すべての送信リクエストヘルパーは、TLS 証明書の検証を無条件に無効化しています:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);

検証は、設定されたプロバイダー URL やネットワーク経路に関係なくオフになっているため、 Emlog サーバーと api_url の間にいるネットワーク隣接型 / 中間者攻撃者は、 偽造証明書を使用して TLS セッションを透過的に傍受し、以下を行うことができます:

• 🔑 Authorization: Bearer <apiKey> ヘッダーを盗む — サイトの有償 LLM プロバイダー API キーです。
• 💉 悪意のある AI レスポンスをアシスタントに注入する。このアシスタントは、 query_database と update_config のツールアクセス権を持つ LLM を駆動します。

これは純粋なトランスポートセキュリティ上の欠陥であり、AI ツール呼び出しの確認 UI によって 制限されません。

🧭 攻撃フロー

flowchart LR
    A["🖥️ Emlog server<br/>AI assistant"] -->|"HTTPS request<br/>Bearer &lt;apiKey&gt;"| M{"😈 MITM attacker<br/>(forged cert)"}
    M -->|"TLS verify DISABLED<br/>→ accepted"| P["☁️ LLM provider"]
    M -.->|"🔑 reads API key"| X["Key exfiltrated"]
    M -.->|"💉 forged response"| A
    A -->|"acts on injected<br/>AI output"| T["⚙️ query_database /<br/>update_config tools"]

    classDef bad fill:#7f1d1d,stroke:#ef4444,color:#fff;
    classDef ok  fill:#1e3a8a,stroke:#3b82f6,color:#fff;
    class M,X bad;
    class A,P,T ok;

💥 影響

• API キーの情報開示 — サイトの有償 LLM プロバイダーキーの窃取と経済的悪用。
• レスポンス注入 — 攻撃者が制御するコンテンツが AI アシスタントのストリームに入り込みます。
• 悪用のハードルが低い — ネットワークに隣接する位置(共有ホスティング、敵対的な Wi-Fi、 侵害されたルーター、悪意のある egress プロキシ)があれば十分です。Emlog のインストールに対する 認証情報は一切不要です。

📂 影響を受けるコード

include/service/ai.php — 以下の関数内の CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST 呼び出し:

🧪 証明 / 検証

# 1. Configure the AI assistant with any OpenAI-compatible provider URL + API key.
# 2. Put a MITM proxy with an UNTRUSTED CA between Emlog and the provider:
mitmproxy --mode reverse:https://api.provider.example -p 8443

# 3. Trigger any AI chat / image-gen / @em-help request from the admin panel.
# 4. Result: request succeeds despite the untrusted cert, and the
#    "Authorization: Bearer ..." header is readable in the proxy log
#    → certificate validation is confirmed disabled.

🛠️ 修復策

include/service/ai.php 内のすべての送信呼び出しで TLS 検証を有効にします:

- curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
- curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
+ curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
+ curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);

プライベート CA を使用するセルフホスト型 / OpenAI 互換エンドポイントは、カスタム CA バンドル (CURLOPT_CAINFO)でサポートしてください — 検証をグローバルに無効化することは絶対に避けてください。

🔗 関連メモ(同一機能、別の堅牢化)

同じ AI 機能の監査中に、Ai::queryDatabase() が blog テーブルへの直接 SQL 書き込みは 特別にブロックするものの、(role / password を保持する)user テーブルはブロックしないことが 判明しました。@em-help を介した間接プロンプトインジェクション経路(ライブの Bing 検索結果と スクレイピングした FAQ が query_database / update_config ツールアクセス権を持つモデルに 供給される)と組み合わせると、write_article がブログ投稿をすでに処理しているのと同様に、 user / options への書き込みを狭いスコープのツール経由でルーティングすることで堅牢化する価値が あります。詳細は REPORT.md を参照してください(上記 CVE とは別に追跡されています)。

🗓️ タイムライン

📚 参考情報

• 🆔 CVE レコード — https://www.cve.org/CVERecord?id=CVE-2026-67598
• 🛡️ NVD — https://nvd.nist.gov/vuln/detail/CVE-2026-67598
• 📢 GitHub アドバイザリ — GHSA-hf85-99vj-m4c5
• 📦 ベンダー — https://github.com/emlog/emlog
• 📝 詳細レポート — REPORT.md

_{調整された開示の一環として、教育および防御セキュリティ目的で公開されています。
発見・報告: Ilhomjon Rustamov (@IlhomjonR) · CNA: VulnCheck}