{"slug": "finding-new-drivers-vulnerable-to-cve-2024-26507", "title": "Finding new drivers vulnerable to CVE-2024-26507", "summary": "A security researcher built drvscan, a Python static analyzer for Windows kernel drivers that scores them for the dangerous primitives that enable bring-your-own-vulnerable-driver (BYOVD) attacks, and used it to find additional signed AIDA64 builds vulnerable to CVE-2024-26507. The tool flagged AIDA64's kerneld.x64 driver (shipped as aida64x.sys and aida64.sys) for creating an unauthenticated \\Device\\AIDA64Driver device object and exposing IOCTLs that perform arbitrary physical memory read/write, and the newly identified builds were added to the existing NVD record. The researcher disclosed the tooling, proof of concept, and reports publicly, with the repository listed among the CVE's NVD references.", "body_md": "**Disclaimer**\n\nI disclosed all of this publicly: the tooling, the proof of concept, and the reports. The NVD entry for CVE-2024-26507 now lists this repository ([PaulDotSH/vuln-driver-aida64](https://github.com/PaulDotSH/vuln-driver-aida64)) among its references. Some of the code and text was AI-assisted. I verified every finding, hash, IOCTL, and code path on a real Windows machine.\n\nI did not report the original CVE. Another researcher found the AIDA64 kernel driver issue in early 2024 and got CVE-2024-26507 assigned (advisory at `belong2yourself.github.io`, PoC at [klezVirus/AIDA64Driver-EoP](https://github.com/klezVirus/AIDA64Driver-EoP)). My work was to find additional vulnerable builds and versions that nobody had covered, verify them, and get them added to the existing record.\n\n**At a glance**\n\n| **CVE** | [CVE-2024-26507](https://nvd.nist.gov/vuln/detail/CVE-2024-26507) | \n| **Class** | Local privilege escalation via arbitrary physical memory R/W | \n| **Weakness** | CWE-1286 | \n| **CVSS 3.1** | 7.8 (High) | \n| **Vendor** | FinalWire (AIDA64) | \n\nKernel exploit kits almost never are from a fresh kernel bug. They ship a signed driver that already does what the attacker wants, usually arbitrary physical or kernel memory read and write, and that an unprivileged process can drive with no check in between. A real vendor signed the driver, so it loads on a stock Windows box with Driver Signature Enforcement on. The attacker brings the driver and the kernel supplies the escalation.\n\nThe question I cared about was not whether I could write an exploit. It was which signed drivers have a dangerous primitive accessible by a normal user. That is a search problem, so I automated it.\n\nOne detail matters here. A CVE pins one version range, not every build. Vendors keep shipping the same flawed driver across releases, each signed with a fresh timestamp and a new hash. Enumerating those builds is useful work on its own, and it is what I ended up doing.\n\nI have written a static analyzer in Python (**drvscan**) for Windows kernel drivers. It scores drivers against the pattern that makes BYOVD work, then I have a more detailed look at the found driver.\n\n`drvscan` parses the PE headers, and has some weights based on the found signals. We also check if a device is created, since we only care for user mode reachability. We also count memory mapping, section mapping and others.\n\nI have implemented a scraper for multiple web sources which I won't name, where I get the drivers from. The analysis is done on the downloaded drivers.\n\nAIDA64 is FinalWire's system information and diagnostics utility. Its kernel component, `kerneld.x64`, ships as `aida64x.sys` with a second build as `aida64.sys`. FinalWire signs both and they load on stock Windows, including builds I pulled from current vendor packages. The triage report for the second build:\n\n*Output from my custom tool:*\n\n`eba3233869c744271d5c22e4c1011ce866987d444a00bb78e4089637b7ed794b`\n`physical_memory`, `mdl_mapping`, `exposes_device`\n`\\Device\\AIDA64Driver`, `\\DosDevices\\AIDA64Driver`\n`e:\\work\\visualc\\llkd\\driver.nt\\amd64\\LLKD.pdb`\nWe see by these findings together a driver that creates a device object, maps physical memory, maps MDLs, and imports no access check.\n\nThe original 2024 report already described that shape. What I found was that the same defect sits in additional signed builds and versions, including ones in current 8.x AIDA64 packages, none of which were in the known-vulnerable record for the family.\n\nThe device object is the pivot. The driver creates `\\Device\\AIDA64Driver` from `DriverEntry` with no ACL, so any process can open it:\n\n```\nHANDLE h = CreateFileA(\"\\\\\\\\.\\\\AIDA64Driver\",\n                       GENERIC_READ | GENERIC_WRITE,\n                       FILE_SHARE_READ | FILE_SHARE_WRITE,\n                       NULL, OPEN_EXISTING, 0, NULL);\n```\n\nThe driver then exposes IOCTLs that take a caller-supplied physical address and size and pass them through with no validation:\n\n| IOCTL | Effect | \n|---|---|\n| `0x80112074` | read 4 bytes at physical `(hi<<32)\\ | \n| {% raw %} `0x80112078` | write 4 bytes to physical `(hi<<32)\\ | \n| {% raw %} `0x80112040` | `memcpy(dest_va, MmMapIoSpace(phys, size), size)` for a bulk physical read | \n| `0x8011204c` /`0x80112084` | `rdmsr` /`wrmsr` | \n| *other* | raw port I/O and PCI configuration-space read and write | \n\nThe bulk path is the standard kernel-to-user mapping chain. The handler reads the address and length from `IRP->SystemBuffer` and calls `MmMapIoSpace`, `IoAllocateMdl`, `MmBuildMdlForNonPagedPool`, and `MmMapLockedPagesSpecifyCache` in sequence, mapping the result into the caller's address space.\n\nAn unprivileged caller ends up with arbitrary physical memory read and write. With the token-stealing technique that h0mbre and Ruben Boonen have both written up, that is enough to reach `NT AUTHORITY\\SYSTEM` without a memory-safety bug.\n\n[aida64_rw.c](https://github.com/PaulDotSH/vuln-driver-aida64/blob/main/aida64_rw.c) is built to prove it with a round trip instead of exposing a poke-any-address tool:\n\n`VirtualAlloc` a large buffer, fill it with a 16-byte marker, and `VirtualLock` it so it stays resident.\nIf the driver were not mapping real physical memory, the round trip would fail. It does not. I left the step from arbitrary physical read and write to kernel code execution or an EDR kill out of the PoC and this post. The point is to document the defect for the advisory process, not to ship a weapon.\n\nTo measure how usable the primitive is, I wrote a memflow connector, `memflow-aida64`, over the two METHOD_BUFFERED IOCTLs. It presents the driver as a memflow `PhysicalMemory` backend, so any memflow OS layer can run on top of it, which is full virtual memory access to the running OS from an unprivileged process. `memflow-bench` compares it against a raw IOCTL backend on per-call latency and on bulk throughput up to 4 MB.\n\nI am not publishing the connector. Same reason as the PoC: defenders need to know the driver is dangerous, not to be handed a kernel memory access tool.\n\nEverything is public.\n\n`belong2yourself.github.io`, PoC at The binaries I reported:\n\n| File | SHA-256 | Size | \n|---|---|---|\n| `aida64.sys` | `27375351b4a723465f937866f0ffc86e8e612b093673ee25ccf0b7ea803f888f` | 34,648 bytes | \n| `aida64x.sys` (`kerneld.x64` ) | `eba3233869c744271d5c22e4c1011ce866987d444a00bb78e4089637b7ed794b` | 68,376 bytes | \n\nThe \"lesson\" here is not that I found a bug. Someone else found it and got the CVE. The lesson is that a CVE entry does not enumerate every affected build. The same signed physical-memory primitive kept shipping, and the original record did not cover it.\n\nFor anyone auditing: signing does not make a driver safe, and a diagnostics utility that maps physical memory for hardware information is one IOCTL away from local privilege escalation. Keep scanning after a CVE lands, because the fixed version in the record can be narrower than the vulnerable reality.", "url": "https://wpnews.pro/news/finding-new-drivers-vulnerable-to-cve-2024-26507", "canonical_source": "https://dev.to/nullptr/finding-new-drivers-vulnerable-to-cve-2024-26507-5c1k", "published_at": "2026-10-10 17:10:05+00:00", "updated_at": "2026-10-10 17:18:53.387055+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents"], "entities": ["CVE-2024-26507", "AIDA64", "FinalWire", "drvscan", "NVD", "PaulDotSH", "klezVirus", "Windows"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/finding-new-drivers-vulnerable-to-cve-2024-26507", "markdown": "https://wpnews.pro/news/finding-new-drivers-vulnerable-to-cve-2024-26507.md", "text": "https://wpnews.pro/news/finding-new-drivers-vulnerable-to-cve-2024-26507.txt", "jsonld": "https://wpnews.pro/news/finding-new-drivers-vulnerable-to-cve-2024-26507.jsonld"}}