Usbliter8 Breaks the iPhone XS and 11 and Apple Cannot Patch It

usbliter8 takes control of the iPhone XS and iPhone 11 before iOS even loads, and no update Apple ships can ever close it.

The flaw lives in the SecureROM, the first piece of code a device runs the moment it powers on. That code is burned into the chip at the factory and cannot be rewritten afterward. A device that gets hit stays exploitable through iOS updates, full restores and reboots, for as long as it stays in service.

It comes down to four chips: the A12 and A13 in iPhones and iPads, and the S4 and S5 in some Apple Watches. The affected models:

• → iPhone XS, XS Max and XR, on the A12
• → iPhone 11, 11 Pro, 11 Pro Max and the second-generation iPhone SE, on the A13
• → iPad Air 3, iPad mini 5 and iPad 8 on the A12, plus iPad 9 on the A13
• → Apple Watch Series 4, 5 and the first-generation SE, on the S4 and S5

The HomePod mini, the Apple TV 4K and the Studio Display run the same silicon, but the published exploit does not target them, and getting at them over USB is a far harder job than plugging into an iPhone. The hands-on attack lands on the phones, tablets and watches. The A12X and A12Z in the 2018 and 2020 iPad Pro share the same core and could be reachable, though the team has not built that part yet. Devices on the A14 or newer sit outside this. The A11 and older were already covered years ago by a different exploit called checkm8.

The bug is not in Apple’s own code. It sits in a part Apple buys from someone else. The USB controller inside these chips is the DesignWare DWC2, made by Synopsys, and it has a counting mistake in how it stores incoming data. When a device is in DFU mode, the controller writes small chunks of USB data into memory and moves a pointer forward after each one. After a few packets it resets that pointer back to the start, the way a ring buffer is supposed to. The trouble is the math. The amount it moves forward does not match the amount it moves back, and the controller also accepts packets smaller than the USB rules allow. Feed it the right undersized packets and the pointer walks backward into memory it was never meant to reach, which means that region can be overwritten with attacker-controlled data.

There is a second reason this works, and it is the thing that decides which chips are in danger and which are safe. Think of DART as a guard that is supposed to stand between the USB controller and the chip’s memory. On the A12 and A13, while the SecureROM runs, that guard is set to wave everything through, a mode called bypass. Nothing gets checked, and the memory can be rewritten. The A11 is safe for its own reason, because its USB driver puts the memory address back after each packet, so the pointer never wanders. The A14 and newer are safe because the guard is doing its job from the start. Same family of chips, one switch, three different endings.

Neither piece is enough on its own. The Synopsys bug needs memory it can reach, and that memory only opens up because Apple set DART to bypass. Apple did not write the flawed controller, and Synopsys did not choose the bypass setting. usbliter8 only works because both are true at the same time.

A regular Mac or PC cannot trigger this on its own, because its USB stack will not send the malformed packets the bug needs. So the exploit runs from a small board built around Raspberry Pi’s RP2350 chip, wired to a Lightning cable. Once the target is in DFU mode and plugged into that board, the run takes under two seconds, before Apple’s signed boot process gets a chance to start.

On the A12 and the Watch chips, getting from there to full control is short work. The attacker overwrites a saved return address on the stack, and the next time the system switches back to the USB task it jumps wherever the attacker points it. A small chain of reused instructions handles the rest.

The A13 is a harder target, and it is where most of the work went. Apple built a check into that chip that watches the addresses the code jumps back to and refuses any that have been tampered with. It is called PAC, short for Pointer Authentication, and it stops the attacker from simply swapping an address out the way they could on the A12. So the team went around it in stages instead of straight at it.

Getting there took a handful of careful steps. They corrupted some heap data sitting just before the buffer to earn a few limited writes, then used those to switch off a check that would otherwise crash the device. Next they rigged the crash handler so a panic would loop forever instead of rebooting, which kept the device alive in a broken state. From there they timed their memory writes until they could overwrite the pointer to the USB interrupt handler. Once that pointer belongs to the attacker, the next USB interrupt runs their code. Both paths end the same way, with the attacker running code at EL1, the chip’s privileged mode, inside the SecureROM itself.

From there the exploit cleans up after itself and hands back a device that looks normal but answers to a custom handler. Two extra commands come with it. One quietly drops the chip into a lower-security state until the next reboot, what the tool calls demoting production mode. The other boots a raw iBoot image with the signature checks skipped, which is what lets unsigned system software run.

1
2
3

usbliter8ctl [-h] {boot,demote}
  boot     boot raw iBoot
  demote   demote production mode

The exploit also tags the device so a compromised unit identifies itself. It writes a marker into the USB serial number, the same move checkm8 made in 2019, so it shows up the moment someone reads the descriptor:

1
2
3
4

CPID:8020 CPRV:11 CPFM:03 SCEP:01 BDID:0E
ECID:XXXXXXXXXXXXXXXX IBFL:3C
SRTG:[iBoot-3865.0.0.4.7]
PWND:[usbliter8]

One detail separates this from a permanent compromise. This is a tethered exploit. The custom handler and the PWND tag last only until the device reboots. After a restart it comes back up normal, and getting unsigned code running again means reconnecting it to the board and exploiting it a second time. What lasts for the life of the device is the flaw in the silicon, not the access. The bug can be used again any time, but the foothold does not survive a reboot on its own.

Paradigm Shift is a European company that builds and sells exploits to defence and law enforcement clients, with a team of more than forty researchers. They published usbliter8 on 18 June 2026 after coordinating the disclosure with Apple Product Security, and it is the first research the company has ever published. A business that normally sells this kind of work behind closed doors chose to give its debut away for free, with working code attached. Its careers page lists openings for iOS exploit researchers.

The bug reaches past Apple alone. The USB controller behind it was bought in, not built in house. Synopsys makes it, and they sell that same design to a long list of other chipmakers, where it ends up in phones, gadgets and all kinds of embedded hardware. The researchers say the underlying flaw could sit in other devices too, just under different conditions. Apple was the target this time. That controller lives in plenty of other chips, and the same weakness could be there too.

That little RP2350 board has its own story. Back in 2024, Raspberry Pi was so sure the chip was locked down that they put it on stage at DEF CON and dared people to break in. They hid a secret inside and said come and get it. Someone did, later that year. They messed with the chip’s power at just the right instant, a trick called glitching, and pulled the secret straight out. And now that same chip is the tool being used to break into an iPhone.

For someone just carrying one of these phones around, the risk stays low, because the attack needs hands on the device and someone has to put it into DFU mode on purpose. There is a separate part of the chip called the Secure Enclave that holds your passcode and your encryption keys, and this attack does not break it. Breaking the boot chain does not hand over your data. The researchers do warn that getting in this deep brings an attacker closer to the Secure Enclave, even without cracking it directly. That part has not been shown yet.

Normally a bug like this gets a paper trail. A CVE number to track it, a severity score, an advisory from the vendor, maybe an alert from CISA. usbliter8 has none of that, and there are no reports of it being used in the wild. That looks like an oversight, but there is a simple reason for it. Those systems exist to chase down fixes. There is no fix here, so there is nothing to chase. Apple has stayed quiet in public too. Reporters asked, and got nothing back.

checkm8 did not stay a research curiosity. It became the base for jailbreaks and for forensic tools that pull data off seized iPhones, and that build-out took years. usbliter8 brings the A12 and A13 into the same territory, though for now it is a proof of concept rather than a jailbreak. The method is public, a finished tool is not.

On the question of what to do, the honest answer is that no software fixes this. For a device in a sensitive role, the only mitigation that holds is moving to A14 hardware or newer, where this does not apply. Until then, the defense is physical.

• → Keep affected devices in hand. Do not leave them unattended at borders, in repair, or with people you do not trust.
• → Avoid DFU mode over USB cables and ports you do not control.
• → Take inventory of any A12, A13, S4 and S5 devices in roles that matter, and plan a refresh to A14 or newer.
• → Keep strong passcodes and current iOS. They do not touch this flaw, but they still matter against other attacks.

Breaking into a machine, going from a normal user to full control, and keeping a foothold that survives the next reboot are the moves behind exploitation, post-exploitation and persistence. That is the ground my ethical hacking course walks through, step by step:

• → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Paradigm Shift | GitHub