Acer, Toshiba and More: A Secure Boot Hole That Never Gets Revoked

Small programs signed and distributed by several PC makers—Acer, GIGABYTE, Toshiba Corporation and others—were found to contain a weakness that lets attackers slip past "Secure Boot," the safety check that runs when your computer starts up. It was published in June 2026 by Japan's national vulnerability portal JVN (JVNVU#93024090) and the U.S. CERT/CC note (VU#457458).

We published this article on June 19, 2026. Two months on, we went back through the primary sources and found three errors in what we originally wrote. One of them goes to the article's conclusion. We apologize and correct them below.

Here is our conclusion two months after disclosure, up front. Under the mechanisms in use today, this case has no path to being closed. There is a system called DBX for registering software found dangerous as "no longer trusted," yet none of the 12 binaries are on it. Microsoft itself has publicly acknowledged why they cannot easily be added. What users can realistically do is set a BIOS administrator password and disable booting from external devices such as USB drives. Not firmware updates, not DBX updates—those two settings are what actually work.

We opened the revocation list and counted

JVN issued its advisory on June 19, 2026. So did the affected software make it onto the revocation list that shuts dangerous binaries out? Microsoft publishes the master copy of that list in a GitHub repository called secureboot_objects. Anyone can open it and read it. We opened it and counted.

The method is simple. We took all 673 entries in the distributed dbx_info_msft_latest.json (443 for x64, 94 for ia32, 26 for aarch64, 110 for arm) and compared them against the hashes CERT/CC lists for the 12 binaries (12 Authenticode SHA1 values and 10 SHA256 values, 22 in total).

There were zero matches. Beyond the hashes, we also looked at the 57 distinct company-name fields in the list: Acer, ASUS, Toshiba, GIGABYTE, Getac, ECS and Uniwill do not appear once. Two months after the advisory, not a single binary in this case has been revoked.

Only 13 entries have been added to the revocation list in all of 2026:

The "revocation shipped in the June 9, 2026 monthly update" you may see reported is a different case. That was the response to VU#616257 (CVE-2026-8863), a shim vulnerability—not to VU#457458. Our original article failed to keep the two apart.

Why they don't get added

The question "why isn't something publicly declared dangerous on the list?" has an answer from Microsoft itself. In GitHub Issue #447 (opened July 10, 2026, since closed), the company acknowledged that the revocation list has hit its limits.

In plain terms: the revocation list is designed to be shipped to every device on earth with identical contents. There is no facility to send each machine only the portion relevant to it. Meanwhile, the place the list is posted is a small block of non-volatile memory inside the PC (NVRAM, the settings area that retains its contents with the power off), and its size is fixed per model. The notices keep piling up, while the board they are pinned to was sized once and cannot be widened. The current volume—443 entries for x64 alone—has reached the point of squeezing that space.

The issue states that even on a ThinkPad, an officially supported Windows 11 machine, updating the Secure Boot variables fails. This is not a story about ancient hardware. The same problem shows up with fwupd (the mechanism for updating firmware and DBX on Linux), where DBX updates are reported failing with "Not enough efivarfs space."

Content is already being cut to fit. 154 hashes related to the BlackLotus bootkit are marked "isOptional" and dropped from the distributed objects. That isOptional treatment is not officially documented anywhere. They were not left out because they were judged safe; they were left out because there was no room.

So behind this case's absence from the revocation list sits a structural fact: things known to be dangerous cannot be revoked, because there is no space. DBX is not an endlessly extensible register. It is a nearly full notice board, and pinning something new means deciding what not to pin.

Who signed it decides whether it gets fixed

Capacity alone does not explain it, because 11 shim binaries were added to the revocation list on April 9, 2026. And that shim case (VU#616257 / CVE-2026-8863) was reported by Martin Smolár of ESET—the same researcher who reported this one. Same researcher, same period, same category of Secure Boot bypass: one set was revoked, the other was not.

The difference is who signed.

Shim is signed by Microsoft's CA (the certificate authority that issues the signatures). Microsoft can therefore withdraw its own seal of approval on its own judgment—the counterparty in that process is itself. The 12 binaries in this case, by contrast, are signed with each maker's own certificate: Acer, Toshiba, GIGABYTE and the rest. They are not Microsoft's seal, so Microsoft is not in a position to withdraw them. The party who can is the maker who signed. And as covered below, most of those makers never replied to CERT/CC.

Identical flaws split into the ones that get fixed and the ones that don't, depending on who signed them. That is the heart of this case. Secure Boot rests on the trust that "anything with a maker's signature may pass," but the procedure for withdrawing that trust exists only on the side that issued the signature. Signatures from a party with no intent—or no process—to withdraw them stay valid even after being declared dangerous.

What is Secure Boot, and why is a bypass scary?

Secure Boot is a mechanism that, in the window between powering on the PC and the OS (such as Windows) starting, "only runs software signed (vouched for) by a legitimate maker." If an unknown program tries to cut in along the way, it won't run without a signature—preventing malware from lodging itself in the boot foundation. It is enabled out of the box on most Windows PCs.

Malware that lodges in this foundation is called a bootkit, and it is especially nasty. Because it runs before the OS, it is hard to see from antivirus software running inside Windows, and it survives an OS reinstall or a reboot. Secure Boot is precisely the gatekeeper meant to shut bootkits out. The weakness found here is one that lets attackers slip past that gatekeeper.

The problem lies in the gatekeeper's rule of "let it through as long as it has a maker's signature." Here, some of the legitimate software the makers themselves signed and distributed (small programs used for maintenance and booting) allowed dangerous operations. In other words, an attacker doesn't need to build new malicious software—they can simply abuse already-vouched-for legitimate software to get through the gate. The pattern of a signed, legitimate part becoming the hole echoes the case we covered where an official image shipped with a default password left active.

The register on the withdrawal side is called DBX. Where db is the list of things to trust, dbx is the list of things to trust no longer. The gatekeeper checks each arrival against both lists before deciding to let it in. What is happening in this case is that a face declared dangerous still has not been added to the "do not admit" list.

Who comes to pry this gate open, and what do they leave behind?

This weakness is not the kind anyone can trip over remotely in one shot. It only works once an attacker has seized administrator privileges or can physically handle the PC. That is exactly why it is worth picturing who is already one step away, and what they leave behind once the gate is pried open.

Those who come are attackers who already broke in with other malware and grabbed admin rights, state-backed espionage crews that want to watch a company's machines for the long haul, people who can physically touch someone else's device under the guise of repair or resale, and thieves analyzing a stolen laptop. What they leave beyond this gate is resident malware that survives an OS reinstall, an eavesdropping rig that watches keystrokes and passwords, a back door for remote control at any time, and a squatter on the foundation that disables antivirus monitoring from the very start. The moment the gate is bypassed, that device turns into "a PC that won't come clean even after a factory reset."

Technically, the attacker scouts which maker built the target device, then loads that maker's signed but vulnerable software through the normal procedure. Because it is signed, Secure Boot does not stop it. Using the dangerous operations that software provides as a stepping stone, they write an unsigned program (the very bootkit the gatekeeper should have rejected) into the boot foundation. Once it squats there, it seizes control before the OS, so it can monitor and tamper from beneath every defense running above. It is favored for long-term targeted espionage and for cementing a foothold after a ransomware crew's initial break-in; the playbooks of such groups are organized in our rundown of major hacker and ransomware groups.

There is, however, a second condition. The vulnerable software only loads on a machine that trusts the certificate it was signed with. OEM certificates are generally present only on machines that OEM itself built. Carry a binary signed with Acer's certificate to a PC that has no Acer certificate, and the gatekeeper does not recognize the signature and refuses it. That is why this is not a case of "every PC is equally at risk."

What actually happens with JVNVU#93024090

The weakness is that some "UEFI applications"—small programs the makers signed and distributed (shells and bootloaders that run before the OS)—left dangerous operations usable as-is. According to the CERT/CC note, the functionality at issue is the UEFI shell's mm (direct memory rewriting) and dmpstore / setvar (reading and writing the NVRAM boot-time settings area). A UEFI shell is a minimal command environment available before the OS starts, intended for maintenance and testing.

This is an "abuse a tool that opens with a legitimate key" type of attack, requiring no new malicious software to be brought in. The attacker passes the maker-signed legitimate software through Secure Boot by the normal procedure, then uses the dangerous commands inside it to write an unsigned program into the boot foundation. As a result, a bootkit that should have been rejected gets to start by borrowing the maker's seal of approval. Because control is seized before the OS comes up, detection by antivirus software inside Windows becomes difficult.

There are conditions for it to work: the attacker must already hold administrator privileges or be able to operate the device physically, and the machine must trust the certificate that signed the binary. Someone doing nothing is not suddenly taken over from across the network. Even so, seizing admin rights with other malware is not unusual, and for an attacker who has reached that stage, this is a way to build a form of persistence that is hard to detect or remove. As of August 17, 2026, no report of this being exploited in the wild has been confirmed.

The reporter is Martin Smolár of ESET, who reported to CERT/CC on February 16, 2026. No individual CVE numbers were assigned; the case is handled collectively under the CERT/CC and JVN tracking IDs.

Is my computer affected?

Whether you are affected depends on who signed the vulnerable binary and whether that signer's certificate is present on your machine. The breakdown of the 12 binaries CERT/CC lists is below. Our original article lumped this together as "Acer, ASUS, GIGABYTE, Toshiba and others," but the actual signers are more granular, and some are OEM lines that never reach the general market.

The single entry bearing the ASUS name is "ASUS schenker-tech.de(XMG)," a signature for the German XMG / Schenker OEM line. It is not the ASUS PCs sold at retail. ASUSTeK Computer Inc. itself answered "Not Affected" in the CERT/CC vendor list. Our original article saw that name and counted ASUS among the affected. We correct that here.

Likewise, "Toshiba" is the Toshiba Corporation name, not Dynabook Inc. In Japan, "a Toshiba PC" reads as "a dynabook," but these are two different companies. Dynabook's support site makes no mention of this case. (The notice Dynabook issued on February 17, 2026 about Secure Boot certificate expiry is a separate matter.) We covered a driver vulnerability affecting dynabook PCs in a separate article.

Vendor responses are below. Only one company, GIGABYTE, acknowledged being affected; most of the signers never replied.

Even so, there is no need to panic

"No path to being closed" may sound alarming, but the risk picture is calm. Here is why.

First, the preconditions are heavy. The attacker must already have seized administrator privileges or be able to operate the device directly. Anyone at that point can do a great deal even without this vulnerability. On top of that, it only works on a machine that trusts the signer's certificate. Because OEM certificates are generally present only on that OEM's own machines, a binary signed for the XMG line cannot be pushed through on another vendor's PC.

Second, the exploitation record. No report of real-world exploitation has been confirmed. ESET, CERT/CC and Microsoft all stay silent on in-the-wild abuse. We also checked the KEV catalog, the U.S. CISA list of vulnerabilities known to be under attack. Against the August 14, 2026 edition of 1,665 entries, none of the keywords UEFI, Secure Boot, bootkit, shim, GRUB or BlackLotus produced a hit. Even CVE-2023-24932, the well-known BlackLotus bootkit flaw, is not in KEV. How to read KEV is covered in this article.

There is also EPSS, which estimates the likelihood of exploitation mechanically. This case has no individual CVE and therefore no score, but the separate shim flaw from the same researcher (CVE-2026-8863) sits at 0.00110—the bottom 1.5% overall. That is supporting evidence that this class of flaw is not something broadly and automatically hunted.

How bad it is when something squats in the boot foundation, and how likely you are to be hit right now, are two different questions. Here the first is heavy and the second is low—that is the fair reading.

How should I respond?

Our original article said "close the hole with firmware updates and DBX updates." The first is up to each maker; the second, as shown above, does not function for this case. Here is an honest rewrite of what can actually be done, in order.

1. Apply Windows Update. Not for this case, though. It is for the Secure Boot certificate expiry work coming in 2026, and for pulling in the revocation of the separate shim flaw—both of which did ship, in the April and June updates. Microsoft's guidance on Secure Boot certificate and CA updates lays out the background. Be precise about the limit: these hashes are not included, so applying the update does not close this hole.

2. If you use GIGABYTE products. This is the one vendor that answered "Affected." Its response, however, is not a firmware update. GIGABYTE removed the signed UEFI shell from its BIOS update packages and deleted the old distributions from its servers. If you still have a downloaded BIOS_flash_tool.zip or old BIOS ZIP files on your machine, delete them and use only distributions dated June 12, 2026 or later. The files sitting on your disk are still the dangerous ones, which is why deleting them matters. GIGABYTE also recommends setting a BIOS administrator password and disabling boot from external devices.

3. A BIOS password and disabled USB boot. This is what works best. The attack presumes physical access or admin rights. Put an administrator password on the BIOS (UEFI) setup screen and disable booting from USB sticks and external drives, and you close off the very route by which a vulnerable binary would be brought in and run. Shutting the door beats waiting for a revocation that may never come. On corporate machines, disk encryption (BitLocker and the like) and tightening administrator rights point the same direction.

4. Acer, Toshiba Corporation and the rest: status unknown. They did not respond to CERT/CC and remain listed as "Unknown." All you can do is check each company's support page for updates or security notices covering your model. If there are none, item 3 above is the realistic defense.

How to check your own machine

On Windows, these three commands in an administrator PowerShell show you the state:

The first tells you whether Secure Boot is on; the second lists the certificates your machine trusts (db); the third lists what it refuses to trust (dbx). -Decoded renders the contents in human-readable form and was added in KB5093574 (April 28, 2026)—it is unavailable on earlier builds. Details are in the Get-SecureBootUEFI documentation.

Now the honest part. Because this case's hashes are not on the revocation list, there is currently no way for these commands to show you as "protected against this." The dbx output from the third command does not contain the 12 binaries. What you can learn is what the second command shows: which makers' certificates your PC trusts. If an Acer or Toshiba certificate is in there, binaries signed by that maker will pass on your machine.

If you have Secure Boot turned off, the revocation list is not evaluated at all. But since this vulnerability is about bypassing Secure Boot, turning it off already left you unprotected. If you are concerned, the place to start is turning it back on.

Why does signed, legitimate software become the hole?

Secure Boot's safety rests on the premise that "signed legitimate software is safe." But when that legitimate software itself permits dangerous operations, an attacker can pass the gate by using a vouched-for part as a stepping stone, without building new malware. As here, when a maintenance UEFI shell still carries commands that write memory and NVRAM directly, that becomes a "lawful detour" straight through.

This pattern of "if any one link in the chain of trust breaks, the whole thing breaks" is a recurring theme in recent security. What this case adds is something else: the means to withdraw a broken link exists only on the side that issued the signature. A signature with no party to withdraw it stays valid after publication. Combine that with a revocation list running out of room, and the pile of "known dangerous but never listed" keeps growing.

Watching only JVN leaves you with stale information

A practical note from reporting this out. The Japanese-language JVNVU#93024090 was published on June 19, 2026, and its last-updated date is still June 19. There is no revision history. The content is a pointer to CERT/CC; affected products and countermeasures are not written on JVN at all.

The upstream CERT/CC VU#457458, meanwhile, was revised to Revision 2 on June 23, 2026. Watching JVN alone, you would never notice. No standalone JPCERT/CC alert and no IPA "important security information" entry has been confirmed either. Domestic coverage amounts to a single ScanNetSecurity piece from June 22, 2026, which introduces the JVN entry.

JVN is a translation-and-forwarding desk, not the primary source. When you track a case that matters to you, follow the link from the JVN page to the upstream note (CERT/CC or the vendor advisory) and check the revision number and date. As here, the upstream copy may be the only one that moved.

Frequently asked questions

Q. I use an ASUS PC. Am I at risk?

A. No. ASUSTeK Computer Inc. answered "Not Affected" in the CERT/CC list. Of the 12 affected binaries, the only one carrying the ASUS name is "ASUS schenker-tech.de(XMG)," a signature for the German XMG / Schenker OEM line. When first published, this article counted ASUS among the affected based on that signature name. That was wrong, and we correct it here.

Q. It says "Toshiba." Are dynabook PCs affected?

A. The affected binary is signed under the Toshiba Corporation name, not by Dynabook Inc., the company that runs the PC business in Japan. Dynabook's support site makes no mention of this case. The notice Dynabook issued on February 17, 2026 about Secure Boot certificate expiry is a separate matter.

Q. Will Windows Update fix it?

A. Not for this case. The 12 binaries are not registered in DBX, the revocation list that shuts dangerous software out. Applying Windows Update is still worth doing, but for the certificate expiry work and for the separate shim revocation. Against this case, the realistic defenses are a BIOS administrator password and disabling boot from external devices.

Q. Can I be suddenly taken over just by browsing the web?

A. No. This weakness requires the attacker to first hold admin rights or be able to operate the device directly, and it only works on a machine that trusts the signer's certificate. Someone doing nothing is not taken over in one shot from across the network. No report of real-world exploitation has been confirmed.

Q. I'm worried a bootkit may already be planted.

A. It is difficult for an ordinary user to confirm reliably on their own. If behavior is suspicious and you are concerned, consult the maker or a specialist. For businesses, managing device procurement and disposal, disk encryption, and tightening admin rights are effective prevention.

Summary

JVNVU#93024090 is a case where 12 UEFI apps signed and distributed by Acer, GIGABYTE, Toshiba Corporation and others were found to have a weakness that lets attackers slip past Secure Boot, the startup safety check. ASUS, which this article originally listed among the affected, in fact answered "Not Affected"; the single ASUS-named entry is a signature for the XMG / Schenker OEM line. We correct that here.

What two months have brought into view is less the size of the damage than the dead end on the repair side. None of these hashes are in Microsoft's revocation list, and Microsoft itself has acknowledged that the list is at its capacity limit. The 11 shim binaries reported by the same researcher were revoked in April. The difference is not in the flaw but in whether the signature came from Microsoft's certificate authority or from each maker's own certificate. Who signed it decides whether it gets fixed.

What users can do is clear. Apply Windows Update (not for this case, but there are reasons to apply it). GIGABYTE users: delete the old BIOS distributions sitting on your disk. And what helps everyone is a BIOS administrator password plus disabling boot from external devices. Against an attack that presumes physical access, closing the physical entrance is what works. No exploitation has been reported, and it is not in KEV. There is no need to panic.

Revision History

Sources

• ▸ JVN - JVNVU#93024090 Secure Boot bypass in vendor-signed UEFI applications (published June 19, 2026; last updated the same day)
• ▸ CERT/CC - VU#457458 (Revision 2, June 23, 2026)
• ▸ Microsoft - secureboot_objects (the repository publishing the revocation list)
• ▸ Microsoft - dbx_info_msft_latest.json (all 673 entries)
• ▸ Microsoft - secureboot_objects Issue #447 (DBX capacity, opened July 10, 2026)
• ▸ CERT/CC - VU#616257 (shim / CVE-2026-8863; the separate case added to DBX on April 9, 2026)
• ▸ Microsoft - Windows Secure Boot certificate and CA updates
• ▸ CISA - Known Exploited Vulnerabilities Catalog (checked against the August 14, 2026 edition, 1,665 entries)
• ▸ ScanNetSecurity - Secure Boot bypass in UEFI applications signed by multiple vendors (June 22, 2026, in Japanese)