CVE-2026-0767
| 评估指标 | 官方评估与明细 |
|---|---|
| CVE 编号 | CVE-2026-0767 |
| 官方处理声明 (Vendor Disposition) | 已驳回 (Rejected) —— 非系统安全漏洞 (Not a Vulnerability) |
| 披露日期 | 2026-01-23 |
| 下发机构 (CNA) | Zero Day Initiative (ZDI-26-033) |
| 宣称的严重等级 | 中危 (Medium) —— CVSS 6.5 (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) |
| CWE 归类 | CWE-319（通过明文方式传输敏感信息） |
CVE 指控的具体内容
该 CVE 指控称，当部署人员在明文的普通 HTTP 协议而非加密的 HTTPS 协议下发布部署 Open WebUI 服务时，用户向系统登录接口提交的鉴权凭证（邮箱和密码）会在网络上以明文形式直接传输，从而允许网络上处于邻近位置（network-adjacent）的黑客直接进行数据拦截嗅探。
为什么这不属于系统漏洞
该报告指控的情况完全属于互联网 HTTP 基础传输协议的底层物理属性，根本谈不上是 Open WebUI 系统的代码安全缺陷。明文的 HTTP 请求在传输过程中不进行加密校验，属于协议原本的设计定义 —— 全球历史上诞生的任何 Web 应用程序，如果脱离 SSL/TLS 强制跑在纯 HTTP 协议下，都会表现出完全相同的行为。
Open WebUI 作为一套后端 Web 应用，只负责向上提供标准的基础 HTTP 传输端口。至于该接口在真实的投产部署中，是直接被暴露到公网上，还是后置在负责 TLS 加密证书卸载的反向代理（Reverse Proxy）后、抑或是配置在带有 TLS 加密的负载均衡器后，完全属于运维部署人员在系统架构规划时的客观决定。应用软件并不应该、也绝对无法替底层的基础网络协议传输配置做强行代理决策。该 CVE 漏洞报告的荒唐指控，在技术逻辑上完全等同于对外宣称：“如果运维人员部署 Apache HTTPD 服务时选择不开启 HTTPS，用户的登录凭证就会明文传输” —— 这无疑句句属实，但其绝对不构成 Apache HTTPD 软件的代码安全漏洞。
CVSS 评分印证非软件缺陷
该 CVE 下发的 CVSS 漏洞评分向量本身就已承认了这种伪漏洞场景在现实中的不切实际性：AV:A（邻近网络访问限制）和 AC:H（极高的攻击复杂度复杂度）充分证实了该指控的达成必须同时依赖于以下两项巧合：“运维人员部署时玩忽职守选择不开启 TLS” 以及 “黑客恰好潜伏在与服务器物理相邻的内网网段下伺机抓包”。在任何标准的、后置在 TLS 加密保护的反向代理下的正规生产环境部署中，这一指控场景根本不成立。
适用的安全策略条款
- 安全策略第 1 条：符合协议标准规范的预期网络传输属性不属于安全漏洞。HTTP 协议固有的明文特征是写入教科书的典型协议属性，而非软件漏洞。
- 安全策略第 6 条：该泄露场景仅在运维人员完全无视生产加固规范、强行选择不配置 TLS 证书时才会触发 —— 这并非 Open WebUI 软件默认配置的属性。
- 安全策略第 7 条：漏洞报告严重张冠李戴，将底层网络部署架构的运维问题捏造为应用层代码的缺陷。
对部署用户的实际影响
部署人员无需采取任何操作，前提是您的生产环境部署已经合理启用了 TLS 加密。如果您目前在公网生产环境下依然强行跑在纯明文 HTTP 协议上，请立刻通过反向代理为服务配置合规的 TLS 证书 —— 这是全球所有 Web 服务在投产时必备的标准运维防护手段，绝非针对此 CVE 的特意打补丁动作。详情请仔细 参阅 HTTPS 与反向代理配置指南。