Zero-Click iOS Attacks: A Decade of Lessons

January 2025. Ciro Pellegrino, head of the Naples newsroom at the Italian publication Fanpage.it, is going about his day. His iPhone is running iOS 18.2.1, the most recent version Apple has released. He has done nothing unusual. He has not clicked any suspicious links, downloaded any sketchy apps, or visited any compromised websites.

Somewhere, someone sends him an iCloud Link containing a maliciously crafted media file. He never sees it. He never taps it. He never knows it arrived. But the moment his phone processes that link in the background — to generate a preview, to update an index, to do whatever iOS does silently with shared media — a chain of bugs fires. By the time the next sunrise comes, Paragon's Graphite spyware is installed on his device. His messages, his contacts, his microphone, his camera, his location history — all of it is now available to the operator who deployed it.

It would be three months before the Apple notification arrived warning him he had been targeted. By then, the operator had everything they wanted. Citizen Lab confirmed the attack chain in June 2025. Apple assigned CVE-2025-43200 to the bug. He was the second journalist at the same publication compromised the same way.

This is what a 2025-vintage iOS zero-click looks like. No clicking. No phishing. No "you shouldn't have downloaded that." Just the arrival of data on a phone, and a parser somewhere doing what parsers do.

iOS has been the public laboratory for this class of attack for over a decade. The technical reports from Project Zero, Citizen Lab, Kaspersky, and Apple itself have collectively become one of the best educations in offensive security ever made publicly available. This article walks through what those reports actually tell us — the chains, the patterns, what Apple has shipped in response, and what your own app contributes to the problem whether you realize it or not.

Two audiences. If you build software but don't write iOS code, the technical sections will explain why your app is part of this conversation. If you do write iOS code, you already know — and the modern attack catalog below has the parts your last security review almost certainly missed.

The 60-second version, if you sign the checks

A zero-click attack is one where the user does nothing. No tap, no link, no permission grant. The mere arrival of a message, image, or call on the device is enough to compromise it. iOS gets the headlines because researchers find these bugs there — Apple's bug bounty program, Citizen Lab's targeting of NSO and Paragon clients, Kaspersky catching state operators on their own employees' phones. The pattern is well-documented and recurring.

Why this matters at the executive level:

The cost-to-build is in the millions, and the cost-to-use is in the thousands. Building a working iOS zero-click chain takes a team of researchers months and costs an operator millions of dollars. Using it against a specific target — once built — is comparatively cheap. That asymmetry means these capabilities are reserved for high-value targets: executives, board members, dissidents, journalists, anyone with information worth millions to someone.
The capability has spread beyond NSO. Pegasus made the headlines in 2021. Paragon's Graphite hit journalists in 2025. Citizen Lab tracks at least half a dozen commercial vendors with iOS zero-click capability today. The market has matured. The bar has lowered. If your competitive position makes you interesting to a state actor — or to anyone who can afford one — these capabilities apply to you.
Your enterprise MDM cannot detect them. Zero-click chains are designed for forensic invisibility. The signal that you've been compromised typically arrives months later, from Apple's threat notification system or a researcher's outreach. By then, every device-side artifact the attacker wanted is long gone.
Apple is shipping new defenses, and your IT team probably hasn't deployed them. Lockdown Mode (introduced in iOS 16) disables most of the attack surface zero-clicks rely on. It is opt-in, off by default, and almost no enterprise has rolled it out for high-risk roles. That is a free, available, immediate defense most companies haven't claimed.
Your own app may be the cheap stage of someone else's chain. The most important section of this article — and the one that most directly applies to non-iOS engineers — is the one about what your software contributes. Push notification handlers, image processors, WebViews, third-party SDKs: every one of these can become a link in a chain that ends in compromise. The attacker's "free RCE" often costs your app two lines of careless code.

Translation: if your company's executives, board, legal counsel, or journalists on staff carry iPhones — and that's nearly every company — you are operating in an environment where the worst threat category has both a documented playbook and a public list of victims. Defense is structural: Lockdown Mode for high-risk roles, fast patching, and a hard audit of your own app's contribution to the attack surface.

The shape of a modern iOS zero-click chain

Before the case studies, the abstract: every public iOS zero-click chain since 2019 has roughly the same five-stage structure.

Delivery vehicle. Something that arrives on the device without user action: iMessage, FaceTime call setup, mail, AirDrop, an iCloud Link, or a malicious WiFi access point.
Initial RCE. A memory-corruption bug in a parser that the OS automatically invokes on delivery — typically image, font, video, or document parsing.
Sandbox escape. The initial RCE runs in a tightly restricted sandbox. The chain needs a second bug — often in IPC, the kernel's task port handling, or shared frameworks — to escape it.
Privilege escalation. Getting from sandboxed code to kernel privileges. Usually a kernel memory-safety bug.
Persistence and exfiltration. Survive reboots, hide from MDM, ship data out quietly. Often the longest stage. Almost always the loudest if the operator is sloppy.

Each link is its own multi-month research effort. Conservatively, a working chain costs millions of dollars per platform to build. That's why these chains — when they leak into the public record — are worth studying carefully. Each one is a textbook.

Case 1: FORCEDENTRY (2021)

CVE: CVE-2021-30860 (CoreGraphics). Disclosure: Citizen Lab and Apple, September 2021. Operator: NSO Group's Pegasus.

FORCEDENTRY's initial RCE was an integer overflow in CoreGraphics' rendering of a JBIG2 (a fax-era image compression standard) embedded inside a PDF, delivered via iMessage with a .gif file extension — which the OS happily handed to the wrong parser based on file magic, not extension.

The technical depth is where this gets genuinely astonishing. The bug itself was a small heap overflow. The exploit chain — documented in Project Zero's deep dive by Ian Beer and Samuel Groß — used the JBIG2 stream to encode an entire virtual CPU inside the JBIG2 bitmap operations. The exploit then ran a complete program of arithmetic and memory operations inside the parser, escalating from a single heap corruption to arbitrary code execution.

Let that sink in. NSO's researchers had built a working computer out of the arithmetic primitives of an image compression format. They booted it inside the parser. They ran their exploit on it. Project Zero called it "one of the most technically sophisticated exploits we have ever seen."

The lesson for the rest of the industry: if a determined adversary can compute a Turing-complete machine from your image parser's arithmetic operations, "input validation" is not a sufficient defense. Memory safety is the defense. Languages that prevent the original heap overflow prevent the entire chain.

Case 2: BlastPass (2023)

CVEs: CVE-2023-41064 (ImageIO WebP), CVE-2023-41061 (Wallet). Disclosure: Citizen Lab and Apple, September 2023. Patched in iOS 16.6.1.

BlastPass exploited a buffer overflow in the WebP image parser shared across Apple's ImageIO framework. The delivery channel was a malicious image attached to a PassKit pass (an Apple Wallet artifact), sent via iMessage. The Wallet pipeline's processing of the pass invoked ImageIO outside of the BlastDoor sandbox that protects iMessage's own parsing, exposing the WebP bug to an unsandboxed attack surface.

BlastPass is technically interesting for what it says about sandbox boundaries. Apple had introduced BlastDoor in iOS 14 specifically to contain iMessage parser bugs. BlastPass found a way around BlastDoor by exploiting the same parser through a different system entry point (Wallet) that did not sandbox it. The defense moved. The attacker moved with it.

The lesson for defenders is structural: a sandbox is only effective against the surface it actually covers. Every other entry point to the same parser is an alternate path. We see the same pattern in enterprise apps — a hardened API endpoint with rigorous validation, and a forgotten admin endpoint that hits the same backend with no validation at all. The bug doesn't care which front door it came through.

Case 3: Operation Triangulation (2023) — the one that found a hidden hardware feature

CVEs: CVE-2023-32434 (kernel), CVE-2023-32435 (WebKit), CVE-2023-38606 (kernel — undocumented hardware feature), CVE-2023-41990 (TrueType font). Disclosure: Kaspersky Lab, June through December 2023.

Triangulation is the most technically dense iOS chain ever made public. Kaspersky discovered it because the operators made the mistake of targeting Kaspersky's own employees. Years of forensic analysis followed.

The chain is four stages. A TrueType font containing an undocumented instruction arrives via a malicious iMessage attachment. The font triggers memory corruption in the font renderer. That corruption is used to call into a JavaScriptCore engine through a malicious Safari WebKit exploit. WebKit code escapes via a kernel bug. The kernel bug uses — and here is the part that should genuinely scare you — a hardware feature undocumented even within Apple.

CVE-2023-38606 targets unknown memory-mapped I/O registers in Apple A12-A16 Bionic processors. These registers are not listed in Apple's own device tree. They are likely linked to the chip's GPU co-processor and were apparently intended for hardware testing or debugging. Triangulation's operators discovered them and used them to bypass hardware-based memory protection — writing data to physical addresses while skipping the protection that should have blocked them.

Kaspersky's verdict, in their Securelist deep dive: the feature was "possibly based on the principle of 'security through obscurity,'" undocumented, and never publicly described. Apple's own product teams almost certainly did not know it could be used this way.

The implication is unsettling. Triangulation's operators discovered something Apple's own product teams did not know existed. That implies either a leak from inside the supply chain or research at a level that exceeds the platform vendor's own visibility into the platform. Either way, the asymmetry between operator capability and defender capability for the highest-value targets is starker than most people assume.

Case 4: Graphite / Paragon (2025) — the one that's happening now

CVE: CVE-2025-43200 (Messages). Disclosure: Citizen Lab, June 2025. Operator: Paragon Solutions' Graphite. Victims (confirmed): European journalists, including two at the Italian publication Fanpage.it.

Graphite is the most recent confirmed zero-click iOS attack chain. The bug is a logic flaw in iOS's handling of maliciously crafted photos or videos shared via iCloud Links. The target does not have to open or view the booby-trapped media file. The vulnerability is triggered by iOS's background processing of the link, before any user interaction.

Apple patched it in iOS 18.3.1 on February 10, 2025. The attacks against the European journalists had occurred in January and early February — meaning the operators were using it against fully-updated devices, in real time, against working journalists.

Two things about Graphite are worth holding onto.

First, the market for zero-click capability has matured beyond NSO. Paragon is a separate vendor. Their Graphite product offers similar capabilities. Citizen Lab tracks at least half a dozen commercial vendors selling iOS zero-click exploits as a service. NSO's high-profile legal troubles (including a $167 million WhatsApp penalty in 2024) did not shut the market down. It diversified.

Second, fully-updated iOS devices are not safe. The victims of Graphite were running the latest version of iOS at the time of compromise. Patching is necessary. It is not sufficient. The zero-day market exists precisely because there is always a window where the latest bug is unpatched.

The pattern: image and font parsers are the doorways

If you trace the initial-stage bugs across the public iOS zero-click record, an unsubtle pattern emerges:

Graphite (2025) — media file logic flaw
BlastPass (2023) — WebP image parser
Triangulation (2023) — TrueType font renderer
FORCEDENTRY (2021) — JBIG2 inside PDF via CoreGraphics
KISMET (2020) — exact details not public but reportedly in iMessage parsing
CVE-2019-8641 — iMessage NSKeyedUnarchiver deserialization (Natalie Silvanovich, P0)
CVE-2019-6223 (FacePalm) — FaceTime group call eavesdropping state machine
CVE-2016-4631 — TIFF parser in ImageIO

The reason this attack surface is so productive is that media parsers have three properties attackers love:

Complex binary formats. Every codec carries decades of edge cases, optional features, and version variants. JBIG2 is a fax format. TIFF was designed in 1986. WebP looks modern but has dozens of optional features.
Written in C or C++. Memory-unsafe languages where a parsing bug becomes a memory corruption bug becomes a code execution bug. The "bug class" is not theoretical; it is structural.
Invoked automatically. The OS fires the parser before the user has a chance to interact, often in a background process the user does not even know exists.

This is why Apple's response strategy has shifted from "find and fix individual bugs" to "shrink the attack surface that runs before user interaction." BlastDoor (iOS 14), Lockdown Mode (iOS 16), and the ongoing rewrite of media parsing into safer language frontends are all examples of the same strategy: do less, in less-privileged contexts, before the user opts in.

What this means for non-Apple developers

Almost everything above is platform-level. The bugs are in Apple's code, fixed by Apple, mitigated by Apple's sandbox architecture. Your app is mostly an indirect beneficiary.

But you are also a participant in the attack surface, and a more important one than most engineering teams realize. Here is what your app contributes to the problem.

If your app processes user-controlled media automatically

Avatar uploads. Attachment previews. OG-image rendering. Push-notification rich media. All of these invoke parsers on input you did not write and cannot fully validate. The libraries you depend on (image processing on the backend, video transcoding, even SVG rendering in your frontend) are subject to the same bug classes that produce iOS 0-clicks. CVE-2023-4863 in libwebp affected thousands of applications because libwebp is everywhere — including, very likely, in yours.

The mitigations look like Apple's: run parsing in a stripped-down process, with strict resource limits, on input that has been size- and type-checked at the boundary. If you can use a memory-safe parser (Rust-based libraries are increasingly available for common formats), do it.

If your app has a notification extension on mobile

Your iOS UNNotificationServiceExtension or Android NotificationListenerService runs in a background context before the user sees anything. If it fetches URLs from the payload, parses content, or modifies the notification body using user-controlled data, you have an automatic-execution attack surface of your own. (We covered this in detail in our "Push Notifications as an Attack Surface" post.)

If your app integrates third-party SDKs

The average production mobile app ships with 20 to 50 SDKs, each of which runs inside your process with your permissions. Several of them include their own parsers — analytics SDKs that handle binary protocols, ad SDKs that render web content, crash reporters that process structured data. Each one is an additional pre-user-interaction attack surface. We routinely find that the most exploitable code in a mobile app is not the app's own — it is the SDKs it ships.

The defender's takeaway

You will not, realistically, stop a Triangulation-class operator from getting onto a phone if they have decided to target your user. That is not the bar. The bar is this:

Your app should not be the cheap stage of someone else's chain. An attacker should not be able to use your push notification handler, your file processor, or your WebView, as the link that turns a memory bug elsewhere into a full compromise.
Your app should not leak the data your user assumes is local. If a chain achieves on-device code execution, your contribution to the blast radius should be small — encryption at rest, narrowest possible app permissions, no PII in caches.
Your security model should not depend on the absence of an attacker. "But they would need to be on the device" is not a defense in a world where zero-clicks are public knowledge.

When we engage on a high-sensitivity mobile product, this is the bar we work toward. The findings are rarely glamorous — they look like "this WebView allows file:// URLs," or "this notification extension fetches arbitrary HTTPS endpoints," or "this image processor uses libwebp 1.3.0 (vulnerable to CVE-2023-4863)." Each of them, individually, is a paragraph in a report. Together, they are the difference between "your app added one link to the attacker's chain" and "your app added none."

The boardroom translation table

What your team says	What it actually means	What it could cost you
"Our executives are on the latest iOS"	Patching helps. It is not sufficient. Graphite hit journalists running fully-updated devices in 2025.	Full device compromise of any executive, including microphones, cameras, messages, location.
"We don't have Lockdown Mode enabled for high-risk roles"	You are not using Apple's strongest available defense for the people most likely to be targeted.	One free, immediate defense unclaimed. Most chains don't function under Lockdown Mode.
"Our app processes images, video, or PDFs from user upload"	You inherit the libwebp / TIFF / PDF parsing CVE risk. Your stack is the cheap stage.	Server-side RCE that doesn't require your code to be wrong — just your dependencies.
"Our mobile app uses 30+ third-party SDKs"	Each SDK is code running in your process with your permissions. You did not audit any of them.	The exploitable surface is in code you don't own. Your app's name is on the breach report regardless.
"We have MDM — we'll see if a device is compromised"	Zero-click chains are designed for forensic invisibility. MDM will not see them.	The first signal of compromise will come from Apple, Citizen Lab, or a journalist. Months late.

Five questions to put to your engineering team this week

"Have we enabled Lockdown Mode for executives, board members, and legal counsel?" This is a free, immediate defense Apple ships. Most companies have not deployed it.
"What media-parsing libraries does our app depend on, and when did we last update them?" libwebp, libpng, libtiff, ffmpeg, ImageMagick — each is a recurring CVE source. Audit your transitive dependencies.
"What does our notification extension do with the data it receives? Does it make network calls?" If yes, that is your app's contribution to a zero-click chain. It deserves scrutiny.
"How many third-party SDKs ship inside our mobile app? Have we audited any of them?" The honest answer for most teams is "more than we counted" and "none." Both are findings.
"If an executive's iPhone were compromised tomorrow, how would we know?" If the answer involves MDM or EDR, you are relying on tools that demonstrably miss this class of attack.

What we test, every mobile engagement

Media parsing libraries (versions, known CVEs, sandbox boundaries).
WebView configurations (URL schemes allowed, JavaScript bridges, file:// access).
Notification extension behavior (network access, payload parsing).
Third-party SDK inventory and known-CVE matching.
Background processing surface: what fires before the user opens the app.
Deep link handling (custom schemes, universal links, URL parsing inconsistencies).
Inter-process communication: XPC, intents, URL schemes between apps.
Encryption-at-rest for sensitive caches, keychain usage hygiene.
Network exposure of app-private endpoints (debugging, dev tools, hidden flags).
Lockdown Mode compatibility (does the app degrade gracefully).

The bottom line

The world where zero-click iOS attacks were a state-actor curiosity is gone. Paragon's Graphite attack on European journalists in 2025 used a fully-public CVE chain. The commercial market for these capabilities has half a dozen vendors. Apple ships defenses; most enterprises have not deployed them. The forensic invisibility means the first signal of compromise is usually a notification from a third party, months after the fact.

Your enterprise can do four things now: enable Lockdown Mode for the people most likely to be targeted, patch fast, audit your own app's contribution to the attack surface, and accept that detection lags will be the norm. None of these are products to buy. All of them are decisions to make.

Apple is not the weak link. The chain is. Your job is to make sure your software isn't the cheap stage of the next one.