There's no patch for Secure Boot's signed-binary problem — only a revocation the ecosystem can't push
There is no bug here. That is not a reassurance — it is the entire problem.
On June 18, 2026, CERT/CC published VU#457458, “Vendor-signed UEFI applications found vulnerable to Secure Boot bypass”. The note covers eleven vendor-signed UEFI applications — UEFI shell utilities and a GRUB2 module — that expose privileged functions like mm, dmpstore, setvar, and insmod (CERT/CC, VU#457458). (Don’t read “eleven binaries” as “eleven affected vendors” — the vendor-status breakdown is its own, much more uncertain question; see the scoreboard below.) Those functions read and write memory, rewrite NVRAM variables, and load drivers. And that is what they are for. mm is a memory-manipulation primitive. dmpstore and setvar exist to touch NVRAM. insmod loads modules. None of them is malfunctioning. None of them has a defect to fix.
The “vulnerability,” reported by Martin Smolar of ESET, is that these tools work as designed, carry no access controls, and are signed by certificates the firmware already trusts. Secure Boot runs them because the signatures are genuine. CERT/CC frames it bluntly: the applications are exposed to Secure Boot bypass “via a ‘Bring Your Own Vulnerable Driver’ (BYOVD)-style attack” (CERT/CC, VU#457458). It is BYOVD one floor down — in the pre-boot environment, with a vendor signature instead of a stolen one. A machine that trusts the relevant certificate can be coerced into running attacker-chosen code before the operating system ever loads, using binaries that are behaving exactly the way their authors intended.
So if nothing is broken, what does “fix” even mean? That question is the whole story.
A patch has nothing to reach
You patch a defect. You cannot patch the absence of one. There is no off-by-one to correct in mm, no missing bounds check in dmpstore. The code is correct. The signature is valid. The trust decision is the flaw, and trust is not something a code change can revoke.
That leaves exactly one lever: stop trusting the binaries. In UEFI, the place you do that is the DBX — the forbidden-signatures database, the firmware’s denylist of things it will refuse to load even when the signature checks out. DB says “these are allowed”; DBX says “these are not, no matter what.” Revoking signed-but-dangerous code means pushing the binaries’ hashes into every machine’s DBX.
CERT/CC’s mitigation says it plainly: “Administrators should update and verify the UEFI DBX on affected systems to ensure the vulnerable binaries are revoked and can no longer execute during the boot process” (CERT/CC, VU#457458), alongside vendor firmware updates that swap the binaries out. That is the fix. Not a patch — a withdrawal of trust, enforced one machine at a time.
The part the ecosystem is bad at
Here is where I stop quoting CERT/CC and start arguing, because this next part is analysis, not something the advisory claims.
Adding eleven entries to a denylist that every machine has to ingest itself is a fleet-wide trust operation, and the ecosystem has a track record on those. My read of that track record is not flattering. DBX updates are slow to propagate and risky to apply, and this is inference from how revocation has historically gone, not a sourced figure — so treat it as my argument, weigh it yourself.
The propagation problem is structural. There is no single button. The DBX update has to flow through OS vendors, OEM firmware pipelines, and management tooling, and then actually land — which depends on machines being patched, rebooted, and not running firmware too old or too quirky to take the update cleanly. Servers that reboot twice a year are still trusting the old list in the meantime.
The application problem is worse, because applying a DBX update is not free of consequences. The whole point is to make the firmware refuse to load specific signed binaries. If one of those binaries — or something that chains off the same trust — is still sitting in a live boot path, refusing to load it does not produce a warning. It produces a machine that will not boot. That is the brick risk, and it is exactly why cautious administrators sit on DBX updates: the safe-looking move is to wait, and waiting is precisely what leaves the window open. A revocation you are afraid to deploy is not a mitigation. It is a mitigation-shaped object.
None of that is a knock on CERT/CC’s guidance. The guidance is correct. It is the delivery mechanism — fleet-wide DBX revocation — that the ecosystem has repeatedly shown it cannot move quickly or safely. The advice is right and the pipeline is the bottleneck, and those two things are both true at once.
The honest scoreboard
CERT/CC notified 27 vendors. Here is exactly where they stand, and I am going to be precise about the uncertainty, because the uncertainty is the point.
| Status | Count | Who | Confidence |
|---|---|---|---|
| Affected | 1 | GIGABYTE | OBSERVED (CERT/CC) |
| Not Affected | 6 | AMD, AMI, Insyde, Intel, Phoenix, Supermicro | OBSERVED (CERT/CC) |
| Unknown | 20 | Not disclosed | OBSERVED as unknown — status genuinely unreported |
One confirmed affected. Six confirmed clear. And twenty whose status is, flatly, Unknown (CERT/CC, VU#457458). I am not going to launder that into “twenty probably affected.” Unknown means unknown — those vendors have not said, and silence is not a confession. It is also not an all-clear. It is a blank space on the board, and a fix that depends on those vendors moving cannot be assessed until they speak.
There is no CVE and no CVSS attached to this note. AMD addressed why, at least for itself: “AMD has reviewed this report and determined that the impacted product(s) have reached end of security support (EOSS)… AMD is declining to issue a CVE ID for this report” (CERT/CC, VU#457458). Read that for what it is: a maintenance lifecycle deciding the disclosure taxonomy. The trust problem does not expire when the support contract does.
For prior art, the note references CVE-2024-7344, the Howyar “Reloader” UEFI application that NVD describes as “vulnerable to execution of unsigned software in a hardcoded path” (NVD: CWE-347, CVSS 8.2 HIGH, published 2025-01-14) — a signed UEFI binary that was used to bypass Secure Boot in the prior disclosure cycle (CERT/CC, VU#457458). That is context, not this note’s identifier — VU#457458 carries no CVE of its own. The recurrence is the tell: signed pre-boot code that does dangerous things by design is not a one-off, it is a category.
So here is the takeaway, and it is not a controls checklist. The denylist is the fix. There is no patch coming, because there is no defect to patch. What has to happen is that eleven legitimately-signed binaries get revoked across an entire installed base through the one mechanism — fleet-wide DBX propagation — that has consistently proven slow to push and dangerous to apply, contingent on twenty vendors who so far have said nothing. A fix that depends on a silent supply chain and a revocation pipeline known to drag is a fix that exists on paper long before it exists on hardware. Check your own DBX. Do not assume anyone else has.
Sources
- CERT/CC Vulnerability Note VU#457458, “Vendor-signed UEFI applications found vulnerable to Secure Boot bypass” (primary)
- NVD entry for CVE-2024-7344 (prior art, referenced by CERT/CC)