Inside Coruna: how an iOS exploit kit covered several software generations
Google reported five alternative iOS chains containing 23 exploits. Their version coverage, reuse and patch history explain why a small group of outdated devices can still matter.
Coruna was built with alternatives. Google’s report describes five full exploit chains covering different iOS configurations, rather than one path that every victim’s device had to follow. That structure helps explain both the kit’s reuse and the patching problem it presents.
Google’s observations and their limits
Google’s March 3, 2026 report describes five full alternative iOS exploit chains containing 23 exploits, with reported coverage from iOS 13.0 through 17.2.1. Its observations span a surveillance-company customer in February 2025, later targeting in Ukraine, and a financially motivated campaign involving Chinese-language websites. Google describes reuse across actors; the transfer mechanism and original provenance are not established with the same confidence as the recovered code.
Google Threat Intelligence Group’s original Coruna report
The five chains are alternatives, not five stages every infection uses. The 23 exploits are not necessarily 23 new zero-days or 23 bugs required for one device. Overlapping paths let a kit provide capabilities across different OS generations. The count tells us about coverage and engineering effort, rather than serving as a severity score.
The protections an exploit chain has to cross
Security property | What it is meant to constrain |
|---|---|
Memory safety in content processing | Invalid access or interpretation of objects while handling untrusted input |
Process sandboxing | Which resources a compromised content-processing process can reach |
Code-flow protection | Whether a program can be redirected through unauthorized control transfers |
Kernel and protected-state integrity | Changes to high-authority operating-system state |
A content-processing bug may corrupt memory while the process sandbox still limits access outside that process. A later authorization failure can increase access without defeating every hardware protection. To understand impact, follow which authority changes at each level rather than treating all code execution as complete device control.
Apple documents application sandboxing, signed entitlements and runtime protections as parts of iOS’s security model. Entitlements matter because privileged operations are not determined only by a process’s Unix user identity. The authority available to a service is therefore part of the impact analysis.
Apple’s runtime process security model
Why alternatives keep patch gaps relevant
Different OS versions have different bugs and protections. Packaging alternative paths can keep a kit useful against some unpatched devices after an update removes another route. That is a defensive interpretation of the reported coverage, not evidence that Coruna could defeat arbitrary future fixes.
Fleet averages can conceal those devices. Most staff may run current releases while a smaller group stays on an unsupported branch for an old business app. Keep exact builds and support status visible so that group is not lost inside a reassuring compliance percentage.
Google’s Coruna analysis includes both browser and higher-privilege components and notes that some CVE associations remained subject to revision. Its financial-theft payload targeted valuable user information, including material associated with cryptocurrency access. Those observations support examining both software exposure and the sensitivity of data stored on a device.
Coruna’s reported components, attribution limits and payload context
Read the later patch guidance too
The highest version named in a recovered kit is an observation about that kit, not a permanent safe-version threshold. Later vulnerabilities, older-device backports and subsequent updates need their own applicability checks.
Apple’s April 14, 2026 guidance says devices on the latest updated releases of iOS 15 through iOS 26 are protected from these reported web attacks. It notes March 11 updates extending protection to iOS 15 and 16, and says devices on iOS 13 or 14 must move to iOS 15 to receive these protections. Apple also identifies Lockdown Mode as protective against these specific attacks while still recommending software updates.
Apple’s protection guidance for the reported web attacks
Install and verify the latest compatible supported security release for the device. An old first-fixed version should not freeze policy in place, and an older major branch should not be assumed to lack a backport without checking Apple’s later notices.
Start with the devices still exposed
Record exact installed versions, support gaps and the business data or authenticated sessions accessible from those devices. For high-risk users, review mobile access and recovery material alongside patch compliance. Copied recovery secrets or reusable sessions may remain valuable after the vulnerable process is gone.
Blocking reported malicious infrastructure may help with known destinations, but covers less than repairing vulnerable software. A device showing no visible crash also tells you little about whether it was targeted. Preserve relevant endpoint and identity records where evidence warrants investigation, and obtain an assessment before a reset removes useful context.
Coruna shows how reusable capabilities can continue to matter across uneven patch coverage. That conclusion does not depend on settling the kit’s uncertain origins or extending its reported version range to every current iPhone.
Source check: September 8, 2026. This article analyzes public reporting by Google Threat Intelligence Group and Apple. Coruna is third-party research; Short Circuit LLC makes no claim to its discovery or attribution.