Security researchers at Paradigm Shift have published a working exploit, dubbed usbliter8, that achieves arbitrary code execution inside the SecureROM of Apple's A12 and A13 chips.
That code is burned into the silicon at manufacture. No software update can reach it. Affected devices will carry this flaw for as long as they stay in use.
This is not a remote attack. It requires physical possession of the device, which must be in DFU mode and connected via USB to a dedicated RP2350-based microcontroller board. With that setup, the exploit finishes in under two seconds, before Apple's signed boot chain loads.
Affected Devices
The public PoC supports A12, A13, S4, and S5 SoCs. A12X and A12Z support is described as theoretically possible but not yet implemented.
Device families in that range include the iPhone XS, XS Max, and XR; the iPhone 11, 11 Pro, 11 Pro Max; the iPhone SE (2nd generation); the iPad Air 3rd gen, iPad mini 5th gen, and iPad 8th gen; Apple Watch Series 4 and 5; the first-generation Apple Watch SE; the HomePod mini; and other Apple products built on those chips. A11 is not affected. A14 and later appear to be out of reach for this exploit path.
The Bug
The root issue is a hardware flaw 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 by a fixed 24 bytes. It also accepts smaller-than-standard packets, incrementing the pointer only by the actual bytes written. That mismatch accumulates into a repeatable buffer underflow, stepping the write pointer backwards through memory 12 bytes at a time.
What makes this exploitable on A12 and A13 is how Apple configures the USB DART (Device Address Resolution Table, the chip's IOMMU) inside SecureROM. On affected devices, it runs in bypass mode, so the underflowing DMA pointer can reach and overwrite arbitrary SRAM.
A11 is not affected because its USB driver manually resets the DMA address after every packet, so the mismatch never accumulates. A14 and later appear to configure DART correctly, which Paradigm Shift says makes the vulnerability unexploitable on newer hardware.
Getting Code Execution
On A12, the DMA buffer sits adjacent 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 created limited write primitives. Overwriting the panic depth counter made the chip loop on errors instead of rebooting. Careful DMA write timing avoided clobbering the USB task's saved registers.
The final step overwrote the USB interrupt handler pointer in BSS. The next USB interrupt then ran attacker-supplied code. Either path ends with execution 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 show a Secure Enclave compromise. Apple's Secure Enclave is designed as a separate protection boundary, isolated from the application processor. Paradigm Shift warns that BootROM-level control may open new routes for attacking it.
No Software Patch
The closest public precedent is
checkm8, the 2019 SecureROM exploit that permanently put A5-through-A11 devices outside Apple's patch authority.
Like checkm8, usbliter8 requires physical access and DFU mode and cannot be closed with a firmware update. usbliter8 extends that condition to the next chip generation.
As of June 19, 2026, no CVE, CVSS score, Apple security advisory, or CISA alert had been issued, and no in-the-wild exploitation had been publicly reported.
For most users, the practical risk is low: an attacker needs the physical device, the right cable, and the knowledge to force DFU mode. For high-security environments, this is now a hardware-retirement and device-custody problem.
If a device runs one of the affected chips, the physical boundary is permanently gone; safety depends on controlling when and where the device can be plugged in. Inventory A12, A13, S4, and S5 hardware in sensitive roles, prioritize refreshes toward A14 or newer, and avoid DFU mode over untrusted USB cables or hosts.
The code is public. That is usually how exploit research stops being a demo and starts being someone else's tool.
<small>Source: The Hacker News</small>
