EDK II / OVMF (UEFI Shell left enabled in downstream Ubuntu and LXD firmware builds): Not a memory-safety bug

Impact

Not a memory-safety bug - a packaging default. The interactive UEFI Shell is compiled into the shipped firmware image, and from it an attacker who already has the OS can load unsigned code and walk straight past Secure Boot. For anyone running GPU workloads inside VMs on OVMF, this quietly voids the guest's Secure Boot guarantee and any attestation chain rooted in it, which is precisely the guarantee confidential-compute and tenant-isolation stories are sold on.

Who can reach it

An attacker who already has administrative control of the guest OS (or the VM's boot configuration) and can reach the UEFI Shell on the next boot. Local to the guest; no firmware flash needed by the attacker.

What to do

Distribution package update, not an OEM BIOS flash - this is a build-flag fix in the edk2/OVMF firmware images shipped by the distro (Ubuntu, LXD). Update the ovmf/edk2 packages on your hypervisor hosts and restart the affected guests to pick up the new firmware blob; no host reboot required. Config workaround: remove the UEFI Shell from the boot order and enforce a firmware password / locked boot order in the guest's variable store, though a determined admin-level attacker inside the guest can often undo that.

References