BLASTPASS Explained: How NSO’s WebP Zero-Day Exploit Hacked iPhones Silently

In September 2023, Apple rushed to patch a critical vulnerability after researchers uncovered an alarming zero-click exploit chain attributed to NSO Group. Dubbed BLASTPASS, this attack could compromise iPhones running iOS 16.6 without any user interaction—no clicks, no warnings.

Today, Google Project Zero researcher Ian Beer has published a deep dive into how the exploit worked, revealing a sophisticated blend of memory corruption, heap grooming, and sandbox bypass techniques that targeted Apple’s iMessage infrastructure.

The WebP Zero-Day at the Core

The exploit chain began with CVE-2023-41064, a buffer overflow in Apple’s ImageIO framework tied to the WebP image format. WebP, developed by Google, is a modern image format that supports both lossy and lossless compression. 

The flaw resided in the lossless compression component, specifically in how Huffman coding tables were constructed. By manipulating the symbol lengths in these tables, attackers could trigger an out-of-bounds write, corrupting memory in a controlled way.

What made this bug particularly challenging to exploit was its limited corruption primitive: it could only write the 32-bit value 0x270007 at a fixed offset past the end of a memory buffer. Worse, the WebP parser would detect the corruption and halt processing almost immediately, leaving little room for traditional exploitation.

BLASTPASS’s Clever Delivery Mechanism

Instead of sending a malicious WebP file directly, NSO Group embedded it inside a PassKit (PKPass) file, Apple’s format for digital passes like boarding passes and tickets. This seemingly innocuous choice was strategic:

• The PKPass file contained a maliciously crafted WebP image disguised as a PNG (logo.png).
• Another file, background.png, was actually a TIFF image—another case of format masquerading.
• The PKPass’s lax parsing allowed the attacker to bypass Apple’s BlastDoor sandbox, which was designed to isolate iMessage attachments.

This multi-layered approach mirrored NSO’s earlier FORCEDENTRY exploit, which used a fake GIF file to trigger a PDF parser.

Heap Grooming and the MakerNote Trick

The WebP file contained more than just the exploit trigger. Hidden inside its EXIF metadata was a massive MakerNote tag—a proprietary field typically used by camera manufacturers. In this case, the MakerNote held a 5.5MB binary property list (bplist), an Apple-specific data format.

This bplist wasn’t just data; it was a precision heap groom, meticulously arranging memory to ensure the WebP overflow corrupted a specific target. 

By exploiting duplicate dictionary keys and other quirks in Apple’s bplist parser, the attackers could control the layout of allocations in the libmalloc small region, a 8MB memory segment used by iOS’s default allocator.

The corruption primitive—writing 0x270007—modified the size of a heap chunk, causing it to overlap with adjacent allocations. This overlap allowed the attackers to partially overwrite a pointer in a CFSet object, redirecting it to a fake CFReadStream object elsewhere in memory.

Bypassing PAC and ASLR

Apple’s Pointer Authentication (PAC) and Address Space Layout Randomization (ASLR) are key defenses against memory corruption exploits. BLASTPASS sidestepped both:

• PAC Bypass: Instead of forging signed pointers, the exploit used callback-oriented programming (COP). By swapping pointers to callback structures (which themselves contained valid, PAC-signed function pointers), the attackers could chain together legitimate code snippets to achieve arbitrary execution.
• ASLR Defeat: Evidence suggests the attackers used a separate HomeKit-based memory disclosure to leak the ASLR slide of the MessagesBlastDoorService process. This allowed them to hardcode pointers in their payload, knowing exactly where critical functions would reside in memory.

The Final Payload and Unanswered Questions

The exploit’s final stage involved a large NSExpression payload, a feature of Apple’s Foundation framework often abused for code execution. This payload decrypted and executed a second-stage exploit, likely a BlastDoor sandbox escape. 

However, researchers couldn’t recover the decryption key, which appeared to be delivered via a follow-up iMessage in a specific format.

Lessons and Mitigations

BLASTPASS highlights several ongoing challenges in mobile security:

1. Parser Confusion Attacks: Renaming files (e.g., .webp as .png) remains an effective way to bypass security checks. Strict file validation is critical.
2. Heap Grooming Resilience: The bplist groom’s complexity underscores the need for stricter parsing of metadata formats.
3. Sandbox Isolation: While BlastDoor limits damage, its large attack surface (including IOKit drivers and system services) still offers escape routes.

Apple has since patched the vulnerabilities, but the exploit’s sophistication—and its parallels to NSO’s earlier work—suggest that similar techniques may still lurk in the wild. For now, keeping devices updated remains the best defense against such advanced threats.

For technical details, read Ian Beer’s full analysis on Google Project Zero’s blog.