A public proof of concept turns Internet Download Manager’s own kernel driver into an arbitrary registry-write primitive for any logged-in user, and the vendor — by the CVE record’s account — has not responded.
What happened
On September 13, 2026, NVD published CVE-2026-90493, a local privilege-escalation flaw in Tonec’s Internet Download Manager (IDM) affecting versions up to and including 6.42 Build 63, the current release, on Windows. The flaw is in idmwfp.sys, the kernel-mode filter driver IDM installs to intercept browser downloads. VulnCheck’s counterpart, the vuldb CNA that assigned the ID, scores it CVSS 3.1 8.8 (High) and CVSS 4.0 8.5 (High), classified CWE-266 (improper privilege management) and CWE-284 (improper access control).
The record is blunt about status. In NVD’s words: “The exploit is now public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.” There is a working proof of concept published on GitHub, there is no patch, and there is — on the record as it stands — no acknowledgment from Tonec.
The mechanism
The problem is an access-control failure at the driver’s front door. According to the researcher’s writeup accompanying the proof of concept, idmwfp.sys exposes a device object, \\.\IDMWFP, to all authenticated users with GENERIC_ALL access. Any account that can log in can open the driver and issue commands to it. That is the whole vulnerability class in one line: a kernel driver that should be reachable only by IDM’s own privileged components is instead reachable by every user on the machine.
What the driver then does with those commands is the escalation. Through IOCTL 0x12C028 and its subcommands 0x0C through 0x0F, the writeup states, a caller can “Read values, Create or modify values, Delete values, Delete empty keys” against arbitrary registry paths in both the HKLM and HKU hives, with no authorization check on the path. Because the operation runs in kernel context, the usual permission on a registry key — the thing that would stop a standard user from touching a machine-wide setting — does not apply. A low-privileged user gets a general-purpose registry read/write/delete primitive over the entire system.
Arbitrary registry write on HKLM is a well-worn road to SYSTEM. The writeup points at the obvious target, HKLM\SYSTEM\CurrentControlSet\Services\, and states the consequence plainly: “Once a low-privileged user can modify registry entries trusted by a high-privilege service or driver, attacker-controlled paths, parameters, or DLL references can be inserted into a privileged execution chain.” Rewrite a service’s ImagePath, or point a driver at an attacker-controlled DLL, and the next start runs attacker code as SYSTEM. The immediate primitive is registry write; the practical outcome is full local privilege escalation.
The proof of concept is packaged to run with no reverse engineering required. The repository ships the IDM installer alongside the exploit and instructs the operator to install IDM normally and then run poc.bat. Its README states that “Versions released after November 2023 can use this PoC directly.” This is not a sketch that a skilled attacker would need to finish; it is a button.
Why it matters
Internet Download Manager is a consumer product, and it is easy to wave off a consumer download manager as not an enterprise concern. That instinct is wrong here for two reasons. First, IDM is installed on a great many corporate endpoints — put there by users, browser-integrated, and rarely inventoried — and its driver loads at boot whether or not the application is running. The vulnerable component is not the app the user sees; it is a kernel driver sitting on the machine. Second, the bug is exactly the kind that matters to a defender even though it is “only” local. Privilege escalation is the second step of most intrusions: an attacker who lands as a standard user through phishing or a browser exploit needs a way up, and a public, one-command SYSTEM primitive on any endpoint with IDM installed is precisely that way. It converts a foothold into full control of the host without touching a patchable Microsoft component.
The driver access-control mistake is also a recurring one, and worth recognizing as a pattern rather than a one-off. A vendor ships a kernel driver to do something legitimate — here, filtering network traffic to catch downloads — and secures the driver’s own logic while leaving the device object open to everyone. The security boundary was never the IOCTL handler; it was the ACL on \\.\IDMWFP, and that ACL granted the world GENERIC_ALL. Third-party kernel drivers are a standing supply of these primitives, which is why Microsoft maintains a vulnerable-driver blocklist at all. This one is not on that list.
The hardest part of this story is that there is no fix to point to. When a vendor patches, the reader’s job is to deploy the patch. When a vendor does not respond, the reader is left to mitigate a live, publicly-exploitable flaw in software their users installed voluntarily — and the only reliable mitigation is removing the software or blocking its driver, which breaks the feature the users wanted. That is a genuinely uncomfortable position, and pretending otherwise does not help.
What to do
There is no vendor patch as of this writing. Treat this as a mitigation problem, not a patching one.
- Inventory. Find endpoints with IDM installed and, more precisely, with
idmwfp.syspresent and loaded. The driver is the vulnerable component; the application being closed does not remove it. - Remove where you can. On managed fleets, the cleanest mitigation is uninstalling IDM, which removes the driver. Where the download manager is genuinely needed, weigh that need against a public local-SYSTEM primitive.
- Block the driver. If removal is not immediately possible, consider blocking
idmwfp.sysfrom loading via Windows Defender Application Control or your endpoint tooling. This will break IDM’s download interception. - Monitor. Watch for non-administrative processes opening
\\.\IDMWFP, and for writes toHKLM\SYSTEM\CurrentControlSet\Services\keys originating from unprivileged contexts. Those are the two observable steps of this exploit.
Track the CVE record for a vendor response; a fixed build would need to tighten the device object’s ACL so that only IDM’s privileged components can open it.
Sourcing note
The CVE identifier, affected version, CVSS scores, CWE classifications, and the “exploit is now public / vendor did not respond” language are from NVD’s record for CVE-2026-90493, published September 13, 2026, 3:16 a.m. UTC, which republishes the vuldb CNA’s assessment. The technical mechanism — the \\.\IDMWFP device object exposed with GENERIC_ALL to authenticated users, IOCTL 0x12C028 subcommands 0x0C–0x0F, the arbitrary registry operations, and the service-key escalation path — is from the proof-of-concept author’s own writeup published with the exploit code, quoted above. We read that writeup and confirmed the repository ships runnable exploit code and the IDM installer; we did not detonate the exploit. This is single-sourced: the CNA is vuldb and the technical detail comes from one researcher’s public PoC. There is no second independent advisory, no vendor confirmation, and no reported in-the-wild exploitation — the concern is a public, low-effort exploit against unpatched software, not an active campaign. We could not reach cisa.gov’s KEV catalog directly (it returns 403 to automated fetching); the flaw is not in the KEV catalog as mirrored on GitHub as of this run.