Cellebrite Advanced Unlocks

I’ve obtained a Cellebrite document 1 marked CONFIDENTIAL 2 that describes a “breakthrough method” to provide AFU access to iPhone 11-16 on iOS 26-26.4+, with expanded coverage promised.

Cellebrite calls it Advanced Unlocks (AU from here on), not to be confused with the “advanced unlocking services” they’ve marketed for years. A press release from earlier this year confirms AU is a new product for 2026.

According to Cellebrite, AU:

is a “ -generation AFU vector that is more resilient to Apple’s OS changes”

works with Stolen Device Protection enabled, which tightens USB restrictions 3

is enabled by a dedicated appliance with a stated range (!) of 8 meters

The document dates from March 2026, last revised September 15. Conspicuously missing: the iPhone 17 and Air, out for a year 4 . (The 18 Pro wasn’t out yet.)

The rest of this post is a whole lot of speculation. You’ve been warned!

This sure looks like a proximity-based radio capability if you ask me.

I went down many rabbit holes trying to make sense of things. For a variety of reasons, the modem and NFC didn’t fit; Bluetooth did 5 . Every supported iPhone had a Broadcom chip, so for a while I was sure it was a bug specific to one chipset family. Later, I convinced myself it was a hardware-agnostic Bluetooth-to-UWB chain. However, finding the exact vulnerabilities that enable AU seemed infeasible.

Then I looked at when AU’s iOS support stalled. “26.4+” might just mean “and newer, trust us.” But the gap between the newest iOS and what AU explicitly claims has only widened:

If an update broke AU, it most likely shipped in 26.5. So I diffed it.

I compared the bluetoothd binary from iOS 26.4 (build 23E246) and 26.5 (build 23F77). bluetoothd is the daemon that manages every Bluetooth connection on the phone. It’s a big, privileged process, with a broad set of entitlements.

There’s a small cluster of security-relevant changes in this daemon in 26.5, every one in L2CAP 6 – the multiplexing layer that sits between the Bluetooth radio and everything above it:

L2CAP signaling PDUs 7 are processed before pairing – any device in BLE range can send them, no user interaction required.

One fix stands out: a use-after-free (UAF) in the L2CAP channel manager. The receive loop for aggregated L2CAP packets iterates over connections and calls each connection’s PDU handler 8 . In 26.4, if a handler freed its connection object mid-iteration, the loop kept going with a dangling pointer – a textbook shape for turning a memory bug into code execution 9 . I haven’t built a proof-of-concept exploit for this, but it’s a strong candidate for what we’re looking for.

The vulnerable code has been present since at least iOS 17 (September 2023) and was likely made easier to exploit in iOS 18, when Apple restructured the L2CAP connection manager.

26.5 also tightened a few other L2CAP paths (signaling-parser bounds checks, transport-switch validation), but none of them look like a candidate for AU.

The hardening didn’t stop there. 26.6 added bounds checks elsewhere in the Bluetooth stack (HCI event handling). iOS 26.7 and 27 fixed CVE-2026-65414 , a separate uncredited Bluetooth RCE that lands in the same aggregated-packet receive path, except earlier. Apple hardened this exact code in 26.5 and still had an RCE sitting in it two releases later. Have they found them all?

Putting it together, the theorized AU chain looks like this:

Cellebrite positioned AU as “more resilient to Apple’s OS changes,” – if an iOS patch a few months later killed it, well, that’s pretty funny. (Also, interesting timing… any journalists out there want to dig into that chain of events?)

AU’s named range of models (11-16) continues to leave out the entire 17 generation after three flyer revisions over six months. That reads like a wall, not a backlog. What could explain this?

If AU was reliant on Broadcom components, we would expect the 17e to be supported, since it didn’t make the swap to Apple’s N1.

MIE is the only change that covers every missing phone. It makes memory-corruption bugs harder to exploit; it covers the kernel and many userland processes including bluetoothd . The vulnerable bluetoothd binary is byte-identical on MIE and non-MIE devices at the same iOS build. MIE is the likeliest explanation for the model cutoff. 11

For the theorized chain above, MIE makes step two ~94% likely to be blocked per attempt 12 – failure crashes bluetoothd and resets the BLE connection. It’s not a magic bullet defense here though because an attacker in a lab environment can likely repeat this step for a few minutes until they get lucky. Step three may face the same odds if it relies on a memory-corruption bug to reach the kernel; failure there is worse – a kernel panic reboots the device into BFU, where the encryption keys held in memory during AFU are gone.

A separate Cellebrite document from March 2026 (withheld) attributes “iPhones 11-16 running iOS 26+” to AU specifically, while listing the 17 under their general Inseyets capability (consent extractions, etc.) The 17 isn’t absent because Cellebrite can’t touch it; it’s absent from AU because this method doesn’t work on it.

Did a new hardware defense show up just in time to collide with the supposedly software patch-resistant AU? That’s pretty funny, too.

To be charitable to Cellebrite: maybe they just haven’t finished expanding support. Their 2024 matrix listed the iPhone 15 as CAS-only 13 ten months after it shipped, so running a generation behind has precedent. But in that case, why not add a qualifier to the model range such as “coming soon” or “in development”?

So Apple quietly fixed a nasty vulnerability reachable over the air in iOS 26.5, yet they made no mention of it in the security bulletin. 14 Sometimes they retroactively update the bulletins, or mention a patch without crediting a researcher (presumably because the issue was found internally) – but they did neither of those for this fix. Why? (It’s not the first time. )

If they wanted to keep it hush-hush, it worked. I haven’t found any public discussion of these vulnerabilities or changes. You can’t help but wonder what other fixes we don’t know , and why Apple decided not to disclose them.

Apple usually discloses fixes like this. Cellebrite usually keeps specifics behind closed doors – the document itself says full details are shared only in a meeting. This time, the roles reversed.

Despite their pedigree, Cellebrite now feels the need to establish credibility up front. As the average iPhone gets harder to break, vague claims unlocking iPhones stop commanding attention. Mainstay techniques like the checkm8 exploit (2019) are past their shelf life in 2026.

Apple’s hardening efforts are paying off. Charging ports have historically been the default vector for forensics tools, but they’re becoming less viable; attackers are being forced onto less appealing paths. Has the Bluetooth front now closed, too, or are things just getting started? Where will the battle be fought?

Note: I’ve been working on this post (with help from AI) for a few weeks. Right before publishing it, I learned that Calif has demonstrated some sort of wireless exploit magic over the weekend at Hexacon. I haven’t seen the presentation(s) yet but I’m mentioning it here for the sake of completeness.

The original document is withheld to protect a source. If you’re a journalist or Apple employee, I can provide a copy and tell you where it came from. Reach out to me at (blog [at] this domain) ↩︎

The original document is withheld to protect a source. If you’re a journalist or Apple employee, I can provide a copy and tell you where it came from. Reach out to me at (blog [at] this domain) ↩︎

↩︎

↩︎

↩︎

↩︎

It also doesn’t say whether “11-16” includes SE and e models. Their leaked 2024 support matrix names SE variants explicitly; AU doesn’t. ↩︎

It also doesn’t say whether “11-16” includes SE and e models. Their leaked 2024 support matrix names SE variants explicitly; AU doesn’t. ↩︎

A good match for Apple’s stated Bluetooth range of 10 meters ↩︎

A good match for Apple’s stated Bluetooth range of 10 meters ↩︎

Logical Link Control and Adaptation Protocol ↩︎

Logical Link Control and Adaptation Protocol ↩︎

Protocol data units – the control messages two devices exchange at this layer ↩︎

Protocol data units – the control messages two devices exchange at this layer ↩︎

In /usr/sbin/bluetoothd (base 0x100000000 ): the vulnerable loop is sub_10029fcb8 in 26.4; the fix is sub_10029f6d4 , liveness check at 0x10029f790 . ↩︎

In /usr/sbin/bluetoothd (base 0x100000000 ): the vulnerable loop is sub_10029fcb8 in 26.4; the fix is sub_10029f6d4 , liveness check at 0x10029f790 . ↩︎

Specifically: a ~224-byte ( 0xe0 ) attacker-influenced object, freed while a reference to it is still live. 26.5 also fixes a second UAF of the same class deeper in the receive pipeline (the Enhanced Retransmission Mode reassembly path), but that one sits behind L2CAP channel configuration, making it harder to reach pre-pairing and less interesting as an AU candidate 15 . ↩︎

Specifically: a ~224-byte ( 0xe0 ) attacker-influenced object, freed while a reference to it is still live. 26.5 also fixes a second UAF of the same class deeper in the receive pipeline (the Enhanced Retransmission Mode reassembly path), but that one sits behind L2CAP channel configuration, making it harder to reach pre-pairing and less interesting as an AU candidate 15 . ↩︎

After first unlock, the Secure Enclave holds the data-protection class keys in an unlocked state and will unwrap per-file keys for the kernel on demand ↩︎

After first unlock, the Secure Enclave holds the data-protection class keys in an unlocked state and will unwrap per-file keys for the kernel on demand ↩︎

Although bluetoothd is using modern hardened allocators in 26.4 and 26.5, these do not defend against same-type reuse as described here. ↩︎

Although bluetoothd is using modern hardened allocators in 26.4 and 26.5, these do not defend against same-type reuse as described here. ↩︎

MIE uses 4-bit memory tags. A blind tag guess succeeds with probability 1/(2^4) ↩︎

MIE uses 4-bit memory tags. A blind tag guess succeeds with probability 1/(2^4) ↩︎

Cellebrite’s top tier service where they’ll fly a team to your office if necessary to attempt a device extraction ↩︎

Cellebrite’s top tier service where they’ll fly a team to your office if necessary to attempt a device extraction ↩︎

There is a vague CoreBluetooth acknowledgment in the 26.5 bulletin, with no CVE – but it’s further up the stack in the framework layer, not the daemon. Interestingly, it was added to the bulletin after the fact. ↩︎

There is a vague CoreBluetooth acknowledgment in the 26.5 bulletin, with no CVE – but it’s further up the stack in the framework layer, not the daemon. Interestingly, it was added to the bulletin after the fact. ↩︎

The second UAF is in the Enhanced Retransmission Mode reassembly path, which requires an established channel – harder to reach pre-pairing than the aggregation-layer UAF. ↩︎

The second UAF is in the Enhanced Retransmission Mode reassembly path, which requires an established channel – harder to reach pre-pairing than the aggregation-layer UAF. ↩︎