Microsoft Surface Firmware Flaw Allows Permanent Bricking via Single Packet

A firmware flaw in Microsoft Surface devices can permanently brick the hardware with a single packet when Secure Core and Secure Boot are disabled, security researcher Jack Darcy has disclosed. The vulnerability was discovered inadvertently when Microsoft Copilot generated a Python script that sent raw SSAM ioctl commands to the SAM embedded controller, overwriting UEFI and Secure Boot firmware. The SAM controller lacks defenses against arbitrary write values, and devices become inoperable after reboot with no recovery options.

The SAM (Surface Access Module) is the embedded controller used in Surface devices. Darcy explained that Microsoft's implementation did not include any defense against arbitrary write values. The probing triggered an update command from the SAM that overwrote the UEFI and Secure Boot firmware. Surface devices treated to this probing continue to operate because the SAM is already initialized and running in RAM, but upon reboot, when the SAM tries to reload using corrupted data in its non-volatile storage, it fails to initialize, and the system is unable to Power-On Self-Test (POST).

The Python script crafted by Copilot iterated blindly over a particular Target Category and set of Command ID (CID) pairs, sending empty/null payloads to WRITE commands. The result was 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. Darcy noted that this has been a common complaint in Surface device online support forums over the years, though it is unclear whether boot failures reported for other Surface devices can be attributed to this specific problem.

Devices made inoperable by SAM access 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 is possible. Darcy described the SAM Bus as terribly designed, noting that there is no way to see the current value without scanning the bus, but scanning the bus kills the unit. The CIDs, which are like APIs for the SAM, have been interleaved in a way that is dangerous. If all reads were grouped together and all writes separately, a probe script could safely scan the read range without accidentally wandering into write territory. But because reads and writes are interleaved in the same numbering space, there is no safe range to probe.

Microsoft does not consider the bug to be a practical threat. A spokesperson told The Register that there is no realistic attack scenario because an attacker would need administrator privileges on the machine and would need to disable Secure Boot. With that access, they could perform any number of actions. The issue did not meet the bar for a CVE, according to the company. Microsoft has been quietly patching the issue for the past 90 days, and most affected devices have been updated via Windows Update, with remaining updates expected in coming weeks.

The discovery highlights the risks of AI-generated code interacting with low-level hardware interfaces. While Microsoft downplays the practical threat, the vulnerability underscores the importance of hardware-level protections like Secure Core and Secure Boot, and the potential for AI tools to inadvertently cause damage when probing undocumented interfaces. The Register coordinated with Microsoft under a 90-day disclosure timeline to allow for repairs before publication.

Microsoft has now released updates via Windows Update for most affected Surface devices, though the company declined to assign a CVE, stating the issue did not meet its bar. The Register's 90-day coordinated disclosure reveals that the deprecated UEFI interface at the root of the bug can only be triggered when Secure Boot is disabled and the attacker already has administrator privileges. Researcher Jack Darcy detailed how the SAM bus's interleaved read/write command IDs make safe probing impossible, as scanning even two consecutive CIDs risks hitting a destructive write command that permanently bricks the device by corrupting UEFI and Secure Boot firmware.