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.
And the company’s Copilot AI software inadvertently helped identify the faulty firmware.
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.
“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.
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.
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.”
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.
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).
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.
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.
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.
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.
Darcy said that the SAM Bus is terribly designed.
“There is no way to see the current value without scanning the bus,” he said. “But scanning the bus kills the unit.”
The problem is that the CIDs, which are like APIs for the SAM, have been interleaved in a way that’s dangerous.
“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.
“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 coin-flip chance of hitting a write command. The moment you decide to enumerate what’s available, you’re already firing blind writes, because the command space gives you zero structural information about which operations are safe and which are destructive.”
Managed devices not at risk
The Register asked Microsoft about our source’s claims on March 10, 2026. A company spokesperson reiterated a prior suggestion that the researcher contact the Microsoft Security Response Center (MSRC), an effort our source found too cumbersome. Rather than publishing details about what might have been a potential zero-day flaw – we were uncertain about the Secure Boot/Secure Core requirement at the time – The Register reached out to internal Microsoft sources in an effort to get someone’s attention.
By March 12, with the help of Microsoft media relations, we managed to coordinate a conversation between Darcy and Madeline Eckert, senior program manager with MSRC. Microsoft subsequently acknowledged the vulnerability and committed to issuing a fix. The Register in turn agreed to delay publication for 90 days while repairs were made. We’re told most affected devices have been updated (via Windows Update), or will receive updates in coming weeks. The issue did not meet the bar for a CVE, according to the company.
“We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure,” a Microsoft spokesperson said in a statement. “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. We have released updates to address the issue for most impacted devices.”
That means managed devices are not at risk.
But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven’t received the update.
We’re uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested.
Microsoft moving Surface to Rust
One of the things we learned from Darcy during the effort to get this issue patched is that Microsoft is planning to move the Surface stack to Rust. We understand from David Abzarian, chief architect for Microsoft Surface, that work is underway to transition future Surface for Business hardware to a more secure architecture based on Rust code.
“Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers,” said Abzarian in a statement provided to The Register. “We’re investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively.
“We’re also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency.”
Asked to comment, Darcy said, “The fact that a device can be destroyed, irreparably from userspace is… certainly an interesting design decision. While I applaud Microsoft for their beautiful, and innovative Surface series, a little more innovation around verifying incoming data at the firmware level would have been greatly appreciated.”
We’re told Microsoft provided Darcy with a Surface laptop as a show of appreciation. ®
