你本地跑的AI助手,一个空密码就能登录——Open WebUI曝4个高危漏洞

🚨 紧急预警：你自建的AI助手正在裸奔

2026年5月15日，Open WebUI 在同一天被披露了4个高危漏洞（CVSS 9.1/8.8/8.7/8.7），涵盖LDAP空密码认证绕过、代码执行开关形同虚设、多实例Redis缓存投毒、以及恶意文件上传XSS。好消息是，这些漏洞影响了Open WebUI 0.9.0之前的版本；坏消息是——如果你的Open WebUI部署了LDAP企业登录，攻击者只需要发送一个空密码就能绕过认证，以任意用户身份登录你的AI平台。

更令人不安的是，这不是孤立事件。Open WebUI 是一个拥有13.7万个GitHub Star的开源项目——它是全球最流行的本地AI聊天界面，也是中国AI爱好者自部署Ollama+Open WebUI的标准配置。从高校实验室到创业公司，从个人开发者到中小企业，无数团队用Open WebUI搭建了私有AI助手。这些部署中，相当一部分直接暴露在公网上，没有任何反向代理或认证加固，这些系统可能正在向攻击者敞开大门。

LDAP认证是企业环境中最常见的统一登录方式之一，也是本次漏洞中风险最高的攻击面。当攻击者发现一个公网Open WebUI实例时，只需要尝试LDAP登录接口——如果服务器配置了LDAP并允许空密码绑定，攻击者在几秒钟内就能以管理员身份登录系统。随后，利用CVE-2026-45672的代码执行绕过，攻击者可以直接在服务器上运行任意Python脚本，从窃取API密钥到建立后门，再到横向移动进入内网，整个攻击链只需要几分钟。

风险确认表

⏱️ 快速自查：你的Open WebUI安全吗？

第一步：检查版本号

登录你的Open WebUI管理后台，查看页面底部的版本信息。如果你的版本低于 0.9.0（修复LDAP+Redis漏洞需要0.9.0以上），或低于 0.9.3（修复音频上传XSS需要0.9.3以上），则处于受影响范围。

第二步：检查是否启用了LDAP登录

在管理后台 → 设置 → LDAP配置中，如果 "Enable LDAP" 开关是打开的，你的平台暴露在CVE-2026-44551空密码绕过风险下。立即关闭LDAP登录，直到升级到修复版本。

第三步：检查代码执行开关

在管理后台 → 设置中检查 "Enable Code Execution" 设置。即使它显示为 false（已关闭），如果你的版本低于0.8.12，攻击者仍然可以通过直接调用 /api/v1/utils/code/execute API来执行任意Python代码。

🛡️ 自救指南

第一优先级（24小时内）：阻断攻击面

# 1. 立即关闭LDAP登录
# 在管理后台取消勾选 "Enable LDAP"
# 2. 临时禁用代码执行（虽然不能完全阻止CVE-2026-45672）
docker exec open-webui sed -i 's/ENABLE_CODE_EXECUTION=true/ENABLE_CODE_EXECUTION=false/' .env
docker restart open-webui

第二优先级（48小时内）：升级到修复版本

Open WebUI 官方已在以下版本中修复了这4个漏洞：

• v0.8.12 — 修复CVE-2026-45672（代码执行绕过）
• v0.9.0 — 修复CVE-2026-44551（LDAP绕过）和CVE-2026-44552（Redis缓存）
• v0.9.3 — 修复CVE-2026-45315（音频上传XSS）

# Docker部署的推荐升级命令
docker pull ghcr.io/open-webui/open-webui:latest
docker stop open-webui
docker rm open-webui
docker run -d --name open-webui \
  -p 3000:8080 \
  -v open-webui:/app/backend/data \
  ghcr.io/open-webui/open-webui:latest

第三优先级：修复后安全加固

升级完成后，执行以下措施：

• 1. 修改所有用户密码 — 特别是管理员账号，假设LDAP空密码漏洞已被利用
• 2. 检查系统日志 — 查看auths.py日志中是否有来自陌生IP的LDAP空密码登录记录
• 3. 审计Redis数据库 — 检查是否有异常的tool_servers或terminal_servers键值
• 4. 添加反向代理层 — 在Nginx或Caddy层面限制对敏感API路径的访问

🔬 技术分析：4个漏洞的攻击链

CVE-2026-44551：LDAP空密码认证绕过（CVSS 9.1）

这是本次披露中 最严重 的漏洞。Open WebUI的LDAP认证端点在 backend/open_webui/routers/auths.py 的第468-477行中，直接将用户提交的密码传递给LDAP服务器进行Simple Bind操作——却没有检查密码是否为空。

Pydantic模型 LdapForm 定义密码字段为 password: str，没有任何最小长度约束。攻击者只需要发送一个带有空密码字符串的API请求，LDAP服务器就会对空字符串进行Simple Bind——很多LDAP服务器（包括OpenLDAP和Active Directory）在特定配置下会接受空密码的Simple Bind，返回成功的绑定结果。

更可怕的是，认证成功之后，Open WebUI会使用返回的LDAP用户信息创建一个本地会话，攻击者完全接管了该用户的角色。攻击者不需要知道任何密码，只需要知道LDAP用户的用户名，发送一个curl请求即可登录。

CVE-2026-45672：代码执行开关形同虚设（CVSS 8.8）

Open WebUI提供了一个 ENABLE_CODE_EXECUTION 环境变量，管理员可以通过设为 false 来阻止用户执行任意Python代码。但安全研究者发现，/api/v1/utils/code/execute 这个API端点 完全忽略了这个配置开关。

管理后台的设置面板会正确显示 "Code Execution: Disabled"，然而API端的代码从未检查该标志——它直接将用户提交的Python代码转发到后端的Jupyter服务器执行。这意味着任何已经登录的用户（包括通过LDAP空密码绕过进来的攻击者）都可以 直接POST任意Python代码 到服务器执行，从读取环境变量中的API Key，到扫描内网，再到建立反向Shell，没有任何限制。

CVE-2026-44552：Redis多实例缓存投毒（CVSS 8.7）

这个漏洞影响多实例部署的Open WebUI。当两个或以上的Open WebUI实例共享同一个Redis数据库时（官方文档支持的多区域部署、蓝绿部署或集群拓扑），tool_servers 和 terminal_servers 两个Redis键 没有使用实例专属的前缀。

这意味着实例A的管理员配置的tool_servers列表会被实例B读取到，反之亦然。攻击者如果获得了任何一个Redis客户端的写入权限，就可以 覆盖tool_servers键的值，让所有共享Redis的实例连接到攻击者控制的恶意API服务。在工具调用执行过程中，这些恶意API可能读取用户对话、窃取LLM API密钥甚至执行系统命令。

CVE-2026-45315：音频上传存储型XSS（CVSS 8.7）

Open WebUI的音频转写上传统一入口 /api/v1/audio/transcriptions 的漏洞更加隐蔽。它从用户提供的文件名中获取扩展名，将文件保存为 CACHE_DIR/audio/transcriptions/<uuid>.<ext>。而 /cache/{path} 路由通过 FileResponse 提供文件服务时，Content-Type完全取决于磁盘上的文件扩展名。

攻击者可以上传一个 polyglot WAV+HTML文件——既是一个合法的WAV文件（通过音频转写检查），又包含嵌入的HTML+JavaScript代码。由于文件名以 .html 结尾，浏览器访问时将其作为HTML渲染，执行其中的恶意脚本。该文件通过Open WebUI的聊天接口自动触发（因为聊天中的音频消息会自动加载），实现存储型XSS。任何查看该聊天的用户都会触发攻击。

这4个漏洞不是孤立存在的——它们构成了一个完整的攻击链。LDAP空密码绕过（CVE-2026-44551）是大门，让攻击者进入系统；代码执行绕过（CVE-2026-45672）是武器，让攻击者在服务器上执行任意命令；Redis缓存投毒（CVE-2026-44552）是扩音器，将攻击扩大到一个集群的所有实例；音频上传XSS（CVE-2026-45315）是监听器，让攻击者在用户侧持久潜伏。单独看任何一个漏洞都有临时缓解方案，但组合起来就是一条完整的攻击流水线。

🎯 攻击场景还原

第一阶段：侦察。 攻击者扫描公网IP，发现一台部署了Open WebUI的服务器。通过访问 /auth/signin 端点确认其使用LDAP认证。

第二阶段：空密码绕过。 攻击者发送一个简单的POST请求到LDAP登录接口，提交已知的用户名（如 admin）和空密码。如果LDAP服务器接受空密码的Simple Bind，攻击者立即以 admin身份登录系统，获得完整的管理员权限。

第三阶段：远程代码执行。 以管理员身份登录后，攻击者调用 /api/v1/utils/code/execute API提交恶意Python payload，读取环境变量中的Ollama API Key、数据库连接信息、Redis密码，并在服务器上建立持久化后门。

第四阶段：横向移动与持久化。 通过内网扫描，攻击者发现其他共享同一Redis数据库的Open WebUI实例，利用CVE-2026-44552投毒tool_servers缓存，扩大攻击面。同时，通过音频上传XSS（CVE-2026-45315）在聊天中植入恶意脚本，潜伏监听后续管理员的对话。

🇨🇳 中国用户影响分析

Open WebUI 在中国拥有巨大的用户基数。原因主要有三点：

第一，本地AI部署的标配。 由于海外AI服务的访问限制，中国AI用户大量自部署本地LLM。Ollama + Open WebUI 的组合是目前最流行的本地AI对话方案。从B站到知乎，大量教程教用户"一行命令部署本地AI助手"。这些教程中很少有人提及 Open WebUI的LDAP配置安全——大多数用户甚至不知道自己的Open WebUI暴露在公网上。

第二，企业LDAP部署比例高。 中国大部分中大型企业使用钉钉、企业微信或自建LDAP进行统一身份认证。当企业IT部门将Open WebUI接入企业LDAP时，空密码绕过意味着 任何知道内部用户名的员工（或攻击者）都可以以该用户身份登录AI平台。考虑到很多企业使用工号、邮箱前缀等可猜测的用户名规则，攻击者完全不需要内网信息即可发起攻击。

第三，多实例部署场景常见。 跨国企业在中国区和海外区各部署了Open WebUI实例，共享同一Redis集群的场景在中国外企中并不罕见。CVE-2026-44552的Redis缓存投毒漏洞可以 跨区域传播恶意配置，一个区域的沦陷可能导致全球部署的连锁反应。

第四，安全问题被功能开发掩盖。 Open WebUI从2024年至今已经披露了超过30个CVE，从文件上传到会话固定到SSRF，几乎每隔几周就有新的安全问题被发现。然而每次修复之后，项目仍然以极快的速度添加新功能——MCP服务器支持、多模态能力、实时语音对话——而安全审查的速度显然跟不上功能迭代的步伐。对于中国用户来说，这意味着不能等到漏洞被披露才行动，而是需要在部署Open WebUI的第一天就建立安全基线。

🏢 企业应急响应建议

• 1. 资产盘点 — 立即排查企业内部所有自部署的Open WebUI实例，包括开发环境、测试环境和生产环境。使用Docker ps和K8s查询脚本逐一确认版本号。
• 2. 风险分级 — 按照"启用LDAP > 暴露公网 > 多实例Redis共享"的优先级评估风险等级。同时满足三个条件的实例为最高风险。
• 3. 分阶段补丁部署 — 高风险实例24小时内关闭LDAP登录并升级到v0.9.3+，中风险实例72小时内升级。升级前确认LDAP已临时关闭。
• 4. 日志审计 — 检查最近1个月的登录日志，筛选出LDAP认证中password字段为空的登录记录。同时检查code/execute API的调用记录，确认是否有异常的Python执行请求。
• 5. 长期加固 — 在Open WebUI前面添加反向代理（Nginx/Caddy），限制对敏感端点的访问。考虑使用WAF规则检测空密码登录模式。对多实例部署，评估Redis实例隔离方案。

📜 Open WebUI安全历史回顾

这并非Open WebUI第一次曝出安全漏洞。作为一款快速迭代的开源AI界面项目，Open WebUI的安全记录呈现出典型的"功能优先于安全"模式：

2024年10月（v0.3.8） — 批量曝光15个CVE，包括 任意文件上传（CVE-2024-7034，CVSS 7.2）、跨站请求伪造提权（CVE-2024-7806，CVSS 8.8）、以及会话固定漏洞（CVE-2024-7053，CVSS 9.0）。当时已经有安全研究者警告："Open WebUI将大量安全决策交给了前端而非后端执行。"

2025年11月（v0.6.34） — 又一批7个CVE被披露，包括SSRF（CVE-2025-65958，CVSS 7.1）和代码注入（CVE-2025-64496，CVSS 8.0）。这次的安全研究者指出，Open WebUI的 ——不同的API端点使用了不同的授权检查机制，有些端点完全遗忘了加入检查。

今天4个CVE延续了同样的模式：后端验证缺失 和 配置与执行分离。管理员在界面上关闭了代码执行，但API层根本没有读取这个配置，配置标志成了一个纯粹的UI装饰；管理员配置了LDAP密码验证，但后端只调用了Pydantic的类型检查而未做业务校验，空字符串通过了所有验证；管理员部署了多实例Redis，但缓存键没有实例隔离，两个实例之间就像住在同一间宿舍的室友——互相能看到对方的全部私人物品。

这些不是新技术的漏洞，而是 最基础的编程疏忽——在一个功能快速扩张的开源项目中，这类疏忽往往被迭代速度掩盖。它们不依赖于复杂的利用技术，不需要ROP链或堆喷射，仅仅是一行 if not password: raise 就能堵住的漏洞，却被遗漏了数个版本。

🛡️ 防御纵深建议

单纯依赖升级是不够的。对于将Open WebUI作为内部AI入口的组织，建议从以下五个层面构建防御体系：

• 网络隔离 — 不要让Open WebUI直接暴露在公网上。使用内部网络 + VPN/反向代理的访问模式。如果必须公网访问，务必在反向代理层面加入IP白名单或二次认证。
• LDAP加固 — 在LDAP服务器层面拒绝空密码的Simple Bind请求。OpenLDAP可以通过设置 olcDisallows: bind_anon 来加强安全策略。
• Redis实例隔离 — 多实例部署时，为每个Open WebUI实例使用独立的Redis数据库（不同db index或不同Redis实例），避免缓存投毒。
• 日志监控 — 配置审计日志，监控敏感API端点（如 /api/v1/utils/code/execute 和 /api/v1/auths/ldap）的异常访问模式。
• 漏洞扫描 — 将Open WebUI纳入定期漏洞扫描范围。由于该项目频繁发布安全修复（从2024年至今已累计30+个CVE），建议设置每月至少一次的安全评估。

🔗 解决方案与参考

官方修复版本：v0.9.3 及以上（覆盖全部4个CVE）。强烈建议所有用户升级到最新版本。

引用链接：

1. GitHub Security Advisory - CVE-2026-44551: github.com/open-webui/open-webui/security/advisories/GHSA-2r4p-jpmg-48f4

2. GitHub Security Advisory - CVE-2026-45672: github.com/open-webui/open-webui/security/advisories/GHSA-482j-2pq6-q5w4

3. GitHub Security Advisory - CVE-2026-44552: github.com/open-webui/open-webui/security/advisories/GHSA-3x8w-4f7p-xxc2

4. GitHub Security Advisory - CVE-2026-45315: github.com/open-webui/open-webui/security/advisories/GHSA-m8f9-9whg-f4xr

5. Open WebUI Releases: github.com/open-webui/open-webui/releases

6. NVD: nvd.nist.gov

龙虾池子 · AI 自动生成