CVE-2026-56129: Toshiba's Unpatched Driver Loads on Windows 11

A vulnerability has been found in a driver that ships preinstalled on Toshiba and Dynabook PCs, and it was disclosed on June 25, 2026 through JVN (Japan Vulnerability Notes), Japan's public clearinghouse for vulnerability reports (advisory JVNVU91051826, CVE-2026-56129). The problem is in the "Generic IO & Memory Access driver" (file name QIOMEM.SYS), a component used for low-level control of the machine.

The trouble is that even a non-administrator user may be able to improperly read and rewrite the PC's internal memory. Worse, the vendor has indicated that no fix (update) will be provided. Because there is no patch, the countermeasure is to "remove the affected driver" itself. The settings the driver handled (such as BIOS password operations) are then done from the PC's own startup screen instead.

On the "CVSS" scale, which rates danger from 0 to 10, it is 6.8 under the latest method (4.0) and 5.5 under the older method (3.1) — a medium rating. But Dynabook is widely used in Japanese homes and offices, and because this is not the kind of issue that "fixes itself via update," each user needs to check whether their own PC is affected.

[Update, August 17, 2026] This hole matters even if you do not own a Toshiba PC

Nearly two months on, the point this article failed to get across has become clear. CVE-2026-56129 is not just a story for people using an old Toshiba PC. The driver in question, QIOMEM.SYS, carries a WHQL signature from the Microsoft Windows Hardware Compatibility Publisher — a digital signature showing the file passed Microsoft's compatibility testing, which is what makes Windows accept a driver as legitimate — and it loads fine on Windows 11. The file itself can also be obtained through the Microsoft Update Catalog.

So an attacker does not need to own a single affected Toshiba or Dynabook PC. Get hold of this one file, bring it to any targeted Windows machine, have it loaded, and physical memory on that machine is within reach. The security industry calls this BYOVD (Bring Your Own Vulnerable Driver), which in plain terms means "the attacker brings along a legitimate part that happens to have a hole in it, and uses it". Rather than picking a lock, it is like carrying around one key that opens any house. The first version of this article did use the word BYOVD, but framed it as something for Dynabook owners to watch out for. In fact it concerns everyone and every organization running Windows. We described the same shape in a privilege escalation case involving a PC-lighting app's driver.

On July 10, 2026 the driver was added to LOLDrivers, a public database of legitimate drivers that can be abused, used by defenders as a list of "files that are dangerous if someone brings them in." The entry ID is 6eca187c-8fb2-4eae-9c80-fd9ef9d8c91e, Verified (confirmed exploitable) is TRUE, the technique is classed as MITRE ATT&CK T1068 (Exploitation for Privilege Escalation), and CVE-2026-56129 is linked to it. The listed operating systems are Windows 7 / 8 / 8.1 / 10 / 11.

At the same time, Microsoft's vulnerable driver blocklist — the list of dangerous drivers Windows refuses to load, enabled by default on Windows 11 — does not include it as of August 17, 2026. We checked the 1,713 Deny rules in the policy currently being distributed (VersionEx 10.0.29545.0, XML timestamp April 9, 2026): zero hits for the string qiomem and zero for the SHA256 above. There is a TOSHIBA-related Deny rule in the list (ID_SIGNER_VERISIGN_TOSHIBA), but it targets a different driver, NCHGBIOS2X64, and does not cover QIOMEM.SYS. Turning on HVCI (memory integrity) does not stop this driver from loading today. The reporter said as much in a technical write-up published on May 16, 2026, before the CVE was public: the driver "is not on the Microsoft Vulnerable Driver list and loads fine under HVCI."

On top of that, working proof-of-concept code is public on GitHub. It is described as "Arbitrary physical memory read/write using Toshiba qiomem.sys from ring 3," where ring 3 is the privilege layer ordinary applications run in. It comes in two parts: acpi.exe creates a fake PnP device to get the driver loaded, and main.exe carries out the exploitation.

One more correction. The first version described the damage mainly in terms of "memory contents being stolen," which was only half the picture. The CVSS vector is VC:N/VI:H (C:N/I:H under CVSS 3.1), rating the impact on integrity as High. Sharp's own wording is "arbitrary access to physical memory." Writing is possible, not just reading. Technically, six IOCTLs (0x08012000 through 0x08012014) pass unvalidated 32-bit physical addresses straight to MmMapIoSpace, letting a low-privilege process read and write physical memory below 4 GiB in 1, 2, or 4-byte units. Being able to rewrite data the kernel holds leads directly to privilege escalation and to disabling defensive features.

The vendor's position has not changed. The security notice on dynabook.com is still dated June 19, 2026, with no revision history. The QiomemDeletionTool removal utility is still dated June 19, 2026, Ver. 1.0.2. Parent company Sharp's advisory 2026-003 was published on June 19 and last touched on June 24 (vulnerability description and related information) and June 29 (related information). Dynabook posted security notices on July 15 and August 12 as well, but both are routine monthly announcements with no mention of QIOMEM. Removal remains the only countermeasure. The affected products span 16 series (dynabook AB / AX / AZ / B / BB / BX / EX / MX / N / P / Qosmio / R / S / Satellite / T, and TOSHIBA CL), PCs announced between roughly 2009 and 2016. There has been no announcement adding to or updating that list.

One fact is worth placing alongside this. The same Dynabook, in the Bluetooth ACPI driver vulnerability it disclosed on April 10, 2026 (TOSRFEC.SYS / DRFEC.SYS, affecting PCs announced from 2017 through April 2022), shipped a fixed DRFEC.SYS v11.0.2.3 through both Windows Update and its own site. The same company, two months apart, delivered a patch for one and only removal instructions for the other. "No patch" is not a company-wide policy; it is a specific decision about QIOMEM. The reasoning has not been made public.

Having laid all that out, this deserves equal weight: there are no confirmed cases of this being used in real attacks. We checked all 1,665 entries in the August 14, 2026 edition of the U.S. government's Known Exploited Vulnerabilities (KEV) catalog: zero hits for CVE-2026-56129, Toshiba, or Dynabook. The CISA SSVC assessment shown on NVD also records Exploitation as none. Neither JPCERT/CC nor IPA has issued a standalone alert. The tooling exists, but there is no sign it has been used yet — that is the accurate reading of where things stand. No cause for panic, and no reason to leave it alone either.

What happens, and whose PC is affected

A driver is a translator-like program that sits between the PC's hardware and the software you see on screen. This "Generic IO & Memory Access driver" is something the maker builds in to talk directly to the lower layers of the machine, and users almost never notice it. According to JVN's disclosure, the permission check at the entry point where this driver receives instructions (a window called the IOCTL interface) is insufficient, so even a low-privilege user who should not be able to use it can reach into the PC's physical memory.

Affected are Toshiba and Dynabook PCs that carry this driver. Dynabook is a long-standing, well-known laptop brand in Japan, spread widely from home use to corporate use. Which exact model numbers are affected must be confirmed via the maker's Dynabook support information. [Correction, August 17, 2026] The first version said the U.S. National Vulnerability Database (NVD) did not yet list the details of CVE-2026-56129; it is listed on NVD now. Japan's national database carries it as JVNDB-2026-020742. The affected products span 16 series (dynabook AB / AX / AZ / B / BB / BX / EX / MX / N / P / Qosmio / R / S / Satellite / T, and TOSHIBA CL), PCs announced between roughly 2009 and 2016.

Who targets this flaw, and why

This is not the kind of flaw that gets you taken over suddenly over the internet. An attack requires being able to actually operate the PC and being logged in. So the starting point is someone who can get onto that PC as an ordinary user, or a malicious program (malware) that has already gotten in by some other route. Shared PCs, loaner laptops, or a machine someone once touched or on which a suspicious program was run are the realistic settings.

What the attacker does with this hole is reach into the heart of the PC (its memory) — which normally only an administrator can touch — while remaining a low-privilege user. Memory temporarily holds passwords, encryption keys, and the contents of running programs. Being able to rewrite or read that is a foothold for impersonating an administrator (privilege escalation) and for neutralizing security software. That the driver is properly signed by the maker is convenient for abusers too; bringing in such a "legitimate but flawed driver" is a technique known in the security industry as BYOVD (Bring Your Own Vulnerable Driver), used repeatedly in recent years. We covered a similar issue in a case where a PC-lighting app's driver led to privilege escalation.

The realistic damage is, for individuals, having files and credentials on the device stolen, and — by rewriting data in memory — the device being made into a base for a deeply embedded malicious program. [Correction, August 17, 2026] The impact is not limited to information being siphoned off. As the CVSS rating's High impact on integrity indicates, writing to physical memory is possible too. For a company or organization, a single work laptop can become the entry point for lateral movement that spreads to other devices and servers inside. Even with a medium severity number, the trait that "it does not fix itself, and the hole stays open unless the user takes action" is what makes this one not to be dismissed.

Technically, why memory is reachable

A PC's operating system (OS, such as Windows) separates a privileged layer that can directly touch memory and hardware (the kernel) from the ordinary layer where we use apps, so that mistakes or attacks do not reach the depths. Drivers run in that kernel layer and therefore hold strong privileges. The window that sends instructions from apps to a driver is the IOCTL, and it must check "from whom, and what kind of instruction, will be accepted."

Here that check was insufficient (CWE-782), so the driver accepts even a "read/write physical memory" instruction sent by a low-privilege user. Being able to touch physical memory freely effectively means jumping over the wall the OS set up, which is why the CVSS rating places it as "high impact on integrity (tampering)." The attack needs no advanced skill or special equipment; it works with just a hands-on login, which raises how realistic the abuse is.

Such maker-supplied low-level drivers keep running without users noticing them. Being signed and seemingly legitimate, security software does not immediately suspect them. That is exactly why, in a case like this where the maker has decided to "recommend removal rather than a fix," whether the user notices it exists and takes action is itself the dividing line for safety.

What to do now

The work splits in two depending on where you sit. If you use a Toshiba or Dynabook PC, the answer is removal. If you do not, the answer is keeping the file from being brought in and noticing if it is. The second track was missing from the first version of this article.

1. If you use a Toshiba or Dynabook PC

This time, no fix update will be provided. So the fundamental countermeasure is to remove the affected driver (QIOMEM.SYS). After removal, some of the settings it handled (such as BIOS/Supervisor password setup) can no longer be done through it, but that role can be handled instead from the BIOS setup screen at startup. The vendor distributes a dedicated QiomemDeletionTool (published June 19, 2026, Ver. 1.0.2). For the exact removal steps and whether your model is affected, be sure to check Dynabook's official security notice and the JVN advisory.

Everyday basics help too. Not running software of unknown origin, limiting administrator rights on shared or loaner PCs, and keeping security software up to date all make the attack's prerequisite — "hands-on execution" — less likely. Because the attack needs local operation, the urgency is somewhat lower than for an internet-facing flaw, but since no fix is coming, the hole stays open if left alone.

2. If you run Windows but no Toshiba hardware

Here it is not about deleting a driver from your own PC. It is about stopping one from being brought in. Since Microsoft's vulnerable driver blocklist does not cover this file, blocking it means writing your own rule. Windows offers WDAC / App Control for Business, the mechanism by which an organization explicitly decides which programs and drivers may load. Add a rule denying QIOMEM.SYS by hash or by signer, and the file will not load even if it is brought in. Applying it straight to a production environment can block legitimate business software too, so the safer route is to run in audit mode first and switch to deny once you see what it catches.

On the detection side, take the SHA256 6abd8d0d541bcf9e257c65122216b1d2ae92cbf8a3a3cb7ce340846e66c449ca and MD5 43252ab49c9a43d22aa583c15e96f7b7 from the LOLDrivers entry and add them to your EDR and log-search rules. A file name can be changed; a hash cannot, so a rule that only watches for the file name qiomem.sys will miss it. Recording kernel driver load events and new service registrations helps against this class of technique in general. Blocking QIOMEM.SYS alone leaves plenty of drivers with the same properties, so ingesting the LOLDrivers list on a regular schedule holds up better over time.

In closing

The hole in the driver inside Toshiba and Dynabook PCs is only medium in severity, but in that "it does not fix itself — the user has to remove it" it differs in nature from vulnerabilities solved by an update. The structure of a signed, legitimate driver becoming a stepping stone (BYOVD) is a pattern repeated in recent years, akin to the Secure Boot problem seen across several makers' PCs. First confirm via official information whether your Dynabook is affected, and if so, remove the driver by the prescribed steps. Plain as it is, that is the most reliable defense this time. And as set out in the August 17 update, this driver loads on Windows 11 and is absent from Microsoft's blocklist. Even an organization that owns no Toshiba hardware has reason to remember the file name.

Sources

• ▸ JVN - JVNVU#91051826: Insufficient access control in the Generic IO & Memory Access driver on Toshiba/Dynabook PCs (June 25, 2026)
• ▸ Dynabook - security notice on the Generic IO & Memory Access driver (affected models and steps) (June 19, 2026)
• ▸ NVD - CVE-2026-56129
• ▸ Sharp - Product Security Advisory 2026-003 (published June 19, 2026; updated June 29, 2026)
• ▸ Dynabook - QiomemDeletionTool (removal utility, Ver. 1.0.2)
• ▸ Dynabook - security notice on the Bluetooth ACPI driver (fixed DRFEC.SYS v11.0.2.3 provided) (April 10, 2026)
• ▸ LOLDrivers - qiomem.sys entry (added July 10, 2026; Verified: TRUE)
• ▸ valium007/qiomem - public proof-of-concept code
• ▸ Akshit Yadav - technical write-up on Toshiba qiomem.sys (May 16, 2026)
• ▸ Microsoft - recommended driver block rules (vulnerable driver blocklist)
• ▸ Microsoft - App Control for Business (WDAC)
• ▸ MITRE ATT&CK - T1068 Exploitation for Privilege Escalation
• ▸ JVN iPedia - JVNDB-2026-020742
• ▸ CISA - Known Exploited Vulnerabilities Catalog (KEV)

Revision History