A firmware weakness in nearly every Surface model let an attacker, or in this case Microsoft's own Copilot, permanently destroy hardware by writing garbage to its embedded controller. Microsoft spent 90 days quietly patching it, decided it didn't merit a CVE, and is now rewriting the Surface stack in Rust. Users running Linux or with Secure Boot disabled may still be exposed.
Microsoft has spent the past three months quietly shipping firmware updates to Surface devices to close a flaw that could turn a working laptop into a paperweight with a single malformed instruction. The catch for affected users is twofold: the patch only reaches you through Windows Update, and the bug was discovered not by a red team but by Microsoft's own Copilot assistant, which bricked a security researcher's laptop while trying to dim the screen.
The story, first reported by The Register, centers on the embedded controller that sits inside Surface hardware, known as the SAM or SSAM. This is the low-level chip that handles things like backlight levels, power management, and other hardware housekeeping. According to Australian security researcher Jack Darcy, his instance of Copilot generated and ran a series of Python scripts to find the right values for backlight control. Those scripts sent raw commands straight to the microcontroller, and one of them overwrote the firmware that the device needs to boot.
What actually happened
The technical chain here matters because it explains why the damage is permanent. Darcy described Copilot autonomously writing "four progressively aggressive Python scripts" that fired raw SSAM ioctl commands (the request code was SSAM_CDEV_REQUEST = 0xC028A501) at the controller. The scripts iterated blindly across a range of Command IDs, or CIDs, which function as the controller's internal API. Crucially, they sent empty and null payloads to commands that perform writes.
Microsoft's implementation included no check on what those write values contained. On most hardware, performing this kind of low-level firmware write requires a physical gesture: holding down a button, or bridging a jumper. That hardware interlock is the safety catch that stops software alone from corrupting the boot firmware. On Surface devices, Darcy says, that catch was absent. The probing triggered an update routine in the SAM that overwrote the UEFI and Secure Boot firmware with junk.
The device keeps running at first, because the controller was already initialized and is operating from RAM. The failure surfaces on the next reboot. When the SAM tries to reload from its non-volatile storage and finds corrupted data, it cannot initialize, and the machine never reaches Power-On Self-Test. No USB recovery, no factory reset, no access to the BIOS. The fix at that point is a new motherboard, which Darcy puts at hundreds of dollars.
He was blunt about the underlying design. "The SAM Bus is terribly designed," he said. The deeper problem is that read and write commands are interleaved in the same numbering space. "If all the reads were grouped together and all the writes were grouped separately, a probe script could safely scan the read range without ever accidentally wandering into write territory," Darcy explained. "But because reads and writes are interleaved, there is no safe range to probe. The moment you decide to enumerate what's available, you're already firing blind writes."
The legal and disclosure picture
This is where the watchdog lens comes in, because how Microsoft handled the report tells you a lot about who carries the risk. The Register approached Microsoft on March 10, 2026. The company's first move was to point the researcher back to the Microsoft Security Response Center intake process, which Darcy found too cumbersome to pursue. Only after the publication leaned on internal contacts did Microsoft engage, coordinating a call with an MSRC program manager on March 12. Microsoft then acknowledged the bug, committed to a fix, and asked for a 90-day publication delay while it shipped patches.
Microsoft declined to assign the flaw a CVE, saying it did not meet the bar. A spokesperson framed it narrowly: "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature."
That framing deserves scrutiny. The decision not to issue a CVE is not a neutral technicality. CVE identifiers are how the rest of the security ecosystem tracks, scans for, and communicates about vulnerabilities. When a vendor declines one, defenders, asset managers, and ordinary users lose the standard signal that would otherwise tell them their hardware is affected. The practical effect is that the only way to learn your Surface needed a fix is to have already installed it.
Who is still exposed
Microsoft's position is that managed devices, meaning those running with Secure Boot and Secure Core intact and receiving updates through Windows Update, are not at risk. The people left in the gap are predictable, and they are not edge cases:
- Users running Linux on Surface hardware
- Windows users who disabled Secure Boot or Secure Core for gaming
- Anyone using custom Windows drivers
- Users with USB boot enabled
Any of those configurations may remain vulnerable if the machine has not pulled the update. Darcy says the affected range appears to cover essentially the whole line, Surface Laptops 3 through 6 and Surface Book 1 through 3, with Surface Go models excluded and ARM variants untested. There is also a long tail here that no one can quantify: Darcy notes that bricked-Surface complaints have circulated on support forums for years, though there is no way to confirm how many trace back to this specific cause.
This matters for user rights in a concrete way. A device that can be destroyed irreversibly from userspace, with no recovery path and a repair bill attached, shifts the cost of a vendor's firmware design straight onto the owner. The people most likely to hit it are the ones who modified their own hardware, exactly the users who paid for a device and chose to run it on their own terms.
Microsoft's longer answer: Rust
The more forward-looking part of the story is architectural. Microsoft is rebuilding the Surface stack in Rust, the memory-safe systems language that has become the industry's standard answer to exactly this class of firmware bug. David Abzarian, chief architect for Microsoft Surface, said future Surface for Business hardware will be built on a new foundation spanning the embedded controller, UEFI, and drivers.
"We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust," Abzarian said, naming two efforts: Secure EC for the controller and Project Patina for a rewrite of the UEFI DXE Core. Microsoft is also shipping some drivers in Rust and co-developing a framework called Windows Drivers in Rust (WDR). Much of this sits under the Open Device Partnership, an open-source effort, which Abzarian tied to a transparency principle.
Rust does not automatically prevent a design decision like interleaving destructive write commands with harmless reads, that is a logic problem rather than a memory-safety one. But the broader rewrite is a tacit acknowledgment that the existing firmware foundation was not built to verify what it was being asked to do. As Darcy put it, "a little more innovation around verifying incoming data at the firmware level would have been greatly appreciated."
For now, the action item for anyone on a Surface is straightforward. Run Windows Update, and if you deliberately disabled Secure Boot or Secure Core, understand that you may be sitting on an unpatched machine that a stray script, AI-generated or otherwise, could destroy without warning. Microsoft gave Darcy a replacement laptop as thanks. Everyone else on an affected configuration is responsible for closing the gap themselves.
Comments
Please log in or register to join the discussion