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 响应注入回助手，而该助手驱动的 LLM 拥有 query_database 和 update_config 工具访问权限。

这是一个纯粹的传输安全缺陷——它不会被 AI 工具调用确认界面拦截。

🧭 攻击流程

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、被入侵的路由器、恶意的出口代理）都足够；无需 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 写入，但不会阻止对 user 表（保存有 role / password）的写入。结合通过 @em-help 的间接提示注入路径（实时 Bing 结果 + 抓取的 FAQ 被输入到拥有 query_database / update_config 工具访问权限的模型中），值得通过将 user / options 的写入路由到范围受限的工具来进行加固——就像 write_article 已经处理博客文章那样。完整详情见 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}