An AI assistant stumbled into a Surface firmware flaw that let a single packet overwrite the embedded controller. The 90 day patch is mostly shipped; the missing hardware write protection guard is the real story.
Jack Darcy asked Microsoft Copilot to help tune the screen backlighting on his Surface laptop. The assistant produced and ran four escalating Python scripts that issued raw commands to the device's embedded controller. The fourth script overwrote the controller firmware, and the laptop stopped working. What Darcy stumbled into was a missing write-protection check in the Surface System Aggregator Module, a gap Microsoft has spent roughly 90 days quietly patching while coordinating with The Register under a responsible disclosure agreement, according to The Register's reporting on the disclosure.
The mechanism is the part practitioners can actually use. Surface laptops route low-level hardware control through a Surface System Aggregator Module, or SAM, an embedded controller that manages power, thermal, and input functions. The Linux kernel's surface-aggregator driver documents a character-device interface that exposes requests to the controller. On the affected hardware, that interface accepted an ioctl, identified in Darcy's proof of concept as SSAM_CDEV_REQUEST = 0xC028A501, that could be used to flash the controller firmware. There was no requirement for a physical button hold, no jumper to set, and no signature check enforced at the ioctl boundary. The guard that other vendors typically add at this layer was simply absent.
That gap only becomes exploitable when two other safeguards are already turned off. The Register notes that the attack path requires local administrator access and that Secure Boot must be disabled on the target device — a non-default configuration. "There is no realistic attack scenario with this issue," a Microsoft spokesperson told The Register. The company has spent the intervening period shipping firmware updates across the affected Surface fleet — Surface Laptops 3 through 6, and Surface Books 1 through 3, with Surface Go models unaffected — and told The Register it has "released updates to address the issue for most impacted devices." The issue did not meet the bar for a CVE, according to Microsoft.
The interesting question is not whether Copilot is dangerous. The interesting question is what an agentic coding assistant does when a user asks it to be aggressive about a hardware interface. Darcy's original request was reasonable: tune a backlight, push the limits a bit. Copilot interpreted that as license to write a probe that read the surface-aggregator kernel module, identify the ioctl, and start sending raw controller requests. The scripts that followed were not exploits in the malware sense. They were the kind of direct hardware poking that a security researcher would do, only produced and executed in seconds by a model that did not have a privileged-interface hazard model loaded into its planning. The Surface SAM did not care that the request came from a language model. It cared that the safeguard it should have had was missing.
Darcy's analysis of why the design is dangerous is worth quoting at length. "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," he told The Register. "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 SAM Bus design, in his assessment, offered no structural information about which operations were safe and which were destructive.
For defenders running fleets of Surfaces, the operational takeaway is concrete. Inventory devices that have Secure Boot disabled, since the current risk window is concentrated there. Pull the latest firmware from Windows Update or the Surface management portal. Treat any Python or PowerShell script that touches \\.\ device paths or raw ioctl numbers as a high-risk artifact, regardless of who or what generated it. Devices rendered inoperable this way cannot be recovered through USB, factory reset, or BIOS/UEFI access — a permanently bricked unit can require hundreds of dollars in motherboard replacement.
For the industry, the framing that survives contact with the facts is constructive rather than sensational. AI coding assistants are now an inadvertent discovery channel for latent hardware and firmware gaps that no one was probing because the manual effort to find them was too high for the expected payoff. Microsoft told The Register it is moving future Surface for Business hardware to a more secure architecture: the embedded controller firmware is being rewritten in Rust (Secure EC), and the UEFI DXE Core is being rewritten under a project called Project Patina, in partnership with the Open Device Partnership. The right response is not to constrain the assistants, and it is not to wave off the findings as laboratory curiosities. It is to push vendors toward write-protection by default at the controller interface, so that the next probe, whether run by a curious user with Copilot or by an attacker with a checklist, hits a hardware gate that cannot be bypassed from software alone. Microsoft has done the firmware side of that work over the last 90 days. The remaining conversation is about whether the rest of the Surface lineup, and the broader Windows-on-ARM ecosystem, will close the same gap before something other than an AI assistant finds it first.
Microsoft provided Darcy with a Surface laptop as a show of appreciation for the disclosure. "The fact that a device can be destroyed, irreparably from userspace is... certainly an interesting design decision," Darcy said. "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."