Background

This section establishes the minimum technical vocabulary needed to follow the two-vulnerability chain dissected in the case study. Readers are assumed to be computer-science graduates without a specialization in systems security; every term is introduced the first time it is used. We cover, in order, the C memory model (Section II-A), the two weakness classes that appear in the chain (Section II-B), the iOS media-processing pipeline in which both vulnerabilities fire (Section II-C), the mitigations that are supposed to prevent exploitation (Section II-D), the 2021 FORCEDENTRY incident which is the historical precedent for the 2025 attack (Section II-E), and the broader decade-long recurrence of write-primitive exploits across iOS and Linux (Section II-F).

The C Memory Model: A Brief Tour

C is a language that trades safety for control. Unlike managed languages such as Java, Python, or Swift, C gives the programmer direct access to raw memory through pointers, with no runtime enforcement of object bounds, type safety, or lifetimes. A running C program organizes its memory into several regions; two are central to exploitation. The stack is a last-in-first-out region where local variables and function call frames live. Every function call pushes a new frame containing parameters, locals, and the saved return address: the instruction to jump to after the callee returns. The heap is a region for dynamically allocated memory (via malloc, calloc, new). Blocks are allocated and freed explicitly by the programmer; the heap allocator maintains bookkeeping metadata (block size, free/used flags, chunk pointers) interleaved with or adjacent to user data.

A pointer in C is simply an integer that names a memory address. Dereferencing a pointer (*p for read, *p = v for write) performs raw memory access with no check that p points to a valid, in-bounds location of the expected type. This is the root of the entire memory-corruption family: if an attacker can drive a write slightly past where it was supposed to land, they can alter state (other variables, function pointers, return addresses, allocator metadata) that the program will later trust and dereference. Aleph One’s 1996 essay “Smashing the Stack for Fun and Profit” ^[6] first formalized the stack-based version of this idea; three decades later, the same pattern continues to produce exploitable bugs at the top of the MITRE CWE Top 25 list ^[8]. The heap-specific variant of this idea was formalised in 2001 by the Phrack article “Once upon a free()” ^[18], which showed how dlmalloc’s bookkeeping metadata (stored adjacent to user data in the same heap region) could be weaponised into a write-anywhere primitive via the allocator’s own unlink routine; three decades later, the structural insight remains valid. Listing 1 shows the minimal C pattern that produces this class of bug.

/* Allocate a 64-byte heap chunk. */
char *buf = malloc(64);

/* No bounds check: if len > 64, bytes
   at buf[64..len-1] are written into
   the *next* heap chunk.             */
memcpy(buf, attacker_input, len);

/* The corruption is invisible here --
   it surfaces later, when the program
   dereferences overwritten state.   */

Vulnerability Taxonomy

Two CWE classes drive the attack chain studied in this work.

CWE-787: Out-of-bounds write ^[8] is the class in which the program writes past the intended end of a buffer. On the heap, an out-of-bounds write may corrupt adjacent allocations or allocator bookkeeping; on the stack, it may corrupt saved registers or the return address. CWE-787 has held the #1 position in the MITRE Top 25 Most Dangerous Software Weaknesses for multiple consecutive years, and memory corruption remains one of the most consequential bug classes in systems software ^[19]. CVE-2025-43300, the Apple ImageIO vulnerability at the core of the chain studied here, is a CWE-787 instance.

CWE-863: Incorrect authorization ^[20] is categorically different. No bits are smashed and no memory is corrupted; the bug is a purely logical failure to enforce an access-control policy on a correctly authenticated principal. CVE-2025-55177, the WhatsApp linked-device synchronization bug, is a CWE-863 instance: the WhatsApp client trusts a synchronization message whose authorization scope was never fully verified, and the attacker uses this trust to coerce the victim device into processing attacker-controlled content. The relevance for this paper is that CWE-863 provides the delivery primitive that places the malicious image into the victim’s media pipeline in the first place. Memory corruption alone is not enough for a zero-click exploit: the bug must be reachable without user interaction, and reachability is exactly what the authorization bug provides.

The iOS Media Processing Pipeline

On Apple platforms, almost every application that displays an image (Messages, Safari, Mail, WhatsApp, Signal) delegates decoding to a shared framework: ImageIO, together with its sister framework CoreGraphics. ImageIO is a C / Objective-C library responsible for parsing image container formats (JPEG, PNG, HEIF, DNG, GIF, TIFF, and several camera-specific RAW variants) and producing decoded pixel buffers. Because ImageIO is shared across the operating system, any parser bug inside it is reachable from every application that displays an image received from the network.

The critical observation is that ImageIO is invoked automatically the moment an incoming image enters the pipeline for thumbnail generation, before the user has seen, tapped, or acknowledged the message. This turns any parser bug in ImageIO into a zero-click attack primitive: the mere delivery of an image is sufficient to trigger code execution if the bug can be driven to memory corruption. In the WhatsApp–ImageIO chain, the end-to-end pipeline is:

1. WhatsApp receives a message via its linked-device synchronization protocol.

2. The message carries an image attachment.

3. To render a thumbnail, WhatsApp hands the raw bytes to CoreGraphics/ImageIO.

4. ImageIO dispatches to the parser for the declared format (DNG in this case).

5. The parser reads attacker-controlled header fields and triggers an out-of-bounds write.

None of these steps requires user interaction.

Modern Mitigations and Their Limits

Three decades of research have produced a layered defense against memory corruption ^{[19, 21]}. Three mitigations are most relevant for iOS and together define the landscape in which the 2025 chain had to operate.

Address Space Layout Randomization (ASLR) randomizes the base addresses of code and data regions at process start, so an attacker who wants to redirect control flow to a specific function must first leak an address from the victim process. ASLR does not prevent memory corruption; it raises the cost of turning corruption into useful code execution.

Stack canaries place a random value just before the saved return address on each stack frame. The function checks the canary before returning, and a mismatch terminates the process. Canaries protect the return address specifically, not arbitrary function pointers, not heap metadata, and not object vtables.

Application sandboxing runs each app inside a kernel-enforced container that restricts file-system, network, and IPC access. A successful RCE inside an app is therefore not immediately full device compromise: a separate sandbox escape is needed to reach kernel or cross-app territory.

These defenses raise the exploitation bar but leave structural gaps. ASLR can be bypassed with an information-leak primitive: often another parser bug in the same process ^[19]. Stack canaries do nothing for heap-resident function pointers, which are precisely what a heap overflow targets. Sandboxes reduce blast radius but do not prevent the initial compromise. The 2025 chain studied here operates entirely within these constraints: the parser bug is exploited inside a sandboxed process, and follow-on stages (privilege escalation, persistence) are layered on top.

Historical Precedent: FORCEDENTRY (2021)

In 2021, Citizen Lab and Google Project Zero documented FORCEDENTRY (CVE-2021-30860), a zero-click exploit deployed against Saudi activists and journalists via NSO Group’s Pegasus spyware ^{[13, 14]}. The architecture is nearly identical to the 2025 chain studied in this paper:

• Delivery: the attacker sends an iMessage to the victim’s phone number; no interaction is required.

• Exploitation: iMessage invokes CoreGraphics to render a malicious PDF disguised as a GIF. The PDF contains a JBIG2-compressed stream; a bug in the JBIG2 parser lets the attacker construct an arbitrary computation primitive inside the parser’s memory, eventually achieving code execution.

• Outcome: full device compromise before the victim sees the message.

FORCEDENTRY proved that a memory-corruption bug in a shared image parser, combined with a delivery primitive that needs no user interaction, is sufficient for complete device takeover. Four years later, the 2025 WhatsApp–ImageIO chain reproduces the same architecture with different components: a different messenger (WhatsApp instead of iMessage), a different authorization bypass (linked-device sync confusion instead of direct delivery), a different parser (DNG in ImageIO instead of JBIG2 in CoreGraphics), and a different carrier format, but the same structural weakness and the same outcome. The persistence of this pattern across four years and across two independent messaging ecosystems is the central empirical observation of this paper, and motivates the technical analysis that follows.

The Recurrence of Write-Primitive Exploits, 2016–2026

The structural parallel between FORCEDENTRY and the 2025 chain is not an isolated coincidence but a reflection of a broader, decade-long trend. Two complementary data sets establish the baseline.

At the vulnerability-class level, memory-corruption weaknesses have dominated the MITRE CWE Top 25 Most Dangerous Software Weaknesses list throughout the period. CWE-787 (Out-of-bounds Write) ranked second in the 2024 edition with a score of 45.20 and 18 entries in the CISA Known Exploited Vulnerabilities catalog ^{[7, 8]}, and remained the highest-ranked memory-corruption class in 2025 ^[9]. At the industry level, memory-safety bugs account for approximately 70 % of all CVEs patched annually by major software vendors: a figure confirmed independently by Microsoft’s Security Response Center across twelve years of patch data ^[10] and by Google’s Chromium team across 912 high-severity browser bugs since 2015 ^[11].

At the exploit level, the decade 2016–2026 produced at least one high-profile write-primitive root or RCE exploit per year across the Linux kernel and the iOS media-processing ecosystem. Table I lists nine representative chains. The entries span eight distinct CWE classes (defined in the table caption) across unrelated subsystems: kernel memory management, pipe page cache, cryptographic API, IPsec networking, and image parsers. Their common denominator is not a single weakness class but a shared exploitation outcome - an unauthorized write to privileged memory that converts into either local root (Linux) or remote code execution (iOS). The four iOS-targeting chains all use parser bugs as the initial write primitive; the five Linux kernel chains exploit different subsystems but reach the same privilege- escalation endpoint.

The recurrence is ongoing. Copy Fail (CVE-2026-31431) was disclosed on April 29, 2026, exploiting an in-place optimization flaw in the kernel AF_ALG crypto interface (CWE-669) to achieve a deterministic 4-byte write into arbitrary kernel page-cache frames ^{[15, 25]}, achieving local root on a fully patched Ubuntu 24.04 with SMAP, SMEP, and KASLR enabled. Nine days later, DirtyFrag (CVE-2026-43284) was disclosed on May 7, 2026, exploiting the xfrm-ESP IPsec networking stack (CWE-123) via the same page-cache write primitive ^{[16, 26]}. Both were actively exploited within days of disclosure. These two disclosures - arriving within a single week - illustrate that the write-primitive exploit class is not converging toward zero: the subclass of bug and the target subsystem change with every disclosure; the exploitation outcome does not.