usbliter8: Unpatchable SecureROM Exploit Breaks Apple A12 and A13 Boot Chain

Security researchers at Paradigm Shift have released usbliter8, a working exploit that achieves arbitrary code execution inside the SecureROM of Apple's A12 and A13 chips. That code is fused into the silicon at manufacture. No software update can reach it. The full technical write-up and a working proof of concept went public on June 18, 2026, after coordinated disclosure with Apple Product Security.

This is not a remote attack. It requires physical possession of a device in DFU mode, connected over USB to a dedicated RP2350-based microcontroller board. With that rig, the exploit finishes in under two seconds, before Apple's signed boot chain loads. The closest precedent is checkm8, the 2019 SecureROM exploit that permanently pushed A5-through-A11 devices outside Apple's patch authority. usbliter8 extends that condition to the next chip generation.

What the exploit reaches

The public PoC supports A12, A13, S4, and S5 SoCs. A12X and A12Z are described as theoretically possible but not yet implemented. That pulls a wide hardware range into scope, much of it still in daily and enterprise use.

• iPhone XS, XS Max, XR; iPhone 11, 11 Pro, 11 Pro Max; iPhone SE 2nd generation
• iPad Air 3rd gen, iPad mini 5th gen, iPad 8th gen
• Apple Watch Series 4 and 5, first-generation Apple Watch SE
• HomePod mini and other products built on the same chips

A11 is not affected. A14 and later appear to be out of reach for this exploit path.

The root cause

The bug lives in the Synopsys DWC2 USB controller. The controller stores incoming USB Setup packets via DMA, buffers up to three, then resets its write pointer on the fourth by decrementing it a fixed 24 bytes. It also accepts smaller-than-standard packets, advancing the pointer only by the bytes actually written. That mismatch accumulates into a repeatable buffer underflow, walking the write pointer backwards through memory 12 bytes at a time.

What makes it exploitable on A12 and A13 is how Apple configures the USB DART, the chip's IOMMU, inside SecureROM. On affected devices the DART runs in bypass mode, so the underflowing DMA pointer can reach and overwrite arbitrary SRAM. A11 escapes because its USB driver manually resets the DMA address after every packet, so the mismatch never builds. A14 and later appear to configure DART correctly, which Paradigm Shift says renders the bug unexploitable on newer hardware.

From underflow to privileged execution

On A12, the DMA buffer sits next to the USB task's stack on the heap. Overwriting a saved link register hands the attacker program counter control on the next context switch. A13 is harder: Pointer Authentication (PAC) protects stack-stored return addresses. Paradigm Shift bypassed it in stages, corrupting DART-related heap structures for limited write primitives, overwriting the panic depth counter so the chip loops on errors instead of rebooting, timing DMA writes to avoid clobbering saved registers, and finally overwriting the USB interrupt handler pointer in BSS. The next USB interrupt then ran attacker code. Either path ends at EL1, the chip's privileged mode, inside SecureROM.

What an attacker gets

Post-exploitation, usbliter8 injects a custom USB request handler and stamps PWND:[usbliter8] into the device's USB serial string. From there an attacker can temporarily demote the SoC's production mode or boot a raw, unsigned iBoot image with no signature checks, stepping outside Apple's chain of trust entirely. The research does not demonstrate a Secure Enclave compromise; the Enclave is a separate boundary, isolated from the application processor. Paradigm Shift warns, though, that BootROM-level control may open new routes for attacking it.

Who actually needs to act

For most users the practical risk stays low. An attacker needs the physical device, the right cable, and the knowledge to force DFU mode. For high-security environments the calculus changes: if a device runs one of the affected chips, the physical boundary is permanently gone, and safety now depends on controlling when and where the device can be plugged in. This is a device-custody and hardware-retirement problem, not a vulnerability you wait out for a fix.

The proof of concept is public. That is usually the moment exploit research stops being a demo and becomes someone else's tool. The window to inventory and retire affected hardware is open now, and it does not close on a patch Tuesday.