Microsoft has mostly repaired flaw in Surface hardware that allowed unprotected devices to be bricked by a single packet

Jump to main content

Search

REG AD

SECURITY

Surface studio laptop gif

Microsoft has mostly repaired flaw in Surface hardware that allowed unprotected devices to be bricked by a single packet

And it was Microsoft Copilot that unwittingly revealed the longstanding vulnerability

Thomas Claburn

Thomas<br>Claburn

Senior reporter

Published<br>fri 12 Jun 2026 // 14:05 UTC

EXCLUSIVE For the past 90 days, Microsoft has been quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot.<br>And the company's Copilot AI software inadvertently helped identify the faulty firmware.<br>According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware.

REG AD

"Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register.

REG AD

The SAM or SSAM is the embedded controller used in Surface devices. And as our source explained, Microsoft’s implementation of the controller in Surface devices did not include any defense against arbitrary write values.

MORE CONTEXT

It blocked us at 'hello!' Anthropic Fable 5 refusing innocuous prompts

Angry bug hunter with Microsoft beef drops new Windows 0-day

Vercel escapes contempt rap after admitting it botched FBI warrant response

GitHub pulls pin on npm's auto-run scripts

Microsoft does not consider the bug to be a practical threat. "There is no realistic attack scenario with this issue," a spokesperson told The Register. "In order to successfully exploit it, an attacker would need to interact with specific drivers and send commands to a hardware interface. This would require administrator privileges on the machine, as well as disabling the Secure Boot feature. With this access, they could perform any number of actions."<br>Commonly, Darcy said, digital devices require holding a button down or connecting a jumper cable to enable arbitrary write access. But that security check is absent in Surface devices, we're told, enabling Copilot to vandalize the firmware in the absence of Secure Core and Secure Boot. Essentially, the probing triggered an update command from the SAM that overwrote the UEFI and Secure Boot firmware.<br>Surface devices treated to this sort of probing should continue to operate because the SAM was already initialized and is running in RAM. But upon reboot, when the SAM tries to reload using corrupted data in its non-volatile storage, it will fail to initialize, and the system will be unable to Power-On Self-Test (POST).<br>The Python script crafted by Copilot on the security researcher's Surface device iterated blindly over a particular Target Category and the set of Command ID (CID) pairs, sending empty/null payloads to WRITE commands.<br>The result, Darcy explained, is that the SET Feature Report was called with null payload, the Output Report was called with null payload, and other CIDs were hit by SET commands that wrote garbage data.<br>As a result, the device became inoperable. We're told this has been a common complaint about Surface devices online support forums over the years, though we have no way to determine whether boot failures reported for other Surface devices can be attributed to this specific problem.<br>Many Surface hardware issues reported publicly appear to be fixable through various troubleshooting techniques. But devices made inoperable by SAM access, our source insists, are permanently bricked – a situation that can entail hundreds of dollars in repairs for a new motherboard. No USB, no factory reset, no access to the BIOS/UEFI, we're told.

REG AD

Darcy said that the SAM Bus is terribly designed.<br>"There is no way to see the current value without scanning the bus," he said. "But scanning the bus kills the unit."<br>The problem is that the CIDs, which are like APIs for the SAM, have been interleaved in a way that's dangerous.<br>"If all the reads were grouped together (say, CIDs 0x01–0x0F) and all the writes were grouped separately (say, CIDs 0x10–0x1F), a probe script could safely scan the read range without ever accidentally wandering into write territory," Darcy said. "You could even put a simple bounds check in your code: 'only probe below 0x10.' Done. Safe.<br>"But because reads and writes are interleaved in the same numbering space, there is no safe range to probe. You literally cannot scan even two consecutive CIDs without a...