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.