文章总结： 文档披露了DeepChatElectron客户端中CVE-2026-43899远程代码执行漏洞的完整技术细节。该漏洞因开发团队在修复前序漏洞CVE-2025-55733时仅修补了preload脚本中的shell.openExternal调用路径，却遗漏了tabPresenter.ts中通过setWindowOpenHandler触发的第二条路径，导致攻击者可通过恶意API端点或PromptInjection在AI响应中植入危险协议链接，用户点击后直接绕过白名单过滤执行系统命令。文章强调AI客户端中用户对AI链接的天然信任加剧了漏洞危害，并指出安全修复必须系统性枚举所有危险API调用路径。官方已在v1.0.4-beta.1版本中统一添加协议验证，建议用户立即升级并谨慎点击AI生成链接。 综合评分： 90 文章分类： 漏洞分析,应用安全,AI安全,安全开发

CVE-2026-43899 打了补丁，但只补了一半：DeepChat Electron RCE 与不完整修复的代价

原创

CVE-SEC CVE-SEC

CVE-SEC

2026年5月12日 11:01 新疆

在小说阅读器读本章

去阅读

打了补丁，但只补了一半：DeepChat Electron RCE 与不完整修复的代价

CVE-2026-43899 | CVSS 9.6 | 严重

前言

2025 年，研究人员在 AI 桌面客户端 DeepChat 中发现了一个严重问题：应用允许 AI 响应中的链接调用任意系统协议，从而触发本地代码执行。开发团队迅速响应，在 preload/index.ts 中添加了 URL 协议白名单过滤，修复了 CVE-2025-55733。

然而，代码库中存在第二条触发同一危险 API 的路径。这条路径被遗漏了。

2026 年 4 月，研究人员 YLChen-007 发现并报告了这一遗漏，CVE-2026-43899 随之披露。这个漏洞的 CVSS 评分 9.6，技术路径与前任几乎完全相同，却完整绕过了专门为拦截前任而构建的防御机制。

一次不完整的安全修复，换来了一个全新的满分级漏洞。

DeepChat 与 Electron 安全模型

DeepChat 是一款基于 Electron 框架构建的 AI 桌面客户端，支持接入 OpenAI、Anthropic Claude、本地模型（Ollama）等多种 AI 服务，用户可以自定义配置任意兼容 OpenAI 格式的 API 端点。

理解这个漏洞，需要先理解 Electron 的基本安全架构。

Electron 应用由两个运行在不同权限层的进程组成：渲染进程（Renderer Process）承载网页内容，运行在受限的沙盒环境中，对系统资源的访问受到严格限制；主进程（Main Process）拥有完整的 Node.js 权限，可以访问文件系统、执行系统命令、调用操作系统功能。

shell.openExternal() 是主进程中的一个高危 API，调用它可以让操作系统用对应的应用程序打开任意 URI——不仅是 http:// 和 https://，还包括 ms-msdt://（Windows 诊断工具协议）、smb://（SMB 文件共享协议）、file://（本地文件协议）、calculator:// 等任意已注册的系统协议。

在不同操作系统上，ms-msdt:// 可以触发远程命令执行，smb:// 可以触发 NTLM 凭据泄露。shell.openExternal() 是 Electron 应用中最危险的 API 之一，使用时必须对 URL 进行严格过滤。

第一次修复做了什么

CVE-2025-55733 的修复在 src/preload/index.ts 中实现了一个 isValidExternalUrl 函数，并通过白名单机制过滤所有经由 api.openExternal() 接口触发的 URL：

const ALLOWED_PROTOCOLS = ['http:', 'https:', 'mailto:']

const isValidExternalUrl = (url: string): boolean => {
  try {
    const parsed = new URL(url)
    return ALLOWED_PROTOCOLS.includes(parsed.protocol.toLowerCase())
  } catch {
    return false
  }
}

openExternal: (url: string) => {
  if (!isValidExternalUrl(url)) {
    return Promise.reject(new Error('URL protocol not allowed'))
  }
  return shell.openExternal(url)
}

这段修复本身是正确的。对于经由 preload 脚本 IPC 接口触发的 shell.openExternal() 调用，过滤是有效的，CVE-2025-55733 的攻击路径被关闭了。

问题是，shell.openExternal() 在代码库中不止被调用了一次。

被遗漏的第二条路径

src/main/presenter/tabPresenter.ts 中，有一段处理 Electron 原生弹窗的代码：

// 处理外部链接
webContents.setWindowOpenHandler(({ url }) => {
  shell.openExternal(url)
  return { action: 'deny' }
})

setWindowOpenHandler 是 Electron 的主进程事件处理器，当渲染进程中触发了”新窗口打开”事件时（例如用户点击了带有 target="_blank" 属性的链接），这个处理器会被调用。

这里的 shell.openExternal(url) 调用完全绕过了 preload/index.ts 中定义的 isValidExternalUrl 过滤逻辑——因为这条路径根本不经过 preload 脚本，而是直接在主进程内部触发，绕过了整个 IPC 层和 preload 层。

第一次修复保护了一道门，但另一道门从未被关上。

攻击者如何利用这条路径

DeepChat 允许用户配置自定义 AI API 端点，这是攻击面的核心。当攻击者控制 API 端点，或者通过 Prompt Injection 操控正常 AI 服务的响应内容时，可以让 AI 返回包含恶意协议链接的 Markdown 文本：

请 [点击这里](calculator://) 以继续。

DeepChat 的 Markdown 渲染器将这段文字解析为一个带有 target="_blank" 属性的 HTML 链接元素。当用户点击这个链接时，Chromium 渲染进程检测到 target="_blank" 属性，不直接跟踪链接，而是触发新窗口打开事件。

主进程中的 setWindowOpenHandler 捕获这个事件，取出 URL——也就是 calculator://——直接传给 shell.openExternal()，没有任何验证，没有任何过滤。操作系统响应，计算器弹出。

在实际攻击场景中，calculator:// 只是一个无害的演示载荷，用于验证漏洞存在。将其替换为 ms-msdt://id PCWDiagnostic...（Windows 下的命令执行）、smb://attacker-ip/share/file（NTLM 凭据窃取）、file://C:/Users/.../credentials 等协议，后果截然不同。

这个漏洞为什么需要特别关注

AI 客户端领域的安全模型与传统 Web 应用存在本质差异，这个差异使此类漏洞的危险性被系统性低估。

在传统应用中，用户对”哪些链接是可信的”有相对清晰的判断——来自熟悉域名的链接、来自明确业务场景的链接。但 AI 对话场景打破了这种判断基础：AI 的响应在绝大多数情况下是有帮助的、是可信的，用户对 AI 给出的链接不会产生与普通网页链接相同程度的警觉。

攻击者利用的正是这种信任。一个恶意的 API 端点，或一个被 Prompt Injection 攻陷的正常 AI 服务，可以生成一个文字描述完全正常（”点击这里查看详情”）但 URL 使用危险协议的 Markdown 链接。用户的点击行为是自然的、是被诱导的，而不是被骗的。

Prompt Injection 作为攻击向量意味着，即使用户使用的是完全合规的 AI 服务提供商，只要 AI 处理了攻击者构造的输入（例如，用户让 AI 分析一个网页，而这个网页中包含注入指令），AI 的响应就可能携带恶意载荷。

不完整修复的工程意义

CVE-2026-43899 提出了一个关于安全修复的重要工程问题：如何保证修复是完整的？

漏洞是对某个危险操作（shell.openExternal()）缺乏保护，修复添加了一个保护层（isValidExternalUrl 白名单）。但如果这个危险操作在代码库中存在多个触发点，仅仅保护其中一个触发点并不能解决问题——它只是让问题从一个位置转移到了另一个位置。

正确的修复流程应当是：

第一步：枚举代码库中所有可能触发危险操作的代码路径，而不仅仅是当前已知的那一条。grep -rn "shell.openExternal" 这样的简单命令，在修复 CVE-2025-55733 时如果被执行，就能立即发现 tabPresenter.ts 中的第二条路径。

第二步：对每一条路径独立添加保护，而不是假设只要修复了一条，其他条路径就是安全的。

第三步：为所有触发路径编写自动化测试，防止未来的代码改动重新引入未保护的路径。

这三步在修复 CVE-2025-55733 时均未完整执行，导致 CVE-2026-43899 的出现。

官方修复

v1.0.4-beta.1 的修复简洁且有效：在 tabPresenter.ts 的 setWindowOpenHandler 中，为 shell.openExternal() 的调用添加了与 preload/index.ts 中相同的 URL 协议验证逻辑。非白名单协议的 URL 会被直接拒绝，shell.openExternal() 不会被执行。

两条触发路径现在都经过同一个安全过滤器，漏洞的直接触发条件被消除。

GitHub 仓库地址：https://github.com/ThinkInAIXYZ/deepchat

用户应该做什么

立即升级至 DeepChat v1.0.4-beta.1 或更高版本。

升级前的临时措施：不要在 DeepChat 中配置来源不明的自定义 API 端点；不要点击 AI 响应中的任何链接，即使链接文字看起来完全正常。

企业环境中，可以在 EDR 解决方案中为 DeepChat 进程配置子进程创建监控规则：若 DeepChat 的直接子进程为 cmd.exe、powershell.exe、mshta.exe 等系统管理进程，应立即告警。

对 Windows 用户而言，考虑通过组策略禁用 MSDT 协议处理程序（ms-msdt://），这个协议是 Electron 应用 shell.openExternal() 漏洞中最常被用于命令执行的载荷入口之一。

结语

CVE-2026-43899 的核心教训不是”AI 应用不安全”，而是”安全修复需要系统性”。

一个针对 shell.openExternal() 的 SSRF-like 漏洞，因为修复时只覆盖了一条触发路径，在几个月后以相同的技术路线、相同的危害程度重新出现。不同的 CVE 编号，相同的根因，完全可以被一次彻底的代码审计所避免。

随着 AI 桌面应用的快速普及，Electron 安全成为一个越来越值得关注的领域。shell.openExternal() 是一个高危 API，Prompt Injection 是一个现实的攻击向量，两者的结合在 AI 客户端中构成了一个新兴的、尚未被广泛认知的攻击面。

参考资料

• GitHub Security Advisory: https://github.com/ThinkInAIXYZ/deepchat/security/advisories/GHSA-cp8j-jx7q-7r5f
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-43899
• DeepChat GitHub: https://github.com/ThinkInAIXYZ/deepchat

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：CVE-SEC CVE-SEC CVE-SEC《CVE-2026-43899 打了补丁，但只补了一半：DeepChat Electron RCE 与不完整修复的代价》