A team of security researchers just published a working exploit for Apple's SecureROM on A12 and A13 chips. The iPhone XS, iPhone 11, and several other devices from that generation are affected. The exploit is called usbliter8. It is real, the proof of concept is public, and there is no software patch coming because the bug lives in read-only memory burned into the silicon at manufacture time.

If you are holding an affected device, the only complete fix is to stop using it or accept that it can be compromised through the USB port. That is a weird sentence to type in 2026.

What SecureROM is and why it matters

Every iPhone has a tiny piece of code that runs before anything else. Apple calls it SecureROM, or BootROM. It is the root of the boot chain. It verifies the next stage, which verifies the stage after that, all the way up to iOS itself. If SecureROM is trustworthy, the whole chain has a solid foundation. If SecureROM has a bug, nothing above it can be fully trusted because an attacker who controls the first instruction can substitute every subsequent verification step with code of their own.

SecureROM is baked into the chip at the fab. It cannot be updated. It cannot be patched. It cannot be changed. Not being remotely modifiable is its main security property. The flip side is obvious: if it has a bug, that bug is permanent. Apple has known this since the beginning. They invest heavily in making sure SecureROM is correct before the silicon ships. But "making sure" is not the same as "guaranteed."

This is not the first BootROM vulnerability in Apple hardware. Geohot's limera1n exploit hit the A4 in 2010. The checkm8 exploit by axi0mX targeted A5 through A11 and was published in 2019. Those were significant. usbliter8 continues the pattern for A12 and A13, chips that shipped in 2018 and 2019 and are still in a lot of pockets.

How usbliter8 works

The exploit targets the USB controller in Apple's SoCs. Specifically, it exploits the DesignWare DWC2 USB controller made by Synopsys, which Apple uses in the A12 and A13.

Here is how it works. When a USB host sends Setup packets to the device, the DWC2 controller stores them in memory using DMA (Direct Memory Access). The controller stores up to three Setup packets and increments a DMA address register after each one. When a fourth Setup packet arrives, the controller resets the DMA address back to the starting position, like a ring buffer.

The bug is in that reset. The controller decrements the DMA address to return to the start, but it calculates the decrement based on how much data it thinks it wrote, not based on where the original buffer started. If you can manipulate the DMA address to point somewhere else before the fourth packet arrives, the "reset" will compute an address that is not where the buffer began. It will compute an address in memory that the attacker controls.

There is also a configuration flaw in Apple's firmware that the researchers combined with the hardware bug. The technical writeup goes into significant depth on the exploitation chain, including how they achieve code execution on the application processor after gaining control through the DMA manipulation. The full writeup is worth reading if you care about low-level exploitation.

The result: by sending specially crafted USB packets to an affected iPhone, an attacker can execute arbitrary code at the earliest stage of the boot process. What you do after that depends on your goals. A law enforcement agency might use it for forensic extraction. A thief might use it to bypass activation lock. A researcher might use it to run Linux on hardware Apple locked down.

What devices are affected

The confirmed affected SoCs:

The A12X and A12Z, used in some iPad Pro models, are technically vulnerable but the exploit does not currently implement support for them. The researchers say support is possible but they did not need it to validate the approach. Newer chips like the A14 and beyond are not affected as far as anyone knows.

Why this matters even if you have a newer phone

If you are reading this on an iPhone 16, you might be tempted to shrug. Your chip is fine. But the implications go beyond which specific phones have a bug this week.

BootROM vulnerabilities keep happening. This is the third major class of them in Apple hardware. Each time, the response is the same: the affected generation is permanently vulnerable, and you should buy new hardware. That worked when iPhones were replaced every two years. It works less well when people keep phones for five or six years. The iPhone XS came out in 2018. It still works. Plenty of people still use it. Telling them their device has an unpatchable security flaw and they need to buy a new one is not a great answer.

There is also the question of what this means for the used device market. A phone with a known BootROM vulnerability that allows forensic extraction is a different device than one without that vulnerability. Resale value, enterprise device policies, and recycling programs all have to grapple with this, and mostly they do not.

The "just buy new hardware" model works for Apple's revenue. It does not work for the people who cannot afford a new phone every three years, or for the environmental cost of short hardware lifecycles, or for the fundamental expectation that a device you bought should not have permanent unfixable security holes.

The physical access question

usbliter8 requires physical access to the device. Specifically, it requires a USB connection. An attacker needs to plug a cable into your phone. This is not a remote exploit. You cannot be hit over Wi-Fi or through a malicious website.

Physical access exploits get dismissed too easily. Yes, if someone has your phone in their hands and a USB cable, lots of things are possible. But "lots of things are possible" is not the same as "arbitrary code execution at the bootROM level is possible." The bar for what an attacker with physical access can achieve matters. Before usbliter8, someone with your A12 iPhone and a cable could try a lot of things but could not defeat the secure boot chain. Now they can.

Border crossings, law enforcement seizures, and supply chain attacks all involve physical access. A phone that can be fully compromised via USB in seconds is a different piece of hardware than one that resists that attack. The threat model depends on who you are and what someone might want from your device.

The Synopsys angle

The USB controller at the heart of this exploit is not made by Apple. It is the DWC2 by Synopsys, a widely used IP core. Other SoC vendors use it too. The researchers specifically note that details about how this controller works can be inferred from the Linux kernel driver for it.

Which raises a question: does the same hardware bug exist in other devices that use the DWC2 controller? The Apple-specific configuration flaw that makes the exploitation easier might not be present elsewhere, but the underlying DMA behavior is a property of the controller design, not of Apple's integration. I have not seen confirmation of other affected devices yet, but I would not be surprised if some appear.

This is a recurring problem with hardware IP cores. A bug in a widely licensed design becomes a bug in every product that uses that design. When a software library has a vulnerability, you pull a new version and rebuild. When a silicon IP core has a bug, every chip that already shipped has it forever. The economics of chip design, where licensing proven IP saves years and millions of dollars, make this kind of shared vulnerability inevitable.

What Filippo Valsorda's vulnerability essay missed (or anticipated)

On the same day usbliter8 was making the rounds on Hacker News, Filippo Valsorda published an essay arguing that vulnerability reports are no longer special. His thesis: LLMs can find potential vulnerabilities almost as well as human researchers now, so the scarcity of insight that made external reports valuable is gone. The bottleneck has shifted from finding bugs to triaging which ones are real.

usbliter8 is an interesting counterpoint. This is not an LLM finding. This is a deep hardware exploit that required understanding USB controller DMA behavior, Apple's specific Secure ROM configuration, and the interaction between the two. The kind of work that still requires a skilled human staring at hardware specs and data sheets for weeks. LLMs are getting better at suggesting where to look, but this particular bug was found and exploited by people who understand silicon at a level that current models do not.

Maybe that changes too. Maybe in two years, an LLM can point at the DWC2 datasheet and say "the DMA address reset in the Setup packet ring buffer looks suspicious." But we are not there yet, and Valsorda's general observation about software vulnerabilities does not extend cleanly to hardware. Hardware bugs are scarcer, more permanent, and harder to find. They also do not get fixed. That makes them both rarer and more important.

What to do if you have an affected device

The permanent bug problem

I keep thinking about the structural issue here. We have built a world where billions of devices contain read-only code that cannot be fixed when it is wrong. The assumption was that the code would be small enough and well-audited enough that bugs would be vanishingly rare. Checkm8 proved that wrong for A5 through A11. usbliter8 proves it for A12 and A13. The pattern is clear enough that I would not bet against someone finding a BootROM bug in A14 or A15 eventually.

Apple could mitigate this with a better hardware root of trust architecture. They could ship ROM alongside a small mutable region for patches. They could make the boot chain recoverable by allowing signed firmware updates even at the lowest level, as long as those updates go through the existing chain of trust. These are not easy engineering problems, especially when you need to prevent downgrade attacks, but they are solvable.

Right now, the message is: if a bug gets found in your BootROM, your hardware is done. Buy a new one. That is a fine message for a company that sells hardware. It is a bad message for everyone else.

The researchers who published usbliter8 did the right thing by going public. These vulnerabilities exist whether they are disclosed or not. The people who use affected devices deserve to know. The companies that build hardware deserve pressure to do better. Silence does not make the bugs go away. It just means the only people who know about them are the ones who will not tell you.