Acer, ASUS, Toshiba and More: Secure Boot Bypass Risks a Malware That Won't Wipe (JVNVU#93024090)

Software signed and distributed by several PC makers—Acer, ASUS, GIGABYTE, Toshiba and others—was 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).

If abused, an attacker can plant malware deep in the foundation of the machine (the boot layer)—the kind that survives an OS reinstall and is hard for antivirus software to spot. The catch is that the attack first requires either administrator privileges or hands-on access to the device. The remedy is the firmware updates PC makers distribute, plus updating the "DBX" revocation list that disables the dangerous software.

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.

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.

The condition of "needs admin rights or physical access" looks like a high bar at first glance. But what is truly frightening is that, once the gate is passed, a state of "nothing you do removes it" is complete. Ordinary malware disappears on a reset; when something squats in the boot foundation, there may be no reliable way to remove it short of replacing the machine.

What actually happens with JVNVU#93024090

The weakness is that some "UEFI applications"—small programs the makers signed and distributed (shells, bootloaders, and maintenance tools that run before boot)—left dangerous operations usable as-is. According to the CERT/CC note, these programs can run powerful commands without access controls: mm (direct memory rewriting), dmpstore / setvar (reading and writing the NVRAM boot-time settings area), and insmod (loading drivers without signature checks).

This is a "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 is a condition for it to work: the attacker must already hold administrator privileges or be able to operate the device physically. 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 powerful move to build a "finished form" of persistence that is hard to detect or remove. As of disclosure, there is no public confirmation that this weakness has been exploited in the wild.

Is my computer affected?

Whether you are affected depends on your PC's maker and whether the signature of the vulnerable software above is trusted on that device. The table below organizes the makers CERT/CC lists as affected and the ones that responded "not affected."

Even if you use a PC from a maker in the table, you are not in immediate danger, because the attack requires admin rights or physical access. Still, devices from the listed makers are in a state where "the gatekeeper can be bypassed," so it is safer to close the hole with the updates below. Note that no individual CVE numbers were assigned; this is handled collectively under the CERT/CC and JVN tracking IDs.

How should I respond?

Respond from two directions. One is to apply the firmware (BIOS/UEFI) updates your PC maker distributes. Check each maker's support page for the latest update for your model. Some makers, like GIGABYTE, have stated they will remove the vulnerable software itself.

The other is to update the revocation list called "DBX". This registers the signatures of software found to be dangerous as "no longer trusted," so Secure Boot won't let them through. On Windows, DBX can be updated through the Secure Boot-related updates Microsoft distributes. As a baseline defense, it is important to keep Windows Update current. CERT/CC likewise lists both firmware updates and DBX updates as countermeasures.

Basic measures that prevent the stage before the foundation is attacked also help. Don't hand over admin rights easily (don't install suspicious software, don't run as administrator all the time), be careful about carrying around or leaving laptops unattended, and enable disk encryption (such as BitLocker) on corporate machines. These everyday practices help stop attackers short of the "admin rights or physical access" precondition.

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 powerful commands remain in a small maintenance tool or shell, 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. Parts a maker signs and distributes, and parts shipped with default settings or default passwords, share a common foundation: users trust them as "legitimate, therefore safe." That is exactly why pulling in maker updates without fail and keeping the foundation's safety mechanism current is the most reliable defense.

Frequently asked questions

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. Someone doing nothing is not taken over in one shot from across the network. It is troublesome, however, when used for "persistence" after admin rights are seized with other malware.

Q. How do I check whether my PC is affected?

A. First check your maker's name in the table above, then look at the maker's support page for firmware updates or security notices for your model. Also keep Windows Update current so DBX (revocation list) updates are pulled in.

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 UEFI apps signed and distributed by several makers—Acer, ASUS, GIGABYTE, Toshiba and others—were found to have a weakness that lets attackers slip past Secure Boot, the startup safety check. If abused, a bootkit that survives an OS reinstall and is hard for antivirus to spot can be planted in the PC's foundation.

It requires admin rights or physical access, so it is not the kind anyone can trip over remotely. Still, given how heavy the impact is—"once it's in, you can't remove it"—devices from the listed makers are safest closed off early with maker firmware updates and DBX updates. Even for signed, legitimate parts, continually pulling in updates rather than trusting blindly is the surest path to protecting the boot foundation.

References

• ▸ JVN - JVNVU#93024090 Secure Boot bypass in vendor-signed UEFI applications
• ▸ CERT/CC - VU#457458
• ▸ Microsoft - Windows Secure Boot certificate and CA updates