文章总结： 本文分析IDM内核驱动idmwfp.sys的CVE-2026-90493本地提权漏洞。该漏洞因设备对象对所有认证用户开放完全访问权，且驱动缺少路径、调用者及HKCU映射三道校验，导致普通用户可通过IOCTL操作注册表，进而修改系统服务配置提权至SYSTEM。PoC已公开，影响所有常规安装IDM的系统，厂商未发布补丁。 综合评分： 88 文章分类： 漏洞分析,恶意软件,应急响应

---

被改写的系统服务：IDM 内核驱动 CVE-2026-90493 提权

Ots安全

2026年9月13日 13:45 广东

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

威胁简报

恶意软件

漏洞攻击

前言

2026 年 9 月 13 日凌晨，VulDB 作为 CNA 发布了一个编号，把一款装机量以亿计的下载工具推到了本地提权的名单上。编号是 CVE-2026-90493，产品是 Internet Download Manager，问题出在它随包安装的一个内核驱动 idmwfp.sys 上。

这件事的特殊之处不在漏洞本身的形态，而在围绕它的一组反差。同一个编号，VulDB 给 9.3 分并标为 CRITICAL，NVD 用自己的向量算出来是 8.5 分并标为 HIGH。CVE 记录写的影响范围截止到 6.42 Build 63，而厂商官方更新页在同一时期已经发到 6.43 Build 10。漏洞报告在 7 月 15 日就把完整源码和预编译二进制放上了 GitHub，厂商在随后一个月里连发三个版本，更新日志里一个字都没提驱动安全。

而整条提权链，被写成了一段六行的批处理脚本。

一、先看问题：一个 9.3 分与一个 8.5 分

1.1 编号、定性与三个判断位

CVE-2026-90493 的官方标题是 Tonec Internet Download Manager Kernel Driver idmwfp.sys access control。受影响组件定性为内核驱动，攻击向量为本地，权限前置为低权限。

CVE 记录里有一句必须原样读出的话：“The exploit is now public and may be used.” 这是 CNA 对利用状态的白纸黑字判断。向量里的 E:P 项与之一致，表示存在概念验证代码。同一段描述里还有另一句，同样需要原样读：“The vendor was contacted early about this disclosure but did not respond in any way.”

CVE 记录中的三个常用判断位在这条编号上全部是”无”：没有进 CISA KEV，没有公开的野外利用报告，NVD 状态停在 Received。前两项容易理解，第三项需要单独说明，因为它决定了这个编号现在的可信度结构。

1.2 NVD 的状态停在 Received

NVD 记录里两个字段值得单独看：vulnStatus 是 Received，configurations 是 null。

configurations 为 null 意味着 NVD 还没有生成 CPE 匹配规则，也就是说所有引用这个编号的工具都还没有拿到”NVD 认可的受影响版本判据”。Received 是 NVD 处理流程中较早的状态，比 Awaiting Enrichment 更靠前，只表示记录已收到、尚未进入分析。

由此可以推出一个对使用者的实际含义：目前能查到的全部分数与分类，源头都是 VulDB 一家。Rapid7、InfoSecCenter 这些数据库页面显示的 8.8、9.3，逐条追下去都会回到 [email protected] 这个来源。这不是说数据有问题，而是说这个编号还没有经过第二家独立机构的评分复核，把它当成定论使用需要留一层余地。

二、影响范围

2.1 这台机器装过 IDM

第一个条件不需要额外动作。idmwfp.sys 不是可选组件，IDM 常规安装就会把它落到 C:\Windows\System32\drivers\ 下，并创建名为 IDMWFP 的服务加载它。文件属性里的描述是 Internet Download Manager WFP Driver，签名方为 Tonec Inc.。

驱动的用途与它的名字一致。WFP 是 Windows 过滤平台的缩写，这个驱动参与网络流量处理。公开的社区实测记录显示，驱动启用后由 System 进程打开一个监听 127.0.0.1:1001 的本地 HTTP 服务，IDM 的浏览器扩展通过这个端点与主程序通信，新建下载任务。这也解释了它为什么会提供注册表读写接口，因为它需要为 IDM 读写自身配置。

含义是清晰的：攻击面随常规安装一起落地，不需要用户额外开启任何功能，也不存在”只装了但没用”的豁免情形。驱动一旦加载，设备接口就在那里。

2.2 驱动当前是否处于加载状态

第二个开关比第一个更容易变动。驱动由服务加载，服务名为 IDMWFP，可以用系统的服务查询工具确认当前状态。若服务被手动停止、驱动文件被清理工具删除、或系统做过卸载残留清理，攻击面就随之消失。

这里有一个容易误判的地方：IDM 主程序是否正在运行与攻击面无关。驱动由服务控制管理器加载，不依赖用户是否打开了下载界面。判断依据应该是服务与驱动文件的存在状态，而不是任务栏里有没有 IDM 的图标。

2.3 只需要一个普通账号

PoC 报告列出的前置条件只有两项：本地已认证用户权限，以及能够打开设备接口 \\.\IDMWFP。

明确不需要的条件同样要列清：不需要管理员权限，不需要 SeRestorePrivilege，不需要 SeLoadDriverPrivilege，不需要调试权限，不需要交互式用户确认。

这与设备对象的安全描述符直接相关。报告的反编译结论是，驱动在 DriverEntry 里创建设备对象时套用了 D:P(A;;GA;;;AU)。这串描述符的含义是：AU 代表 Authenticated Users，即所有已认证用户；GA 代表 GENERIC_ALL，即完全访问权。所有已认证用户对该设备拥有完全访问权，这是整个链条的第一块基石，也是这份描述符把门槛从管理员降到了普通账号的原因。

2.4 没有可以关掉的配置项

多数产品漏洞可以通过调整配置来收窄暴露面，这个编号是例外。报告的第五节逐条列出了驱动缺失的三类校验，其中一类正是”没有把操作限定到调用者自己的 HKCU 映射”。也就是说，不存在一个”打开安全模式”或”限制为本用户”的开关可以把它关小。

因此准确的影响范围表述应该是四个开关的合取：装了 IDM、驱动处于加载状态、本机存在任意一个普通本地账号。三个条件同时成立时，该账号即具备提升到系统级执行的通路。 环境里有几个普通账号不影响判断，因为攻击者只需要其中一个。

三、原因导致：三道没做的校验

3.1 一块对所有认证用户敞开的设备

根因需要两个条件同时成立，这个驱动两者都满足，所以两组问题要分开看。

第一组是设备侧。D:P(A;;GA;;;AU) 让任何已认证用户都能拿到设备的完整访问权，于是任何普通本地用户都可以向 \\.\IDMWFP 发送 DeviceIoControl 请求。报告把这个条件列为漏洞成立的第一项前提。

需要说明的是，安全描述符过宽本身通常不足以构成高危问题，因为驱动可以在请求处理阶段补上调用者校验。这个驱动的问题恰恰在于它没有补，这就是第二组问题。

3.2 一个内核注册表代理

分发函数是 IRP_MJ_DEVICE_CONTROL 的处理例程，报告给出的地址是 sub_14000E9E0。其中 IOCTL 0x12C028 走注册表操作路径，请求的第一个字节作为子命令选择器，0x0C 到 0x0F 四个子命令全部进入同一个处理函数 sub_140005B90。

四个子命令的功能划分如下：

| 子命令 | 功能 | | — | — | | 0x0C | 查询值 | | 0x0D | 创建缺失的键路径并写入值 | | 0x0E | 删除值 | | 0x0F | 删除值，并在键为空时删除键 |

处理函数内部会从用户输入中解出”注册表相对路径 + 值名”两部分。根前缀由请求包里的 flags 字段低位决定：flags & 0x1 映射到 \REGISTRY\MACHINE\，flags & 0x2 映射到 \REGISTRY\USER\。路径字符串在驱动内解码后，于路径末尾的反斜杠处切分成键路径与值名。

完成这些解析之后，处理函数直接调用一组内核注册表 API：ZwOpenKey、ZwCreateKey、ZwDeleteValueKey、ZwDeleteKey、ZwQueryValueKey、ZwSetValueKey。

调用链到这一步就没有别的了。这组 API 的能力上限，就是这套接口的能力上限，而中间的约束环节全部缺失。

3.3 缺失的三道校验

报告第五节用三个”没有”概括了根因，逐条抄录：

1. 驱动没有限制路径必须位于 IDM 自有命名空间下
2. 驱动没有校验调用者是否应当有权访问目标键
3. 驱动没有把操作限定到当前用户自己的 HKCU 映射

三道校验缺任何一道都会削弱防护，三道全缺的结果是接口性质发生变化。它不再是一个服务 IDM 自身配置的私有接口，而变成了一个由内核驱动代理执行的、面向任意已认证用户开放的注册表操作原语。

用一句话概括这个错误的性质：把一个内核级的高权限能力包装成了用户可调用的代理，却没有在代理层恢复任何权限判断。 这也是为什么提交记录里的标题用的是 Exposed IOCTL with Insufficient Access Control 这个表述，而非泛泛的”权限检查缺失”。

3.4 请求包与私有编码

四个子命令共用一个输入结构。报告给出的定义如下，此处仅用于说明协议形态：

typedefstructIDMWFP_REG_CMD {    uint8_t  subcmd;        /* 0x0C / 0x0D / 0x0E / 0x0F */    uint8_t  mode;    uint16_t reserved0;    uint32_t flags;         /* bit0 = HKLM, bit1 = HKU */    uint16_t path_offset;    uint16_t path_wchars;    uint16_t data_offset;    uint16_t data_size;    uint16_t value_type;    uint8_t  seed0;    uint8_t  seed1;} IDMWFP_REG_CMD;

从结构字段可以看出攻击者能完全控制的内容：注册表根、相对键路径、值名、值类型、值内容。四项全部来自用户输入，驱动侧只做解码与转发。

PoC 源码里还出现了成对的 encode_value_transport 与 decode_value_transport 函数，用于处理数据字段的字节变换，路径字段则单独走一套 UTF-16 展开逻辑。这说明接口使用的是私有编码而非明文协议。

需要把这一点的安全含义讲清：私有编码提高了构造请求的逆向成本，但它不构成安全边界。编码是公开算法，PoC 已经完整实现并随仓库发布。把不公开的编码格式当作防护手段，在攻击者拿到一份反编译结果之后就不再成立。

3.5 证据边界说明

本节的全部机制描述来自两个来源：PoC 报告对驱动二进制的反编译结论，以及 PoC 在实机上的行为观测。

厂商没有发布任何安全公告，也没有发布补丁，因此不存在可以逐行阅读的补丁差异文件。这一点与闭源内核组件的一贯处境相同，需要在正文与参考章各标注一次，避免读者把反编译推断误当作补丁代码阅读。

四、漏洞触发：六行批处理写完的提权链

4.1 PoC 脚本的六步

PoC 仓库提供一个批处理脚本，把整条链压缩成六个动作。此处按动作意图逐步说明，不逐行复制脚本原文。

| 步骤 | 动作 | 改动前的值 | 改动后的值 | | — | — | — | — | | 1 | 查询目标服务的 ImagePath | %SystemRoot%\system32\svchost.exe -k netsvcs -p | 未改动，仅作记录 | | 2 | 改写 ImagePath | 同上 | 攻击者二进制路径，类型 REG_EXPAND_SZ | | 3 | 改写启动类型 | 0x3（手动） | 0x2（自动） | | 4 | 改写服务类型 | 0x20（共享进程） | 0x10（独立进程） | | 5 | 替换 RequiredPrivileges 列表 | 三项 | 二十八项 | | 6 | 启动该服务 | 未启动 | 调用服务启动命令拉起 |

目标服务是 Windows 内置的 Natural Authentication。第三、四步的改动意图值得单独说明：启动类型从手动改为自动，是为了不依赖人工触发；服务类型从共享进程改为独立进程，是因为载荷是一个独立可执行文件，而不是由 svchost 托管的动态库，服务控制管理器需要按独立进程方式加载它。

第五步是整个链条里最能说明隐患深度的一处。被替换的 RequiredPrivileges 列表包含二十八项特权，其中包括：

• SeTcbPrivilege

  （作为可信计算基础的一部分行动）

• SeDebugPrivilege

  （调试其他进程）

• SeLoadDriverPrivilege

  （加载与卸载设备驱动）

• SeBackupPrivilege

  与 SeRestorePrivilege（备份与还原文件，可绕过 ACL）

• SeImpersonatePrivilege

  与 SeAssignPrimaryTokenPrivilege（模拟与分配令牌）

这一组权限的组合在 Windows 权限体系中处于顶端。换句话说，这条链不但把身份从普通用户换成了 LocalSystem，还顺手给新身份配足了二十八项特权，其中任何一项单独拿出来都足以支撑后续操作。

4.2 为什么挑中这个系统服务

PoC 仓库里附了一份 backup.reg，用于在使用后恢复原始配置。从这份备份文件可以完整读出 Natural Authentication 服务的原始定义，也就能看出选择它的理由。原始定义中的关键字段如下：

| 字段 | 原始值 | | — | — | | ImagePath | %SystemRoot%\system32\svchost.exe -k netsvcs -p | | ObjectName | LocalSystem | | RequiredPrivileges | SeTcbPrivilege、SeChangeNotifyPrivilege、SeSystemEnvironmentPrivilege | | Start | 3（手动） | | Type | 0x20（共享进程） | | DependOnService | RpcSs、ProfSvc、Schedule | | 服务 DLL | %SystemRoot%\System32\NaturalAuth.dll |

这份原始定义里有三个特征同时成立，构成了挑选依据。

一是身份。ObjectName 为 LocalSystem，服务本体以内核级身份运行。二是权限。它的 RequiredPrivileges 里原本就含 SeTcbPrivilege，这一组权限通常只授予 SYSTEM 与极少数系统组件，被借用的服务自带这个起点。三是触发方式。备份文件中存在 TriggerInfo 子键，记录了触发 GUID、触发类型等字段，说明这是一个触发启动型服务，不需要等待系统重启就能被拉起。

backup.reg 这份文件本身也透露了一条信息。它把整棵服务注册表子树完整备份下来，说明 PoC 具备用后恢复原配置的能力。这类”改完再复原”的设计在真实攻击中常用于降低被发现的概率，它不改变漏洞的技术性质，但改变攻击者的时序选择。

4.3 载荷侧的动作

PoC 的载荷是一个标准的 Windows 服务程序：通过 StartServiceCtrlDispatcherA 注册入口，通过 RegisterServiceCtrlHandlerA 注册控制处理器，服务名硬编码为与目标服务相同的名称。这一设计是为了让服务控制管理器在启动它时能够正常握手。

提权成功后的动作是 StartProcessAsSystemInActiveSession，参数为目标程序路径与窗口标题，指向系统目录下的命令解释器。这个调用的作用是把进程从会话 0 拉到当前活动交互会话。

这一步解决的是一个实际问题。服务由服务控制管理器在会话 0 启动，即使身份是 SYSTEM，进程也处在一个没有交互桌面的会话里，用户看不到窗口。要在当前登录会话里拿到可交互的系统级命令行，就需要跨会话启动进程。PoC 仓库里单独提供了 create_process_as_user.hpp 这一文件，篇幅约十五 KB，承担的就是这部分工作。

报告中还提到一段与载荷行为相关的观察：脚本触发后，载荷可能在不同的 Windows 会话中启动，因此即使执行成功，程序窗口也可能不出现在当前交互桌面上。这种情况下仍可在任务管理器里观察进程，例如一个以 SYSTEM 用户运行的命令解释器实例。这句话是报告里对端到端效果唯一的间接描述，它不等价于一张提权成功的截图，这一点在用词上需要区分。

4.4 已动态验证的六项行为

报告第六节列出了作者实际验证过的行为，共六项：0x0D 向测试路径写入 REG_DWORD；0x0C 读回；0x0E 删除该值；0x0F 删除空键；0x0D 写入 REG_EXPAND_SZ；0x0C 读回并正确重建字符串内容。

作者对这六项结果的解释是：接口不是理论上的”可能写入”，而是已经实证可稳定用于通用注册表操作。

需要把验证范围讲准。六项验证覆盖的是注册表操作原语本身，即读写删三类动作都能按预期工作；它不包含端到端拿到系统级命令行的完整记录。 完整链具备工程实现这一点，依据是仓库里的载荷源码与批处理脚本，而非一份提权成功的日志。区分这两者，是因为前者决定了漏洞的定性，后者决定了攻击者在具体环境里的成功率。

4.5 关于是否需要重启

PoC 脚本的末行直接调用服务启动命令拉起目标服务，设计意图是不依赖重启。

这里存在一个公开材料没有说明的环节：普通本地用户是否默认持有该服务的启动权限。CVE 记录与 PoC 报告都没有给出这一项的实测结果，服务安全描述符的原始内容虽然在备份文件里，但报告没有对其做权限解读。

可以确定的替代路径是：脚本第三步已把启动类型写成自动（0x2）。因此如果启动命令被拒绝，已落盘的配置会在系统下次启动时生效，触发目标服务的加载。两条路径最终指向同一个结果，差异只在时间。把”免重启”当作无条件结论是不严谨的，严谨的表述是”脚本尝试立即触发，失败时由自动启动配置在重启后兜底”。

五、补丁分析：没有补丁可分析

5.1 厂商在 PoC 公开后又发了三个版本

这一节没有补丁差异可读，但有一条同样有信息量的时间线。

PoC 仓库的初始提交日期是 2026 年 7 月 15 日，报告、源码与预编译文件在同一次提交里一起公开。此后厂商的发布节奏没有变化：

| 日期 | 版本 | 更新日志要点 | | — | — | — | | 2026-07-22 | 6.43 Build 7 | 修复部分网站不显示下载面板 | | 2026-08-08 | 6.43 Build 8 | 修复部分文件下载 403 错误 | | 2026-08-20 | 6.43 Build 10 | 修复部分文件下载 403 错误 |

三个版本的更新日志都只涉及下载功能。需要把表述的边界写清：从更新日志未提及这一点，只能推出”厂商未公开说明已修复”，不能反推”这三个版本仍然受影响”，也不能推”厂商已修复但选择不公告”。 最新版本当前是否仍存在该缺陷，公开信息未说明，这是本编号最大的开放问题。

5.2 同一产品历史漏洞的形态变化

IDM 历史上有过若干编号，把可检索到的几条按时间排列，可以看出形态的变化：

| 编号 | 年份 | 类型 | 评分 | | — | — | — | — | | CVE-2008-4508 | 2008 | 边界内操作限制不当 | 7.8 | | CVE-2010-0995 | 2010 | 栈缓冲区溢出（FTP URI） | 9.3 | | CVE-2020-23060 | 2021 | 栈缓冲区溢出（导入导出功能） | 7.1 | | CVE-2020-28964 | 2021 | 栈缓冲区溢出（搜索功能） | 6.7 | | CVE-2025-56231 | 2025 | 证书校验缺失（更新保护绕过） | 9.1 | | CVE-2026-90493 | 2026 | 内核驱动访问控制缺失 | 9.3 |

前四条全部是内存破坏类问题，落点在用户态组件。本次是该产品在可检索记录里的第一个内核驱动层面的编号，而且不是内存破坏，是权限逻辑缺陷。

这个转变对防御方的含义是反向的：内存破坏类漏洞需要绕过地址随机化、控制流保护、堆保护等一整套缓解机制，利用难度随系统版本上升；而授权逻辑缺陷不需要绕过任何缓解机制，它只是”本该拒绝的请求被接受了”。从防御角度看，缺陷类型向逻辑层迁移，通常意味着利用门槛下降而不是上升。

5.3 更新通路本身出过问题

前表中 2025 年 11 月的那条编号值得单独看。CVE-2025-56231 的定性是证书校验缺失，描述里明确了后果是允许攻击者绕过更新保护，评分 9.1。

这条编号与本次的关系需要写清：当前厂商没有发布修复，所以它暂时不构成叠加风险，因为没有可投毒的修复包可以下发。但它影响一个判断前提。当”升级到最新版”被当作唯一处置手段时，这条历史记录说明该产品的更新通路曾经出现过校验缺陷，把自动更新当作可信修复渠道需要保留质疑。

5.4 这类问题的标准修复路径

虽然厂商没有发布补丁，这类缺陷的修复方向在 CWE 体系里有明确表述。报告建议的映射是 CWE-862（授权缺失）与 CWE-732（关键资源权限分配不当），CVE 记录实际采纳的是 CWE-266（权限分配不当）与 CWE-284（访问控制不当）。

而 VulDB 提交记录的标题用的是另一个概念：CWE-782，Exposed IOCTL with Insufficient Access Control。这个分类反而没有被写进 CVE 记录的 CWE 字段，但它才是这类问题的专有类别。

CWE-782 的官方描述针对的正是”产品实现了一个本应受限的 IOCTL，却没有正确实施访问控制”这一形态，其描述里特别点出一句与本案高度吻合的话：开发者常常假定 IOCTL 只会被受信任的进程访问，因此对传入数据很少或没有校验，从而暴露了在攻击者无法直接调用该 IOCTL 时根本不可达的弱点。

该条目的官方缓解建议有三处，与本案根因逐项对应：

1. 为设备对象设置正确的安全描述符，限制哪些用户组可以打开设备句柄
2. 在 IOCTL 处理例程内校验调用者身份与特权，而不是依赖调用者的自觉
3. 最小化暴露面，只开放必需的功能，并在访问控制到位的前提下仍然校验全部输入参数

本案在这三处全部缺失：安全描述符给了所有认证用户完全访问权，处理例程不做调用者校验，功能上一口气开放了四个子命令覆盖读写删。用 CWE-782 去描述它比用 CWE-284 更准确，原因是前者直接指向了缺陷的构造方式而非后果。

六、结束语

这个编号在 2026 年的漏洞清单里不算最显眼的一个。没有在野利用报告，没有进 CISA KEV，NVD 状态还停在上游。但它的结构值得留意。

它把缺陷放在了最难修补的位置。设备对象的安全描述符与 IOCTL 处理例程的鉴权逻辑，都在内核驱动里，而这是一个随常规安装落地的闭源组件。用户能做的只有卸载或停用，没有中间档位。

它也把厂商侧的处置空白暴露得很完整。报告在 7 月 15 日公开，源码与二进制一起给出；厂商在一个月内发布了三个版本，更新日志里没有一行相关文字；CVE 记录对厂商的表述是收到披露但未作任何回应。这是公开披露机制在商业闭源软件上的一次典型落空。

对使用者而言，这一类漏洞提醒的是一件更基础的事：装机量本身不是安全信号。一个天天在用的工具，可以同时携带一个对所有本地用户敞开的内核级写注册表能力，而这个能力与它的核心功能并无必要关联。 判断一个组件的风险，看的是它请求了多少权限，而不是它在桌面上看起来多普通。

在厂商给出修复之前，本编号只有降级与隔离两种处置。也唯有把”随包安装的内核组件”纳入资产清点、把服务配置基线纳入持续监控，才能在下一个同类编号出现时提前知道自己的机器是否在范围内。

七、参考

1. CVE 记录 CVE-2026-90493。CNA 为 VulDB，CWE-266 与 CWE-284，四个版本的 CVSS 评分与向量逐项列明。
2. NVD 记录 CVE-2026-90493。来源标识为 [email protected]，vulnStatus 为 Received，configurations 字段为 null，cvssMetricV40 给 8.5。
3. PoC 仓库 IDM_LPE_PoC，作者 KnCRJVirX，初始提交日期 2026-07-15。含 readme.md、report_en.md、report_cn.md、poc.bat、backup.reg、预编译二进制与源码目录 src。
4. PoC 报告正文 report_en.md（13,568 字节）。机制描述、根因分类建议、六项动态验证行为、四条安全建议均出自该文件。
5. PoC 载荷源码 main.cpp 与 create_process_as_user.hpp。服务注册方式与跨会话启动实现出自这两个文件。
6. PoC 注册表操作源码 idmwfp_reg_demo.cpp（29,350 字节）。IOCTL 编号常量、请求包构造与传输编码函数出自该文件。
7. 厂商官方更新页，Tonec Inc. 的 Internet Download Manager news 页。版本序列与各版本更新日志逐条取自该页，页面共记录 376 条版本条目。
8. 驱动文件信息，idmwfp.sys 的产品名 Internet Download Manager WFP Driver 与签名方 Tonec Inc. 出自公开文件信息库条目。
9. 社区实测记录，关于 IDMWFP 服务与本地 127.0.0.1:1001 端点关系的技术讨论帖，用于说明驱动用途。

证实状态说明：厂商未发布安全公告，未发布补丁，因此本文第三节的机制描述来自 PoC 报告对驱动的反编译结论与实机行为观测，不属于补丁代码阅读。第一节中 CVSS 4.0 的两处分值差异，只能从公开字段观察到向量补充项的差异，具体计算口径差异公开信息未说明。最新版本 6.43 Build 10 是否已修复该缺陷，公开信息未说明。PoC 所称 2023 年 11 月之后版本均可使用的说法，报告未列出实测版本清单，属报告方陈述。

https://www.cve.org/CVERecord?id=CVE-2026-90493https://nvd.nist.gov/vuln/detail/CVE-2026-90493https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-90493https://github.com/KnCRJVirX/IDM_LPE_PoChttps://github.com/KnCRJVirX/IDM_LPE_PoC/blob/main/report_en.mdhttps://github.com/KnCRJVirX/IDM_LPE_PoC/blob/main/poc/backup.reghttps://vuldb.com/vuln/403081https://vuldb.com/submit/891910https://www.internetdownloadmanager.com/news.htmlhttps://cwe.mitre.org/data/definitions/782.html

END

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

 提供整洁 – 广告已关

公众号 | AnQuan7 (Ots安全)

---

免责声明：

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

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

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

本文转载自：Ots安全 《被改写的系统服务：IDM 内核驱动 CVE-2026-90493 提权》