More details here, and there’s a second recently found Secure Boot flaw too.
https://arstechnica.com/security/2025/06/unearthed-in-the-wild-2-secure-boot-exploits-microsoft-patches-only-1-of-them/
There’s a pinned comment from the researcher who found the second flaw that’s interesting info. In part, his comment reads:
Unfortunately, it was a long process to communicate the extent of the vulnerability, and for it to pick up any traction. I coordinated with the vendor and agreed on public disclosure dates, before sharing any details.
Microsoft also dismissed the report after about a week, as they believed it was not their responsibility, due to the vulnerability existing within the igel-flash-driver, rather than the shim signed by them.
As others have mentioned, this highlights the current state of Secure Boot; while it can be an effective gatekeeper, users should be wary of who/what they are implicitly trusting. If not needed, the Microsoft 3rd Party UEFI CA should be distrusted. For Linux users, I also recommend generating and enrolling your own keys, to sign a unified kernel image. These can be generated automatically after a system upgrade.