Windows Update Broke Linux Dual Boot? SBAT, Shim and DBX Explained

A Windows update can stop Linux booting on a dual-boot PC because both systems share one set of Secure Boot revocation data in firmware. When Windows raises the minimum allowed version of the Linux shim bootloader (SBAT) or adds entries to the forbidden list (dbx), an older shim fails its check. The fix is to update shim and GRUB from your distribution, not to switch Secure Boot off for good.

That is exactly what happened to many people after Microsoft's August 13, 2024 security update, which applied an SBAT revocation that Microsoft said would skip dual-boot machines. Some were hit anyway and saw "Verifying shim SBAT data failed: Security Policy Violation" at power on. This guide explains the moving parts, what Microsoft actually said, how to read your own machine's state, and how to recover without making things worse.

Key takeaways

• db, dbx, SBAT and MOK are different trust lists: allowed, forbidden, minimum generation per component, and owner added keys.
• SBAT exists because dbx ran out of room. The shim project says BootHole revocations alone added about 10 kB to a store that is typically 32 kB.
• Microsoft's August 2024 update applied SBAT on Windows devices to stop vulnerable Linux shims. Microsoft said it would not apply where dual booting was detected, then published a known issue confirming some dual-boot users could not boot Linux.
• September 2024 and later Windows updates do not contain the setting that caused the problem, according to Microsoft's own release notes. Machines that already received it still need a newer shim.
• The durable fix is a current, distribution-signed shim and GRUB. Shim 15.8 (January 2024) fixed CVE-2023-40546 through CVE-2023-40551, including CVE-2023-40547.
• Disabling Secure Boot is a temporary recovery step at most. The mokutil manual states that shim deletes the SBAT revocations when Secure Boot is disabled, which also removes the protection they provide.
• Have your BitLocker recovery key and a current live USB before touching firmware settings.
• The boot chain is mostly outside Safeguard's scope. The honest overlap is that shim and GRUB are packages inside OS and appliance images whose SBOMs you should keep.

What is actually happening when Windows "breaks" Linux?

Nothing in a Windows update edits your Linux partition. What changes is shared state in UEFI firmware variables. The firmware checks every boot program against lists stored there, and Windows Boot Manager and the Linux shim are both checked against the same lists, because both are signed through certificates Microsoft controls.

Distributions do not get each GRUB build and kernel signed by Microsoft. Microsoft signs a small first-stage loader called shim. Ubuntu's security documentation calls shim a "pre-bootloader" that the firmware validates, and that carries Canonical's certificate to validate GRUB and the kernel. Debian's wiki describes the same design: shim is signed by Microsoft and "embeds Debian's signing keys."

So shim is the gatekeeper for the whole Linux side. If it is revoked, nothing after it runs. Because Windows receives Secure Boot revocation updates through Windows Update, a Windows patch can change what the firmware or shim accepts on the next boot. It looks like Windows broke Linux; in practice Windows enforced a rule that your Linux shim was too old to pass.

What are db, dbx and SBAT, and how do they differ?

Microsoft's key management guidance for OEMs defines the two firmware databases plainly. The authorized database (db) "contains public keys and certificates that represent trusted firmware components and operating system loaders." The forbidden signature database (dbx) "contains hashes of malicious and vulnerable components as well as compromised keys and certificates and blocks execution of those malicious components." The same guidance says dbx must be checked before db, and any match must stop the image from running.

SBAT, Secure Boot Advanced Targeting, sits beside those two. The shim project's SBAT document explains that every revocable component (shim, GRUB, and others) carries a small CSV table in a .sbat section of its EFI binary, listing a component name and a generation number. A separate UEFI variable, SbatLevel, records the minimum generation that is still acceptable. If a binary's generation is lower than the level, it is refused.

MOK, the Machine Owner Key list, is shim's own database of keys that the person who owns the machine has enrolled, for example to load self-built kernel modules. Debian notes that MOK changes "may only be confirmed directly from the console at boot time", which is a deliberate safeguard against software silently adding keys.

The practical difference: a dbx entry targets one specific binary or one certificate, and every new revocation adds bytes. An SBAT change targets a class of builds ("every GRUB below generation 4") and overwrites an existing entry, so the list stays small.

Why was SBAT introduced?

SBAT is a direct consequence of BootHole. BootHole, CVE-2020-10713, was disclosed on July 29, 2020, as a flaw in GRUB2 that could allow code execution during boot even with Secure Boot enabled. It rated 8.2 under CVSS 3.1. Because nearly every signed GRUB2 build was affected, the only way to stop old builds from running was to revoke them.

Revoking them through dbx was painful. The shim project's SBAT document says the BootHole revocations increased dbx by about 10 kB, "roughly a third" of a typical 32 kB store, and that merged revocation lists could push dbx toward half full. Every future GRUB bug would cost more space, and every shim update would multiply the number of images that needed signing.

The BootHole disclosure also described the operational risk: if a dbx revocation lands before shim and the bootloader are updated, Linux will not load, and approved recovery media can stop booting. It cited an earlier 2020 dbx update that left some devices unusable before it was withdrawn.

SBAT was the industry's answer. In the shim project's words, "Shim can move faster than the UEFI system firmware ecosystem." Instead of listing hashes, vendors agree on generation numbers. When a new class of bug is fixed, the global generation for that component goes up, every vendor that signs a fixed build bumps its own .sbat entry, and one small edit to SbatLevel retires every older build at once.

SBAT complements dbx rather than replacing it. The shim document notes that shim certificates can still be revoked by hash in dbx when a shim bug is serious enough.

How generation numbers work

The SBAT document defines two kinds of number:

• A global generation for each component. A vendor that signs, say, GRUB at generation 4 is promising that its build contains the fixes for every public or pre-disclosed issue covered up to generation 4.
• A product specific generation for one vendor's build, written as an entry such as grub.debian or grub.fedora. This lets one vendor fix a problem in its own patches without forcing the whole industry to rebuild.

The document is firm that both "should only ever go up; they should never be reset." Its example for a Fedora GRUB build:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.04,https://www.gnu.org/software/grub/
grub.fedora,1,The Fedora Project,grub2,2.04-31.fc33,https://src.fedoraproject.org/rpms/grub2

Each line is component, generation, vendor, package, version and URL; the first line declares the SBAT format version.

What happened with the August 2024 SBAT update, and what did Microsoft say?

On August 13, 2024, Microsoft shipped KB5041585 for Windows 11 versions 22H2 and 23H2 (OS builds 22621.4037 and 22631.4037). Its release notes include an item headed "Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)". Microsoft wrote that the update "applies SBAT to systems that run Windows" and that this "stops vulnerable Linux EFI (Shim bootloaders) from running."

The same note made two promises and one warning. It said the SBAT update "will not apply to systems that dual-boot Windows and Linux." It warned that after SBAT is applied, "older Linux ISO images might not boot," and told people to work with their Linux vendor to get an updated ISO.

The same KB page now carries a known issue. Microsoft acknowledges that "you might face issues with booting Linux if you have enabled the dual-boot setup," quotes the error "Verifying shim SBAT data failed: Security Policy Violation," and restates that the SBAT update "will not be applied to devices where dual booting is detected." In other words, Microsoft's own documentation confirms that some dual-boot machines were affected even though the design intent was to skip them. Microsoft does not explain in that note why detection missed those machines.

On September 10, 2024, KB5043076 (OS builds 22621.4169 and 22631.4169) repeated the dual-boot item and added a second error string users reported: "SBAT self-check failed: Security Policy Violation." It pointed readers to Microsoft's guidance for CVE-2022-2601 and CVE-2023-40547.

Microsoft's resolution text on the August KB is the most useful line for anyone still affected. It says the September 2024 and later updates do not contain the settings that caused the issue. On systems that dual-boot, "there are no additional steps necessary" after installing those later updates. On Windows-only systems, administrators who want the protection can set a registry key documented in the CVE-2022-2601 and CVE-2023-40547 entries so the SBAT update is applied.

Note what that wording does not say. Later updates stopped applying the setting; nothing in Microsoft's text says they lowered SbatLevel on machines that already had it, and the shim project designs generation numbers never to go down. A machine hit in August 2024 that never updated shim is still in the same state, and the supported route is a Linux side update, as Microsoft's "work with your Linux vendor" advice implies.

Which CVEs drove the revocation?

The two CVEs Microsoft cites map neatly onto the shim project's public SbatLevel history:

• CVE-2022-2601 is one of the GRUB2 flaws that the shim project lists against the revision sbat,1,2022111500, which raised GRUB to generation 3.
• CVE-2023-40547 is the most serious of six shim flaws fixed in shim 15.8. The shim project lists the January 2024 shim CVEs against revision sbat,1,2024010900, which raised shim to generation 4.

Microsoft's KB text does not name the exact SbatLevel revision Windows wrote in August 2024, so this guide does not either. What matters for recovery is the same either way: a shim at generation 4 or later, and a GRUB at the generation your distribution currently ships, passes the policies published to date.

What error do users see?

The two strings Microsoft documents are the ones to search for:

If Windows still boots from the firmware boot menu, your disk and Linux data are fine. This is a trust decision, not corruption.

What were the shim CVEs of 2023 to 2024?

The shim maintainers released shim 15.8 on January 23, 2024. The release notes list six CVEs:

Ubuntu's CVE page describes CVE-2023-40547 as a flaw in shim's HTTP boot support that trusts attacker controlled values while parsing an HTTP response, leading to an out of bounds write. It also notes the conditions: an attacker needs a man in the middle position or a compromised boot server, and it is only reachable during early boot. Ubuntu rates it Medium priority with a CVSS 3.1 score of 8.3. Debian's security tracker describes the same conditions.

So CVE-2023-40547 is not something a web page can trigger on a laptop booting from its own disk. Old shims are still revoked industry wide, because a signed binary known to be weak can be carried to any Secure Boot machine that still trusts it.

The release notes also list SBAT related changes in 15.8: a change that blocks Debian GRUB binaries with SBAT generation below 4, the addition of the SbatLevel_Variable.txt file that documents revocations, and a change so signatures are verified before SBAT levels are checked.

Fixed versions on major distributions

Ubuntu lists 23.04 and 23.10 as end of life and not fixed. On an end of life release there may be no signed shim that passes current SBAT levels, so upgrade the release rather than fight the boot chain.

How do distros coordinate with Microsoft on revocations?

There is no single public calendar, but the shim project publishes the history of every SbatLevel revision in SbatLevel_Variable.txt. Reading it shows how the coordination works in practice:

A few patterns stand out. Revocations are staged: 2022052400 was first offered as an opt in "latest" policy and later shipped automatically without the shim bump, and two documented revisions (2023012950 and 2023091900) were not delivered at the time because vendors disagreed on exploitability or on whether they shipped the affected GRUB module. Vendor specific entries such as grub.debian or grub.proxmox revoke one vendor's builds instead of everyone's. Windows can apply SBAT itself: the shim document says systems that never run shim, such as Windows, can write SbatLevel from boot services code, which is the mechanism behind the August 2024 update. The payload is public: SbatLevel values live in the shim source tree and are compiled into shim, so anyone can read a revision before it reaches their machine.

Microsoft signs shim builds through its third party UEFI CA after review and ships dbx and SBAT updates through Windows Update. Its OEM guidance links the UEFI Forum's revocation list file and notes that dbx content "will be split and applied based on the signing certificate(s) in the KEK and DB variable of the device."

How do you read your machine's Secure Boot and SBAT state?

These commands only read state. Run them before you change anything.

On Linux

# Is Secure Boot on?
mokutil --sb-state

# Which SBAT revocations are active right now (read from SbatLevelRT)?
mokutil --list-sbat-revocations

# Which keys has the machine owner enrolled in MOK?
mokutil --list-enrolled

# Which shim and GRUB packages are installed?
# Debian and Ubuntu
dpkg -l | grep -E 'shim-signed|grub-efi-.*-signed'
# Fedora and RHEL family
rpm -q shim-x64 grub2-efi-x64

The mokutil manual describes --list-sbat-revocations (short form --sbat) as listing "the current revocations active in the Secure Boot Advanced Targeting (SBAT) store (SbatLevelRT)." The output is a small CSV, for example a first line naming the revision followed by lines such as shim,4 and grub,5.

To see what generation your installed shim claims, read its .sbat section. This does not modify the file:

# Find the mounted EFI system partition first; do not guess the path
findmnt /boot/efi

# Then list the vendor folders it contains
ls /boot/efi/EFI/

# Dump the .sbat section of your shim to a temporary file and print it
objcopy --dump-section .sbat=/tmp/shim-sbat.csv /boot/efi/EFI/ubuntu/shimx64.efi
cat /tmp/shim-sbat.csv

Replace ubuntu with your distribution's folder name (for example debian or fedora). Compare the shim line in the dump with the shim line in mokutil --list-sbat-revocations. If the binary's number is lower, that shim will be refused. Do the same with grubx64.efi for the grub lines.

On Windows

Open PowerShell as administrator:

# Returns True when Secure Boot is on
Confirm-SecureBootUEFI

# Recent Secure Boot servicing events, using the IDs Microsoft documents in KB5016061
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1032,1796,1801,1808 } -MaxEvents 20 |
  Format-Table TimeCreated, Id, Message -Wrap

Microsoft's KB5016061 lists the event IDs Windows records when it updates Secure Boot data. Among them: 1032 flags a BitLocker recovery risk, 1796 an unexpected error, 1801 that certificates are not yet applied, and 1808 that a device is fully updated. The KB lists SBAT as one of the update types those generic events can report. If a command returns nothing, it means no matching events were logged, not that the machine is unaffected.

How do you recover a dual-boot machine safely?

Work through these steps in order and stop as soon as Linux boots with Secure Boot on. None of them require bypass tools, and none of them touch Windows.

Step 0: Prepare before you change anything

1. Confirm Windows still boots. Use your firmware's one time boot menu (often F12, F11, F9 or Esc at power on; check your PC maker's documentation) and pick Windows Boot Manager.
2. Get your BitLocker recovery key now. Changing Secure Boot settings can trigger a BitLocker recovery prompt on the Windows side. Microsoft's KB5016061 even has an event (1032) for the BitLocker recovery risk during Secure Boot servicing. See our guide on where to store recovery keys for encrypted laptops.
3. Make a current live USB of your distribution from its official download page. A recent image carries a shim that passes current SBAT levels. This is the "updated ISO" Microsoft told users to get from their Linux vendor.
4. Back up anything irreplaceable on the Linux partition from Windows or from the live USB before you write to the EFI system partition.

Step 1: Boot a current live USB and update from inside your installed system

This is the cleanest path because Secure Boot stays on the whole time.

Warning: the commands below mount partitions and write to your installed system. Mounting the wrong partition, or the Windows EFI folder, can cause a second problem. Identify every device first and re-check the names before each command. Device names such as nvme0n1p5 differ on every machine.

Boot the live USB, open a terminal and identify your partitions:

# Read only: list disks, partitions, filesystems and labels
lsblk -f
sudo blkid

Find your Linux root partition (often ext4 or btrfs, the size you expect) and the EFI system partition (vfat, usually a few hundred MB, often the same one Windows uses). Write the names down. Then, using your own names:

# CHECK: replace both device names with the ones you identified above
ROOT=/dev/nvme0n1p5
ESP=/dev/nvme0n1p1

# Re-confirm before mounting
lsblk -f "$ROOT" "$ESP"

sudo mount "$ROOT" /mnt
sudo mount "$ESP" /mnt/boot/efi
for d in dev proc sys run; do sudo mount --bind /$d /mnt/$d; done
sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
sudo chroot /mnt

If your system uses a separate /boot partition or btrfs subvolumes, mount those as your distribution documents before continuing. Inside the chroot, update the signed boot packages:

# Debian and Ubuntu
apt update
apt install --only-upgrade shim-signed grub-efi-amd64-signed
# Fedora and RHEL family
dnf upgrade shim-x64 grub2-efi-x64

Then leave cleanly:

exit
sudo umount -R /mnt

Remove the live USB and reboot. Pick your Linux entry from the firmware boot menu.

These are the common x86 64 bit package names; Arm systems use different ones.

Step 2: If you cannot update from a live USB, use a temporary Secure Boot change

If a chroot is impractical (encrypted root, unusual layout), there is a fallback that needs care. The mokutil manual states that "If UEFI Secure Boot is disabled, shim automatically deletes the SBAT revocations." With Secure Boot briefly off, the old shim loads, you update it, then you turn Secure Boot back on.

Warning: this step lowers your protection while it is in effect, and changing Secure Boot state can trigger BitLocker recovery on Windows. Do it only after Step 0. Do not install anything other than your distribution's signed shim, GRUB and kernel packages while Secure Boot is off.

1. Enter firmware setup and disable Secure Boot. The menu name varies by vendor.
2. Boot Linux normally.
3. Update the signed packages, using the same apt or dnf commands as in Step 1 but without the chroot.
4. Verify the new shim's SBAT data with the objcopy check from earlier. The shim line should show generation 4 or later.
5. Reboot, enter firmware setup, and turn Secure Boot back on.
6. Boot Linux and confirm with mokutil --sb-state that it reports Secure Boot enabled.
7. Boot Windows once to confirm it starts and, if asked, enter the BitLocker recovery key.

Some 2024 community guides mention a mokutil option to delete the SBAT policy. The current mokutil manual documents only latest and automatic for --set-sbat-policy, so we do not recommend a deletion command; follow the documented behaviour above or your distribution's instructions.

Step 3: Reinstall the boot entry only if it is missing

If Linux now passes SBAT but the firmware boot menu no longer lists it, the boot entry was lost rather than revoked.

Warning: efibootmgr writes to firmware variables. A wrong disk or partition number creates a broken entry. Read the existing entries first and check the device again.

# Read only: show current entries with their file paths
sudo efibootmgr -v

# CHECK: confirm disk and partition number of the ESP again
lsblk -f

# Example only: create an entry for Ubuntu's shim on disk /dev/nvme0n1, partition 1
sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 \
  --label "ubuntu" --loader '\EFI\ubuntu\shimx64.efi'

Reinstalling the shim or GRUB package usually recreates the entry, so try that first.

Recovery decision table

What does mokutil show, and how do you read SBAT levels?

Read the three outputs together. mokutil --sb-state tells you whether either list is enforced at all. mokutil --list-sbat-revocations gives the minimum generation per component: a line shim,4 refuses any shim whose .sbat table says shim,3 or lower, and a suffixed line such as grub.debian,4 applies only to binaries carrying that vendor entry. The .sbat section of each binary is what it claims, and every component line must be equal to or higher than the stored level.

The mokutil manual also documents --set-sbat-policy with two values. latest tells shim to "Enforce the latest SBAT revocations" built into it; automatic enforces "the previous generation of SBAT revocations." That is how shim stages revocations: a new shim can carry a stricter list it only applies once vendors have caught up. For most people automatic is the right default. Choose latest on a dual-boot machine only if every bootable medium you rely on is already current.

Why should you not leave Secure Boot off?

With Secure Boot off, the firmware runs any boot program it finds and shim stops enforcing SBAT. That removes the protection against exactly what these revocations target: an old, signed but vulnerable bootloader that someone with administrator rights could plant to run code before the operating system starts. BootHole was dangerous because unsigned configuration could abuse a signed loader.

There are practical costs too. BitLocker and measured boot depend on Secure Boot state, so changing it can force recovery prompts and weaken TPM based protection. Many organisations require Secure Boot for device health checks. And a refused shim is a signal that a component is known to be weak; turning the check off hides the signal without fixing the cause.

If a driver or custom kernel needs a signature the default keys do not provide, the documented route is to enroll your own key through MOK (mokutil --import, confirmed at the console on next boot), not to disable Secure Boot. Debian and Ubuntu both document it.

How do you prepare a dual-boot machine before the next revocation?

Prepare before the next one lands:

1. Update the Linux side as often as Windows. A Linux install booted twice a year is the classic victim. Boot it monthly and install shim-signed, GRUB and kernel updates.
2. Stay on a supported release, because end of life releases stop receiving signed shims.
3. Check SBAT levels after each Patch Tuesday with mokutil --list-sbat-revocations and compare with your shim and GRUB .sbat data.
4. Refresh your live USB twice a year. Old rescue media is what Microsoft warned would fail.
5. Keep the BitLocker recovery key on a device other than the laptop.
6. Record boot entries and back up the EFI system partition.

Warning: the copy below only reads from the ESP, but confirm the mount point first so you copy the right partition.

# CHECK: confirm this is the ESP (vfat) before copying
findmnt /boot/efi
sudo cp -a /boot/efi "/root/esp-backup-$(date +%F)"
sudo efibootmgr -v > "/root/efibootmgr-$(date +%F).txt"

For fleets, The original BootHole guidance still holds: update bootable media, gold images and recovery images before a revocation, test on the firmware versions used in the field, roll out slowly, and verify recovery paths.

Where does the 2026 certificate rotation fit?

SBAT and dbx revoke old binaries. A separate 2026 change replaces Microsoft's 2011 Secure Boot certificates: Microsoft's OEM guidance says the Microsoft Corporation KEK CA 2011 "is set to expire in 2026" and lists 2023 replacements, including the Microsoft UEFI CA 2023 used for third party binaries such as shim. A machine whose KEK is never updated may stop receiving future dbx and SBAT updates. We cover that side in Secure Boot certificates expire in 2026: what to check and UEFI Secure Boot and the software supply chain in 2026.

Where Safeguard fits, honestly

The boot chain is mostly outside Safeguard's scope. Safeguard does not read UEFI variables, change Secure Boot settings, scan firmware, manage devices or fix a laptop that will not boot. The recovery steps in this guide are the job of your distribution, your PC maker and Microsoft.

The one honest overlap is inventory. Shim and GRUB are ordinary packages inside OS images, VM templates and appliance images that teams build and ship. If you keep an SBOM for each of those images, you can answer "which of our images still carry shim older than 15.8?" the same way you answer it for any other component. Safeguard can scan container images and SBOM files and show which projects contain a given component and version. For more on how boot components fit into supply chain thinking, see Secure Boot, UEFI and the software supply chain and Secure Boot, trusted boot and measured boot: the difference.

Common mistakes

• Leaving Secure Boot off after recovery. Check mokutil --sb-state after every fix.
• Reinstalling GRUB without updating shim. If shim is the revoked component, a new GRUB changes nothing.
• Fixing it with an old live USB. That image's shim is likely below the current level too.
• Guessing device names. Run lsblk -f before every write.
• Copying shim from another distribution. Each shim embeds its own vendor's keys and will not trust your GRUB and kernel.
• Running end of life releases on Secure Boot hardware. No new signed shim will arrive.
• Changing firmware settings without the BitLocker key. You can fix Linux and lock yourself out of Windows in one evening.
• Assuming a later Windows update undid the change. Later updates stopped applying the setting; they did not lower levels already written.

FAQ

Why did a Windows update stop Linux from booting?

Because both systems share Secure Boot data in firmware. Microsoft's August 13, 2024 update applied an SBAT setting that refuses shim bootloaders below a minimum generation. Microsoft said it would skip dual-boot machines, but its own known issue confirms some dual-boot users were affected.

What does "Verifying shim SBAT data failed: Security Policy Violation" mean?

It means the shim on your EFI system partition reports an SBAT generation lower than the minimum stored in firmware, so shim refuses to continue. Your Linux files are intact. Update shim and GRUB to fix it.

Is it safe to disable Secure Boot to fix it?

Only briefly, as a recovery step, after you have your BitLocker recovery key. The mokutil manual says shim deletes SBAT revocations when Secure Boot is disabled. Update shim, then turn Secure Boot back on and confirm with mokutil --sb-state.

Did Microsoft fix the dual-boot SBAT problem?

Microsoft says the September 2024 and later updates do not contain the setting that caused the issue, and that dual-boot systems need no additional steps after installing them. Machines that already received the August setting still need a current Linux shim.

How do I check my SBAT level on Linux?

Run mokutil --list-sbat-revocations. It prints the active revision and the minimum generation per component, such as shim,4. Compare it with the .sbat section of your installed shim and GRUB binaries.

What is the difference between dbx and SBAT?

dbx is a firmware list of forbidden hashes and certificates; each revocation adds entries. SBAT stores one minimum generation per component and raises it in place, so it can retire many builds without growing.

Which shim version fixes CVE-2023-40547?

Shim 15.8, released January 23, 2024. On Ubuntu that is shim-signed 1.58 on 24.04, 1.51.4 on 22.04 and 1.40.10 on 20.04. Debian 12 first fixed it in 15.8-1~deb12u1 and now carries 16.1.

Why won't my old Linux USB boot after a Windows update?

Microsoft warned in the August 2024 notes that after SBAT is applied, older Linux ISO images might not boot. The shim on old media is below the new minimum. Download a current image from your distribution.

How do I stop this from happening again?

Boot and update the Linux side regularly, stay on a supported release, refresh your live USB, keep your BitLocker key handy, and check mokutil --list-sbat-revocations after Windows updates.

Fix it without waiting for upstream

A dual-boot laptop that has just been recovered is also a developer machine that will pull packages, toolchains and images again, and the OS images you build carry shim and GRUB as components alongside everything else. The boot chain itself is fixed by your distribution and Microsoft, but the open source dependencies and images you build and ship are where the steps below apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos repairs a boot chain or changes Secure Boot settings; that work belongs to your distribution and your PC maker. They show the inventory and fix steps for the software you build, with a person approving each action.

In this Safeguard CLI session you run safeguard and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. After rebuilding a dual-boot developer machine, the same flow is how you bring a project's dependencies back to fixed versions instead of reinstalling whatever was cached.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. It suits teams that build OS or appliance images in-house and want to scan those images and their SBOMs locally, so questions like "which images still ship an old shim package?" can be answered without the images leaving the network. Our guide to how the local runner and offline mode work covers the details.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which projects contain a given component and version, which is the same question you would ask about shim or GRUB versions recorded in your image SBOMs. Our post on using SBOMs to find affected products fast shows that workflow in more depth.

Click through it at your own pace, or open it full screen.

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli.

Quick check

Sources

• Microsoft Support: August 13, 2024, KB5041585 (OS Builds 22621.4037 and 22631.4037)
• Microsoft Support: September 10, 2024, KB5043076 (OS Builds 22621.4169 and 22631.4169)
• Microsoft Support: KB5016061, Secure Boot DB and DBX variable update events
• Microsoft Learn: Windows Secure Boot key creation and management guidance
• rhboot/shim: SBAT.md
• rhboot/shim: SbatLevel_Variable.txt
• rhboot/shim: release 15.8
• mokutil manual page (lcp/mokutil)
• Ubuntu Security: CVE-2023-40547
• Ubuntu Security documentation: UEFI Secure Boot
• Debian security tracker: CVE-2023-40547
• Debian Wiki: SecureBoot
• NVD: CVE-2020-10713 (BootHole)

Last reviewed: 23 October 2026.