"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," Jack Darcy said.
How a routine probe turned a Surface into a brick
Security researcher Jack Darcy says a seemingly ordinary attempt to adjust backlighting on a Surface laptop produced a Python script from Microsoft Copilot that overwrote embedded controller firmware and rendered the machine inoperable. According to Darcy, the Copilot-generated code sent raw SSAM ioctl commands to the SAM microcontroller, iterating blindly across Target Category and Command ID (CID) pairs and delivering null or garbage payloads to WRITE commands. The immediate effect: the SAM updated its non-volatile storage with corrupted data and, while the device continued to run in RAM, the unit failed to initialize on reboot and could not complete POST.
SAM/SSAM design and the danger of interleaved CIDs
Darcy describes the SAM (also called SSAM in the reporting) as an embedded controller whose command identifiers mix reads and writes in the same numbering space. He said that because reads and writes are interleaved, "you literally cannot scan even two consecutive CIDs without a coin-flip chance of hitting a write command." In Darcy’s account, there is no external hardware requirement—no button hold or jumper—to gate arbitrary writes. The result, he warned, is that simple enumeration of the command space can trigger destructive WRITE operations and, in some cases, irreversibly brick devices.
Microsoft’s assessment, coordination, and remediation
Microsoft acknowledged the issue after The Register coordinated a conversation between Darcy and Madeline Eckert of the Microsoft Security Response Center (MSRC). The company described the root cause as a "deprecated UEFI interface [that] could trigger a boot loop on some devices" and said it had released updates "to address the issue for most impacted devices." A Microsoft spokesperson told The Register, "There is no realistic attack scenario with this issue," clarifying that successful exploitation requires administrator privileges and disabled Secure Boot, and that attackers with that level of access could already perform many actions.
The Register contacted Microsoft on March 10, 2026, and with the company’s assistance coordinated a March 12 conversation that led to Microsoft committing to a fix. Publication was delayed for 90 days while repairs were made. Microsoft said the issue did not meet the bar for a CVE and that most affected devices have been updated via Windows Update or will receive updates in the coming weeks.
What this means for Linux users, managed devices, and gamers
- Linux users and those who have disabled Secure Core or Secure Boot may remain vulnerable if their systems have not yet received Microsoft’s update, because the exploit path requires Secure Boot to be disabled.
- Managed enterprise devices, Microsoft said, are not at risk because updates are distributed and Secure Boot is typically enforced; the company noted "managed devices not at risk."
- Users who disable Secure Boot for gaming, install custom Windows drivers, or enable USB boot may be exposed until their Surface firmware receives the patch.
Longer-term changes: Secure EC and Project Patina in Rust
During the reporting process Microsoft disclosed plans to rework the Surface firmware stack using Rust. David Abzarian, chief architect for Microsoft Surface, said the company is "building our embedded controller firmware from the ground up in Rust" as part of an initiative called Secure EC, and is rewriting the UEFI DXE Core in Rust under Project Patina. Abzarian added that Microsoft is shipping some drivers written in Rust and helping co-develop the Windows Drivers in Rust (WDR) framework. Those efforts are framed as an architectural shift intended to improve reliability and security and will be contributed to the Open Device Partnership (ODP) as open-source work, the company said.
Darcy accepted Microsoft’s outreach; the company provided him with a Surface laptop as a gesture of appreciation.
The immediate technical takeaway is stark: arbitrary user-space writes to an embedded controller interface were able to destroy non-volatile firmware state and force an unrecoverable boot failure unless the device had been protected by Secure Boot and related platform defenses. Microsoft’s fixes appear to have reached many affected devices, but the company’s own description leaves several concrete points open — including the full list of impacted Surface models and whether ARM-based devices behave the same way — even as it moves to redesign the firmware stack in Rust.
Original report: The Register — Microsoft has mostly repaired flaw in Surface hardware that allowed unprotected devices to be bricked by a single packet
