It's Still Not to Late to Turn Off "Secure Boot"
Yesterday:
Published earlier this week is another timely reminder that firmware updates are risky and typically unreliable. Quoting "Fixing Firmware Update Issues on Framework Laptop 13:
The author shares their experience troubleshooting firmware update failures on a Framework Laptop 13 equipped with an defective chip maker Intel Core Ultra processor. Despite multiple attempts and issues with left-side ports, they successfully resolved the update problem by using the UEFI shell on a USB drive and providing specific instructions. They express gratitude for Framework's support.
If people reboot their PC or server today, and it relies on "Secure Boot" on Sept. 12 or later, then depending on the firmware there may be trouble ahead. GNU/Linux users don't reboot their machines all the time (unlike Windows users), so the full effect won't be immediately visible and widely reported.
Also published "September 11, 2025", there's this press release entitled "Binarly to Deliver Fourth Consecutive Keynote at LABScon, Unveil New Research on Firmware Trust Failures" in binarly.io:
This year’s presentation, Signed and Dangerous: BYOVD Attacks on Secure Boot, presents the first large-scale census of signed UEFI modules, drawn from both public threat intelligence feeds and Binarly’s private telemetry. We analyzed tens of thousands of binaries and discovered how over-privileged, under-scrutinized modules undermine Secure Boot’s trust model.Binarly research leads Alex Matrosov and Fabio Pagani will walk attendees through real-world bypass chains, including live exploitation on a fully patched system, and provide a hardening roadmap for vendors and defenders alike.
For the first time, Binarly will also introduce a new taxonomy of Secure Boot attack categories that span vulnerable signed modules, double-use binaries like UEFI shells, leaked private keys, and verification logic flaws. This framework is designed to help security teams map the full attack surface, moving the industry toward a more mature understanding of firmware-level risks.
Of course "Secure Boot" has nothing to do with security. It was deliberately misnamed, it is a misnomer. █

