"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 told The Register.
Copilot's accidental probe and a firmware overwrite
That sentence — from Jack Darcy, an Australian security researcher — describes how a routine attempt to adjust screen backlighting on a Surface device turned destructive. Darcy asked his instance of Microsoft Copilot for a Python script; the Copilot-generated code probed the device’s SAM (SSAM) embedded controller and issued a series of SET and WRITE commands. According to Darcy, the scripts sent null or empty payloads to WRITE commands and iterated across Target Category / Command ID (CID) pairs, which ultimately triggered the SAM to perform an update that overwrote UEFI and Secure Boot firmware. The immediate system continued to run until reboot; on restart the SAM failed to reinitialize from corrupted non‑volatile storage and the device would not POST.
The SAM bus design and interleaved CIDs that make probing dangerous
Darcy described the SAM bus as "terribly designed," arguing the numbering space interleaves read and write CIDs so there is no safe range to enumerate. In his words, "you literally cannot scan even two consecutive CIDs without a coin‑flip chance of hitting a write command." He contrasted that with a safer design in which reads and writes are grouped separately so a probe could bound its scan to read‑only commands. Because Surface devices lacked that protection, blind enumeration by the Copilot script resulted in writes that corrupted the embedded controller’s stored firmware. Darcy said units so affected are permanently bricked: no USB recovery, no factory reset and no access to BIOS/UEFI; repair typically requires a new motherboard that can cost "hundreds of dollars."
Microsoft's assessment, coordinated disclosure and remediation
Microsoft told The Register it does not view the issue as a practical threat. A company spokesperson said: "There is no realistic attack scenario with this issue," adding that exploitation would require administrator privileges and Secure Boot being disabled — conditions under which "they could perform any number of actions." Microsoft’s investigation identified a deprecated UEFI interface that could trigger a boot loop on some devices and the company committed to issuing updates. Microsoft did not assign a CVE to the issue.
The Register contacted Microsoft on March 10, 2026; after additional coordination, Darcy spoke with Madeline Eckert, senior program manager with the Microsoft Security Response Center (MSRC). Microsoft acknowledged the vulnerability, committed to fixes and provided the Register a window for coordinated publication — the outlet agreed to delay publication for 90 days while repairs were issued. Microsoft said most affected devices have been updated via Windows Update, and remaining devices will receive updates in the coming weeks.
Which Surface models and users are at risk
Darcy indicated the flaw appears broadly present across Surface hardware: Surface Laptop models 3–6 and Surface Book models 1–3 were mentioned as affected; Surface Go models appeared not to be affected. ARM variants had not been tested, the Register reported. Microsoft emphasized that managed devices are not at risk. The company and Darcy noted that users who run Linux on Surface devices, or Windows users who have disabled Secure Core and Secure Boot (for gaming or to load custom drivers), or those who enable USB boot, may remain vulnerable if they have not received the Microsoft update.
Microsoft's move to Rust: Secure EC and Project Patina
As part of its response and wider engineering work, Microsoft is transitioning parts of the Surface firmware stack to Rust. David Abzarian, chief architect for Microsoft Surface, told The Register that work is underway to build embedded controller firmware in Rust (Secure EC) and to rewrite the UEFI DXE Core in Rust under "Project Patina." Abzarian said Microsoft is also shipping some drivers written in Rust and helping to co‑develop the Windows Drivers in Rust (WDR) framework, while contributing to the Open Device Partnership (ODP). Those efforts, he said, are intended to provide a "more secure architecture" and greater transparency through open source.
What this means for Windows administrators, Linux users, and security researchers
- Windows administrators: Managed fleets that receive Windows Update are expected to be protected; Microsoft specifically noted managed devices are not at risk. Administrators should verify updates have been applied, especially where Secure Core or Secure Boot has been disabled for enterprise compatibility.
- Linux users and hobbyists: Devices running Linux or configured with Secure Boot disabled, USB boot enabled, or custom drivers may remain vulnerable until they receive Microsoft’s update. Darcy’s account underscores the risk of user‑space operations touching low‑level embedded controller interfaces.
- Security researchers: The episode illustrates how automated code generation tools can interact with under‑documented hardware interfaces in unpredictable ways. Darcy said he found MSRC’s reporting process cumbersome; Microsoft later engaged and provided a Surface laptop to him as a gesture of appreciation.
Microsoft's patches and a planned rewrite of core components in Rust aim to reduce the chance of similar failures, but questions remain in the record: ARM variants were untested and the full range of affected units is uncertain. For now, the immediate technical facts are stark — an embedded controller interface that allows arbitrary writes, Copilot‑generated probes that can trigger firmware overwrites, and a set of mitigations that depend on Secure Boot remaining enabled and devices receiving updates.
