2026-09-15 04:41:20 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： FoxitPDFReader存在CVE-2026-57239本地提权漏洞，攻击者需先获低权限代码执行能力，通过伪造winspool.drv文件及硬编码密钥解密用户可写目录下的配置文件，诱导更新服务以SYSTEM权限执行恶意命令。建议管理员立即升级至2026.1.2.36540版本，或临时禁用FoxitPDFReaderUpdateService服务。 综合评分： 85 文章分类： 漏洞分析,漏洞POC,安全建设

装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析

Ots安全

2026年9月14日 13:09 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

威胁简报

恶意软件

漏洞攻击

2026 年 7 月 8 日，Foxit 在安全公告页发布了一批 Windows 平台更新，Foxit PDF Reader 与 Foxit PDF Editor 各自升到 2026.1.2。同一批公告覆盖的编号多为解析 PDF 时的内存破坏问题，评分集中在 7.8 与 6.1 两档。其中有一条不属于这一类：它不涉及文档解析，不需要打开任何 PDF，翻遍描述也找不到越界写或悬垂指针。它要的只是两个用户本来就写得进去的位置，以及一段用硬编码密钥加密的指令。

编号 CVE-2026-57239，CWE 落在 CWE-427，CVSS 由厂商给 8.2、由 NVD 给 7.8。报告者是荷兰研究者 Luke Paris（@Paradoxis），报告日 2026 年 4 月 17 日，技术细节与一份 Rust 版 PoC 在 7 月 15 日公开。他给这篇文章起的标题是《Escalating All The Privileges With Foxit PDF Reader》，直译过来是把所有权限都提上去。这个说法不算夸大，链路的终点确实是 NT AUTHORITY\SYSTEM 的完整令牌。

值得单独写一篇的原因不在终点，而在路径。这条链没有一处内存破坏，全程只用了两个文件写入动作，其中一个写入的还是文本文件。它把”特权服务如何看待用户可写的数据”这个问题摆到了台面上。

一、时间线与三个窗口期

作者在原文末尾附了完整披露时间线，与 Foxit 官方版本历史页交叉后如下。官方版本历史页在这里补上了作者没有的两个关键日期。

| 日期 | 事件 | 来源 | | — | — | — | | 2026-03-25 | 开始研究 | 作者时间线 | | 2026-03-26 | 发现通过 WINSPOOL.DRV 的 sideload 技术，尚未找到触发提权的路径 | 作者时间线 | | 2026-03-31 | Foxit PDF Reader 2026.1.0.36452 发布，阻断该加载路径 | 官方版本历史页 | | 2026-04-14 | 逆向出进程间消息的加解密方案，同时发现 sideload 路径已被修补 | 作者时间线 | | 2026-04-15 | 发现替代的 sideload 技术 | 作者时间线 | | 2026-04-17 | 向 Foxit 报告 | 作者时间线 | | 2026-04-20 | Foxit 确认收到报告，正在分析复现 | 作者引用厂商邮件 | | 2026-04-27 | 2026.1.1.36485 发布，未含该修复 | 官方版本历史页 | | 2026-05-14 | 询问进展，Foxit 回复已复现，遵循 120 天修复政策，承诺 7 月 26 日前修复 | 作者引用厂商邮件 | | 2026-06-16 | Foxit 告知补丁将于下月发布，并附 CVE 编号与公告 | 作者引用厂商邮件 | | 2026-07-01 | Foxit 告知定于 7 月 8 日发布 | 作者引用厂商邮件 | | 2026-07-08 | 修复版本 2026.1.2.36540 与安全公告发布，分配 CVE-2026-57239 | 官方公告与版本历史页 | | 2026-07-15 | 原文章与 PoC 公开 | 原文章与 GitHub 仓库 | | 2026-08-13 | 2026.1.3.36551 发布 | 官方版本历史页 | | 2026-09-01 | 2026.2.0.39747 发布，当前最新 | 官方版本历史页 |

由此可得四个窗口期：

报告日到补丁日，2026-04-17 至 2026-07-08，共 82 天
首次发现日到补丁日，2026-03-26 至 2026-07-08，共 104 天
厂商承诺日与实际发布日，7 月 26 日比 7 月 8 日早 18 天，实际交付早于承诺
补丁日到细节公开日，2026-07-08 至 2026-07-15，共 7 天

82 天这个数字是本文最值得记住的一个数。厂商在 5 月 14 日的回复里明确说明遵循 120 天修复政策，实际用了 82 天，报告方也按约定等到了补丁发布后一周才公开细节。这套节奏对防御方有直接参照价值：本地提权类漏洞的修复周期以月计，任何”先观察再决定”的处置策略都要按这个量级来排。

二、影响范围：更新服务与一次对话框交互

2.1 Windows 平台与版本区间

官方公告给出的是分段表述，不是单一版本号。逐字如下：

| 产品 | 受影响版本 | | — | — | | Foxit PDF Reader | 2026.1.1.36485 and earlier | | Foxit PDF Editor | 2026.1.1.36485 and all previous 2026.x versions, 2025.3.0.35737 and all previous 2025.x versions, 2024.4.1.27687 and all previous 2024.x versions, 2023.3.0.23028 and all previous 2023.x versions, 14.0.4.33508 and all previous 14.x version, 13.2.4.24048 and earlier |

NVD 的 CPE 配置把区间切成更细的段，与上表逐条吻合：13.2.4.24048 及更早、14.0.0.33046 至 14.0.4.33508、2023.1.0.15510 至 2023.3.0.23028、2024.1.0.23997 至 2024.4.1.27687、2025.1.0.27937 至 2025.3.0.35737、2026.1.0.36452 至 2026.1.1.36485。Reader 侧只有一条，即 2026.1.1.36485 及更早。

注意到 2026 那条区间的起点不是最早的 2026 版本，而是 2026.1.0.36452。这个起点不是随手划的，它正是 3 月 31 日那次修补的发布版本，原因见 3.5 节。macOS 平台不受影响，同日发布的 macOS 公告未列入该编号。

判版本时容易踩的坑是把版本区间读成单点。Reader 用户只需看 2026.1.1.36485 这一个界；Editor 用户要按自己所在的版本线各查各的界，2025.x 线与 14.x 线的界不同。

2.2 更新服务是否在运行

漏洞的提权环节依赖 FoxitPDFReaderUpdateService.exe。这个服务以 NT AUTHORITY\SYSTEM 身份常驻，不需要用户打开 Foxit 主程序就会运行。装了产品但从不打开也不足以规避。

反过来说，如果某台主机通过组策略或部署工具停用了该服务，或者部署的是不含该服务的定制包，提权环节缺少执行者。这是全部判定项里唯一一个可以在补丁到位前主动处置的条件。停用服务的代价是自动更新失效，需要改用其他分发方式补丁。

2.3 是否已有本地代码执行能力

攻击向量是 AV:L，前置条件是攻击者已在目标主机上取得低权限代码执行能力。这条链的价值是二级跳板，不是入口。它把一次以普通用户身份落地的钓鱼载荷、宏文档或供应链投递，转换成主机上的完整 SYSTEM 控制。

作者在原文开头的摘要里把这一点写在最前面，措辞是不加修饰的：利用需要机器上已有某种形式的代码执行。本文沿用这个定性，不把它写成远程漏洞。

2.4 那一次对话框交互

向量里的 UI:R 指用户交互。本次的用户交互不是打开 PDF，而是攻击者通过写入的加密指令让更新器弹出一个组件下载对话框，再等待用户点击其中的链接。3.5 节会说明，这一步同时是绕过既有修补的关键。

用户交互的存在让链路的自动化程度打了折扣，但没有改变定性。系统管理员的日常操作场景里，一个由 Foxit 签名的进程弹出的组件提示对话框，点击门槛并不高。

2.5 一个不含修复的中间版本

时间线里有一行值得单独拉出来：2026-04-27 发布的 2026.1.1.36485，在报告日之后十天发布，且落在受影响区间内。这说明按月发布的版本节奏与安全修复节奏并不同步，从报告到修复之间厂商仍会发常规版本。

实际含义是，在 4 月 17 日到 7 月 8 日之间，管理员看到产品提示有新版本、升级、重启，漏洞依然存在。判断修复状态只能看版本号是否跨过 2026.1.2.36540，不能看”已经是最新版”这个提示。把更新提示当作修复确认，在这类事件里会持续误判。

三、原因导致：一份 DLL 清单与一个硬编码字面量

3.1 三个被监视的文件与一个可写目录

漏洞的两端分别是一个用户可写目录和一个 SYSTEM 服务。作者用进程监控工具盯住服务后，看到它持续轮询三个文件：

C:\ProgramData\Foxit Software\Foxit PDF Reader\Foxit Service\Log\log.libC:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txtC:\Program Files\Foxit Software\Foxit PDF Reader\ProfStore\ProfStore.xml

三个文件里，前两个位于 ProgramData 下，Users 组默认持有写权限，作者实机确认过这一点。第三个位于 Program Files 下，普通用户无写权，作者也确认过，因此不构成攻击面。真正起作用的是 FoxitData.txt，服务读它的内容并据此发起进程创建。

图上事件流的每一行都来自 SYSTEM 身份的 FoxitPDFReaderUpdateService.exe：查询文件属性、打开、读取、设置属性、关闭，对象始终是同一个 FoxitData.txt。一个高权限进程以固定节奏读取一个低权限用户写得进去的文件，这条数据通路就是整个提权链的骨架。它本身还不构成漏洞，漏洞在于这个文件里的内容会被当作可执行指令。

3.2 三十二项清单里没有 winspool.drv

更新器 FoxitPDFReaderUpdater.exe 位于用户自己的 %APPDATA%\Foxit Software\Continuous\Addon\Foxit PDF Reader\ 下，同样在可写范围。它启动时会在同目录里依次尝试加载一批模块。作者反编译后得到的清单包含 RICHED20.DLL、CRYPTSP.dll、USERENV.dll、profapi.dll、RpcRtRemote.dll、apphelp.dll、ntmarta.dll、DEVRTL.dll、credssp.dll、DNSAPI.dll、rasadhlp.dll、schannel.DLL、RASAPI32.dll、rtutils.dll、sensapi.dll、dhcpcsvc.DLL、secur32.dll、ncrypt.dll、bcrypt.dll、GPAPI.dll、cryptnet.dll、dhcpcsvc6.DLL、Cabinet.dll、WindowsCodecs.dll、version.dll、mslso.dll、CRYPTBASE.dll、MSASN1.dll、d3d10warp.dll、netutils.dll 以及两个 Manifest 文件名，合计 32 项。

检查逻辑只有两行：

PathCombineW(dll_path, installer_dir, dll_filename);if&nbsp;(&nbsp;PathFileExistsW(dll_path) )&nbsp; &nbsp;&nbsp;break;

拼接路径，判断存在，存在就用。这段逻辑对清单内的项成立，对清单外的项不成立。

问题的关键就在图里看不出来的那一项：winspool.drv 不在这份清单里，但程序会去同目录找它。清单承担的是允许列表的角色，而检查只在允许列表内部生效。允许列表之外还有加载目标，这是本次事件的第一处根因。

winspool.drv 虽然用驱动后缀，实际是标准 PE 文件，加载时会执行 DllMain，因此投放一个同名文件即可在更新器进程内取得代码执行。同批被引用的 oleaccrc.dll 情况不同，它是资源 DLL，一般以 LOAD_LIBRARY_AS_DATAFILE 标志加载，只读取资源不执行代码。作者在原文里对两者作了区分，本文照此区分，不把两者并列成同一种攻击面。

把 winspool.drv 与列表里那 29 个 DLL 放在一起看，能看出检查清单是”程序主动列出想加载什么”的白名单，而 Windows 的模块搜索顺序决定了程序还会被动加载一些它没列的东西。白名单覆盖不到被动加载项，这是 427 类缺陷的常见形态。

3.3 指令通道的机密性靠一个字面量

FoxitData.txt 里存的不是明文。服务端解密后才使用其内容。作者反编译出的关键调用是这一行：

maybe_initialize_key(&encryption_key, "c6c7702dbcbf4678",&nbsp;0x10u);

0x10 即十进制的 16，对应 AES-128。整体算法为 AES-128-CBC，初始向量为全零。密钥的取法在作者 PoC 源码注释中写明：把该 16 字符字面量做 Base64 编码后取前 16 字节。

这里要把实测值与推断值分开。反编译视图给出的是那个字面量本身与长度参数 0x10（实测）；”Base64 编码后取前 16 字节”这一具体取法来自 PoC 源码注释与作者实际跑通的结果（实做验证），不是反编译代码的逐行阅读结论。两条证据互为印证，本文按此表述。

解密后的明文是一条以双竖线分隔的键值串，字段为三项：

sessionid=1||strTempUpdaterPath=<更新器自身路径>||csCommandLine=<要执行的命令行>

strTempUpdaterPath 指向更新器自己的位置，csCommandLine 是随后要执行的命令行，其中含 -updater、-type、-hwnd、-readerpath、-regpath、-version、-UpdateMode、-SessionID 等参数。

一个 SYSTEM 服务把自己要启动什么程序的决策依据，放在一个所有用户都能写的文件里，而保护这个文件的机密性只靠一个硬编码在二进制里的十六字符常量。这个常量对任何拿到更新服务可执行文件的人都是可读的。命令行的结构反过来还给了攻击者调节执行参数的抓手，3.5 节的替代路径正是从 -type 这个参数入手的。

3.4 证书校验挡住的是文件，不是加载路径

作者在写下第一版 PoC 之前尝试过最直接的做法：把更新器可执行文件本身换掉。这条路走不通，服务端有两道检查。

第一道是文件名检查，限定被执行的更新器文件名，排除直接替换成系统工具的可能。第二道是证书校验，验证目标文件的签名有效性，并且进一步限定不能是任意一张有效证书，需要匹配预期签发方。作者在反编译视图里找到了两处检查的位置，也确认了它们覆盖的范围。

两道检查都作用在被执行的 PE 文件上，不作用于该文件将要加载的模块。sideload 投放的 winspool.drv 不在被校验对象里，因此它在证书校验完好无损的情况下照样加载。这是同一类问题里最常被问到的一点：为什么签名校验有效，攻击仍然成立。原因是校验的是主体文件的签名，而代码执行发生在被加载的模块里。

作者顺带留了一句判断：理论上可以用检查与使用之间的时间差构造竞争条件绕过文件检查，但没有往下做。本文把这个分支记为作者的判断，不作为已验证结论。

校验边界的划分需要一个明确原则：凡是特权进程会加载的内容，都要纳入同一套信任判定，不能只判定主程序。只判定主程序的结果就是把加载路径整体留在了信任边界之外。

3.5 修补一次，换一条路进来

原始路径在 2026 年 3 月 31 日发布的 2026.1.0.36452 里被关闭。作者 4 月 14 日逆向出加解密方案时，才发现 sideload 这条路已经走不通。

接下来两天他试了几条思路：竞争条件、机会锁（OpLock，Windows 的一种文件锁机制）、命名管道强制，都没找到能直接利用的点。转机出现在一个不起眼的参数上：用 -type 参数可以强制更新器弹出一个组件下载对话框。对话框里的链接被点击后，应用会重新尝试加载外部模块。

于是链路重新闭合：加密指令让更新器弹出对话框，用户点击链接触发模块重新加载，同目录的恶意模块随之被载入，而这次加载发生在服务以 SYSTEM 身份启动的更新器进程内。修补的是第一扇门，第二扇门一直开着。

这也解释了 NVD 的 CPE 区间为什么从 2026.1.0.36452 起算。这个起点不是”漏洞从这里开始”，而是”从这里开始补了一次，但没堵住”。把起点读成引入版本会得出错误的修谱结论。

修补后的路径不在检查清单里，攻击面就还在。这类修补的本质是收敛了一个具体入口，没有改变”更新器从用户可写目录加载模块”这个结构性前提。结构不变，替代入口就总有被找到的可能。

四、漏洞触发：从一次写入到 SYSTEM 令牌

4.1 两步动作与一次进程创建

整条链的攻击者侧只有两个文件操作动作：

向 %APPDATA%\Foxit Software\Continuous\Addon\Foxit PDF Reader\ 投放恶意 winspool.drv
向 C:\ProgramData\Foxit Software\Foxit PDF Reader\FoxitData.txt 写入用硬编码密钥加密的指令

两个位置都在攻击者可写范围内，不需要管理员权限，不需要驱动加载权限，不需要重启。服务读到指令后以 SYSTEM 身份启动更新器，更新器启动时加载同目录的恶意模块，代码在 SYSTEM 上下文中执行。

这张图是整条链最硬的一张证据。进程路径栏是用户自己的 AppData 目录，用户栏是 NT AUTHORITY\SYSTEM，完整性级别栏是 System，会话标识为 1，启动时间与作者脚本执行时间吻合。一个位于用户可写目录的可执行文件，以最高权限账户被启动，三个字段合起来就说明了全部。

同类事件里常有人争论”用户目录下运行的程序算不算提权”，这张图给出判据：看的不是路径在哪，而是进程的令牌与完整性级别是什么。路径不决定权限，令牌决定权限。

4.2 令牌、环境块与 CreateProcessAsUserW

服务端为什么要复制别的进程的令牌，作者反编译出的执行逻辑分四步：

枚举进程，找出属于目标会话（sessionid=1）的 winlogon.exe
打开该进程并复制其令牌
以该令牌创建环境块，继承标志设为 TRUE
调用 CreateProcessAsUserW 创建进程

关键调用在反编译视图里长这样：

CreateProcessAsUserW(process_token_handle_duplicated,&nbsp;0, lpCommandLine,&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0, 0, 0, dwCreationFlags, Environment,&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;0, &StartupInfo, &ProcessInformation);

同屏还能看到把命令行逐字搬运的循环（v67 += 2），即从 ANSI 到 UTF-16 的转换。上一节提到的编码问题就出在这里：服务端按 UTF-16 处理输入，写入方按 ANSI 编码就会静默失败，没有任何报错。

作者在原文里顺带记了一笔：环境块继承的是用户会话中 winlogon 进程的令牌，他一度想过能否构造出不需要用户重新登录的变体，但没有验证下去。这一点本文照原样记录，不替他把这个分支补完，公开材料到此为止。

使用 CreateProcessAsUserW 而不是直接 CreateProcessW，说明服务端是有意把新进程放进目标用户的会话与桌面里的。工程上的用意是让更新界面能正常显示，代价是令牌来源变成了可枚举的 winlogon 进程，而上下文参数最终又来自一个用户可写的文件。用于改善体验的机制与用于隔离权限的机制在这里方向相反，服务端选择了前者。

4.3 UTF-16 这一步的代价

作者在原文里用了不小的篇幅讲一个失误：他最初按 ANSI 编码写入十六进制密文，尝试了多种加解密组合都得不到正确结果，直到用 API 监控工具钩住 Foxit PDF Reader 看它实际写入了什么，才发现少了一件事，写入方按 UTF-16LE 编码时每个字符前面都有一个 0x00 字节。改用 UTF-16LE 之后一次通过。

这一步的代价是他自己说的，花了数小时。对防御方而言这一步有实际含义：这类私有协议的判读，靠猜编码格式会反复失败，观察真实进程的写入内容是唯一可靠入口。反过来，攻击者侧同样如此，这条链的可复现程度依赖作者把这一步踩通。

写入格式整体为：明文按 UTF-16 编码，用 AES-128-CBC 加密，密文转成十六进制字符串，再按 UTF-16 编码写入文件。作者在原文中完整给出了加密脚本，本文不复制该实现，只描述算法与参数。

4.4 绕过修补后的第二条加载路径

替代路径启用后，更新器会在同目录里重新发起模块查找。作者用进程监控工具记录下了第二轮查找：

事件流里 FoxitPDFReaderUpdater.exe 对 PROPSYS.dll、secur32.dll、MLANG.dll、msvcp110_win.dll 逐一发起打开请求，结果栏多数是 NAME NOT FOUND，中间还夹着一次返回 BUFFER OVERFLOW 的查询。查找发生在用户自己的 AppData 目录下，按目录内优先级，投放同名文件即可命中。

这张图与前面那张清单图合起来交代了同一件事的两种形态：白名单里没有的目标程序照样会去找，而一旦找到就会用。secur32.dll 这个文件名同时出现在 Merlon 的检测规则里，说明实际利用时被投放的模块不止 winspool.drv 一个。

4.5 PoC 的形态与证据边界

公开的 PoC 仓库为 Rust 实现，2026 年 7 月 8 日建仓，与补丁同日。命令行提供三个入口：

check

：判断当前安装的 Foxit PDF Reader 版本是否在受影响范围内
exploit

：执行提权链
cleanup

：清理利用过程中留下的文件

两条技术路径以参数选择，分别为 win-spool-sideload 与 updater-link-sideload，对应修补前后的两个入口。构建脚本把单独编译的 elevator.dll 以 include_bytes! 内嵌进主程序，运行时释放，因此最终交付的是单个可执行文件。仓库未附许可证文件，这一点在合规层面需要注意，本文不引用其源码，也不提供构建产物。

第三方漏洞库对该仓库的判定为可用的实际利用而非检测器，理由是它包含可运行的主程序与独立编译的载荷模块。这个判定与仓库内容吻合。

证据边界要写清：本次没有源码，也没有补丁差异可读。3.3 节的密钥取法、4.2 节的令牌流程，全部来自对已编译二进制的反编译与实机行为记录，不属于补丁代码阅读结论。这一句在参考章会再标一次。

五、补丁分析：修复版本号在转述中走样

5.1 官方公告给出的修复版本

Foxit 官方公告的标题直接写了版本：Security updates available in Foxit PDF Reader 2026.1.2 and Foxit PDF Editor 2026.1.2，发布日期 2026 年 7 月 8 日。同一 CVE 还出现在同日另外两则公告里，分别对应 Foxit PDF Editor 14.0.5 与 Foxit PDF Editor 13.2.5，三则的漏洞描述段落完全一致，只有受影响版本范围不同。

官方版本历史页补上了 build 号与日期，答案为 2026.1.2.36540。三个产品线的修复版本分别是：Reader 升到 2026.1.2，Editor 的 2026.x 线升到 2026.1.2、14.x 线升到 14.0.5、13.x 线升到 13.2.5。

5.2 作者与转述媒体写的 2026.2

原文章的处置建议节写的是升级到 2026.2。这个说法被后续转述普遍沿用，可查到的包括 sectoday 的中文报道、securebulletin、hackersradar、一则 LinkedIn 技术帖，以及 Mallory 与 Armis 两家漏洞库的修复建议字段。Armis 还另外把 14.x 线的修复版本写成 14.1，而官方公告写的是 14.0.5。

一个版本号在转述链里被替换成另一个，通常不值得单列一节。本次值得，因为两个版本号之间存在 55 天的时间差，而这个差会直接影响处置排期。

5.3 决定性的时间证据

判断哪个口径正确，不需要争论，看发布日期即可。

Foxit 官方版本历史页显示，2026.2.0.39747 的发布日期是 2026 年 9 月 1 日，是当前最新版本，属于功能版本，更新说明里是 AI 助手、工作区、本地模型一类内容。而原文章与全部转述文字出现于 2026 年 7 月 15 日。写作时 2026.2 还不存在。

结合受影响版本的上界是 2026.1.1.36485、修复版本是 2026.1.2.36540，结论清楚：官方一手来源给出的修复版本是 2026.1.2.36540，作者写的 2026.2 是口径偏差。

按转述口径处置会怎样：管理员看到文章说升到 2026.2，而 7 月时产品最高只到 2026.1.2，可能判断为”还没有修复版本”而搁置，实际修复版本已经发布并可安装。修复时点从 7 月 8 日被推迟到 9 月 1 日，中间 55 天。转述一个版本号，代价是一台主机多暴露近两个月。

版本号这类硬信息必须以官方公告为准。第三方漏洞库与安全媒体的修复建议字段属于转述层，出现偏差是常态，本条记录是可复现的例证。

5.4 同一处加载路径被多方同期发现

时间线里有一条容易忽略的巧合。作者 3 月 26 日发现通过 WINSPOOL.DRV 的 sideload，5 天后即 3 月 31 日，Foxit 发布 2026.1.0.36452，关闭了这条加载路径。

官方 4 月 1 日的安全公告给出了该次修补的归属：CVE-2026-3775，DLL Hijacking（CWE-427），7.8 分，报告者是 Erik Egsgard（Field Effect，经 TrendAI 零日计划）；以及 CVE-2026-3780，Untrusted Search Path（CWE-426），7.3 分，报告者 Kara Zaffarano。两条与作者发现的是同一处加载路径。

作者在原文里对自己的运气做了推测：他怀疑是自己在一台联网的干净机器上测试触发了崩溃转储，进入厂商遥测后被识别，导致厂商抢先修补。他把这段话明确标注为个人推测，也说明自己无意向厂商求证。

这里要按两个来源并列处理：官方公告把该次修补归属于两位具名报告者；作者的说法是自述推测，且他自己承认无法证实。两条并列写，不裁定谁促成了修补。对防御方的实际含义与归属无关：同一处加载路径在一个月内被三方独立发现，说明它的可见度很高，发现成本不高。

六、结束语

6.1 这一类缺陷的通用结构

Foxit 这个案例不是孤例。同一类结构在多个产品的自动更新器上被反复发现，公开的技术资料把它们归在一起：低摩擦的进程间通信面，加上一条以特权身份执行的更新路径。

可对照的公开案例有几类形态。一类是命名管道暴露过宽的访问控制与模拟级别，客户端传入的命令标识会映射成不同的模拟级别与完整性标识，改一个数值就让新进程带着完整系统令牌启动。一类是组件对象模型（COM，Windows 的进程间组件调用机制）形式的提权助手，服务端只取用低权限侧计算出的判定结果，判定逻辑放在一个用户态动态库里，改掉这个库就能让它放行任意程序。还有一类是更新或修复流程把临时脚本写进可预测路径并特权执行，用户抢先占用该路径即可替换执行内容。

这些案例的共同结构可以概括成一个判断：当特权进程消费来自低权限侧的数据、判定结果或执行路径时，权限边界就已经从内核挪到了用户可写的文件系统上。Foxit 本次是数据与路径两头都落在低权限侧，硬编码密钥只是让这条通路不那么直白，不构成边界。

七、参考

https://www.foxit.com/support/security-bulletins.htmlhttps://www.foxitsoftware.com/pdf-reader/version-history.htmlhttps://blog.paradoxis.nl/escalating-all-the-privileges-with-foxit-pdf-reader-cve-2026-57239-582a78b60492https://github.com/Paradoxis/CVE-2026-57239https://nvd.nist.gov/vuln/detail/CVE-2026-57239https://cveawg.mitre.org/api/cve/CVE-2026-57239https://github.com/advisories/GHSA-x8h2-84hg-x9j6https://mallory.ai/vulnerabilities/CVE-2026-57239https://cve.armis.com/CVE-2026-57239https://hacktricks.wiki/en/windows-hardening/windows-local-privilege-escalation/abusing-auto-updaters-and-ipc.html

END

公众号内容都来自国外等平台- 搜索的内容通过结合编写 –

提供整洁 – 广告已关

公众号 | AnQuan7 (Ots安全)

免责声明：

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

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

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

本文转载自：Ots安全《装了Foxit（福昕阅读器）的机器要看一眼： CVE-2026-57239 提权链解析》