Coruna: The Exploit Kit That Turned iPhones Into ATMs for Cybercriminals — And Why This Is Mobile's EternalBlue Moment

A surveillance-grade iOS exploit kit traveled from a commercial spyware vendor to Russian intelligence to Chinese cybercriminals in under twelve months. Along the way, it picked up a cryptocurrency-stealing payload that scans your Notes app for seed phrases, decodes QR codes from your photo library, and drains eighteen different wallet apps. CISA just added three of its vulnerabilities to the Known Exploited Vulnerabilities catalog. This is the story nobody is telling completely — and the dots nobody is connecting.

On March 3, 2026, Google's Threat Intelligence Group (GTIG) and mobile security firm iVerify simultaneously published reports on what may be the single most significant iOS exploitation framework ever publicly documented. GTIG called it Coruna, the name the kit's own developers gave it. iVerify independently discovered it and tracked it under the name CryptoWaters. Two days later, on March 5, CISA added three of its component vulnerabilities to the Known Exploited Vulnerabilities (KEV) catalog, with federal agencies given until March 26 to patch.

But the real story here is not just another set of CVEs added to a government spreadsheet. Coruna represents a tectonic shift in mobile security — one that collapses the distance between nation-state surveillance tooling and commodity cybercrime, exposes fundamental architectural weaknesses in how enterprises protect mobile devices, and carries echoes of the single most destructive exploit leak in cybersecurity history.

What Coruna Is and How It Works

Coruna is a modular iOS exploit framework containing 23 individual exploits organized into five full exploit chains. It targets iPhones running iOS 13.0 (released September 2019) through iOS 17.2.1 (released December 2023). According to GTIG's report, the kit's name was discovered when a threat actor accidentally deployed a debug version of the framework, revealing internal codenames for each exploit — including names like "buffout," "Parallax," "terrorbird," "cassowary," "bluebird," and others, all written in English.

The attack flow is methodical. When a victim visits a compromised or malicious website, a hidden JavaScript framework activates. This framework fingerprints the target device, checking the specific iPhone model, iOS version, and critically, whether the device is running Apple's Lockdown Mode or using private browsing. If either defensive measure is active — Lockdown Mode or Safari's Private Browsing — the framework aborts entirely. iVerify confirmed this dual abort behavior independently: the LPE exploit also checks for the presence of a Corellium virtualized environment (/usr/libexec/corelliumd) and will not run if it detects a research or sandboxed environment. If the device passes all checks and is vulnerable, Coruna selects the appropriate exploit chain and silently begins execution.

From there, the chain progresses through multiple stages: WebKit remote code execution (RCE) provides the initial foothold, followed by Pointer Authentication Code (PAC) bypass, sandbox escape, and Page Protection Layer (PPL) bypass to escalate privileges all the way to kernel level. At the end of the chain, a stager binary called PlasmaLoader (tracked by GTIG as PLASMAGRID) injects itself into powerd, an iOS daemon that runs as root. From that position, the payload has effectively unlimited access to the device.

One anti-forensics detail that has received almost no attention in coverage of Coruna: the exploit chains actively scan for crash logs from previous exploitation attempts. According to iVerify's technical analysis, if a crash log is found from a prior failed attempt — particularly crashes involving powerd or kernel panics — the kit deletes those logs before proceeding. This deliberate evidence cleanup means that a device that survived an earlier failed exploitation attempt may show no log trace of that attempt by the time it is successfully compromised. The forensic trail is shorter than it would otherwise be, by design.

GTIG described the framework as "extremely well engineered," with all exploit components linked through shared utilities and a common delivery architecture — building a kit where each piece reinforces the others. — Google Threat Intelligence Group, March 3, 2026

What makes Coruna architecturally distinct from previous iOS exploits is its breadth of coverage. Rather than targeting a single iOS version with a single chain, it carries five complete chains that collectively span four years of Apple operating system releases. That means the framework does not need the target to be on one specific vulnerable version — it can adapt to whatever it encounters, as long as the device has not been updated past iOS 17.2.1.

There is one technical characteristic of PlasmaLoader that has significant implications for both forensics and remediation: the implant does not establish persistence across a full device reboot. It injects into the powerd daemon and lives in memory, but a hardware reboot clears it. That sounds reassuring until you consider the other side of that fact — a device can be reinfected immediately by visiting the same compromised site again. The infection is not permanent, but the vulnerability that enables it is, until the device is patched. iVerify has explicitly recommended daily restarts as a mitigation for unpatched devices, but stressed that restarts are not a substitute for patching. They buy time. They do not close the door.

One further technical detail from iVerify's independent analysis: its researchers captured modules targeting imagent (Apple's iMessage service daemon) and WhatsApp that GTIG did not report in its initial publication. iVerify noted this explicitly in its technical blog, adding that the Coruna implant and exploit kit appear to be in active development. New modules can be pushed to compromised devices via the C2 configuration. What GTIG and iVerify documented in early March 2026 represents the kit's capabilities at that snapshot in time, not a static ceiling. The attack surface iVerify observed was larger than what GTIG initially described, and both organizations have said additional technical publications are forthcoming.

The Three CVEs CISA Just Flagged

On March 5, 2026, CISA added three vulnerabilities from the Coruna kit to its Known Exploited Vulnerabilities catalog. Each plays a distinct role in the exploitation chain:

CVE-2021-30952 (codename: "buffout") — An integer overflow vulnerability in WebKit, fixed by Apple in iOS 15.2. This flaw allows arbitrary code execution when a device processes crafted web content. It serves as the initial remote code execution entry point in one of Coruna's chains. CVSS score: 8.8.

CVE-2023-41974 (codename: "Parallax") — A use-after-free vulnerability fixed in iOS 17. Exploiting this flaw enables arbitrary code execution with kernel privileges, making it the critical privilege escalation component. CVSS score: 7.8.

CVE-2023-43000 (codename: "terrorbird") — A use-after-free vulnerability in WebKit, fixed in iOS 16.6 in July 2023. It allows an attacker to trigger memory corruption via crafted web content. Notably, Apple did not include a CVE-2023-43000 entry in its original iOS 16.6 security release notes; the identifier was added to the relevant Apple security documentation significantly later — after the vulnerability had already been silently exploited in the wild as part of Coruna for over two years.

The nine other CVEs known to be part of Coruna had already been added to the KEV catalog in previous rounds. The fact that these three were only now added — despite some being patched years ago — is itself telling. There were no confirmed public reports of their exploitation before GTIG and iVerify published their Coruna research. The vulnerabilities were patched, but nobody outside the attacker ecosystem knew they were being actively exploited until this kit was dissected.

One additional CVE worth noting, though it was not among the three CISA added on March 5: GTIG's analysis specifically identified CVE-2024-23222, a type confusion vulnerability in WebKit, as the exploit delivered to a device running iOS 17.2 during the Ukrainian campaign phase. Apple patched CVE-2024-23222 in iOS 17.3 on January 22, 2024, without crediting any external researcher. This is consistent with Apple's pattern of silently patching exploited vulnerabilities — and with the broader finding that multiple Coruna component vulnerabilities were being exploited in the wild long before they entered any public catalog of known-exploited flaws.

The Proliferation Timeline: Surveillance to Espionage to Crime

Coruna's journey across the threat landscape in 2025 is what elevates this from a technical curiosity to a strategic concern. GTIG tracked the kit through three distinct phases:

February 2025: The Surveillance Vendor. GTIG first captured parts of the Coruna exploit chain during an operation attributed to a customer of an unnamed commercial surveillance company. At this stage, the kit was being used in the manner typical of the commercial spyware industry — highly targeted, against specific individuals, presumably on behalf of a government client. GTIG did not identify which government was involved.

Summer 2025: Russian Espionage. The same JavaScript framework appeared again, this time hosted on cdn.uacounter[.]com, a domain loaded as a hidden iFrame on compromised Ukrainian websites. The sites ranged from industrial equipment retailers to local service providers and ecommerce shops. GTIG attributed this activity to UNC6353, a suspected Russian espionage group. The framework was delivered selectively, only to iPhone users from specific geolocations.

December 2025: Chinese Financial Crime. Coruna surfaced a third time, now embedded in a network of fake Chinese gambling and cryptocurrency websites. GTIG attributes this campaign to UNC6691, a financially motivated Chinese threat actor. iVerify confirmed that unlike the earlier deployments, this version had no geolocation filtering — meaning any iPhone running a vulnerable iOS version that visited these sites was a target.

GTIG wrote that how Coruna changed hands "is unclear, but suggests an active market for 'second-hand' zero-day exploits." — Google Threat Intelligence Group, March 3, 2026

That progression — from targeted surveillance to geopolitical espionage to mass criminal deployment — happened in approximately ten months. Spencer Parker, iVerify's Chief Product Officer, estimated that the Chinese UNC6691 campaign alone infected at least 42,000 devices — a figure he described to CyberScoop as "a massive number" for iOS, a platform where infections are typically counted in the dozens. The total number of victims across all three campaigns remains unknown. That 42,000 figure covers only the UNC6691 phase and only the infections iVerify could confirm via C2 traffic analysis. The actual count is almost certainly higher.

To understand why the proliferation timeline matters, we need to examine two historical parallels that inform what Coruna actually represents.

The Operation Triangulation Connection

Several of Coruna's exploit chains reuse vulnerabilities that were first seen as zero-days in Operation Triangulation, the sophisticated iOS spyware campaign discovered by Kaspersky in June 2023. Operation Triangulation was unprecedented in its own right: it used four zero-day vulnerabilities chained together, including CVE-2023-38606, which exploited undocumented hardware features in Apple's A12-A16 Bionic chips to bypass hardware-based kernel memory protection.

Kaspersky's researchers described that hardware exploitation as the most complex they had ever analyzed. The attackers wrote data to Memory-Mapped I/O (MMIO) registers that were not described in any public documentation, were not referenced in the iOS device tree, and were not used by the firmware. In a Kaspersky press release issued alongside the 37th Chaos Communication Congress presentation in December 2023, Boris Larin stated: "This is no ordinary vulnerability." The question of how the attackers even knew those registers existed has never been answered.

The connection to Coruna is direct. According to GTIG, two Coruna exploit modules — internally codenamed "Photon" and "Gallium" — exploit the same CVEs that were used as zero-days in Operation Triangulation: specifically CVE-2023-32434, which grants full kernel read/write access, and CVE-2023-38606, the undocumented hardware feature bypass. Coruna also embeds reusable modules that facilitate exploitation of these same vulnerabilities across different iOS versions.

Here is where it gets complicated. The Russian government publicly accused the United States — specifically the NSA — of being behind Operation Triangulation. Russia's Federal Security Service (FSB) claimed in June 2023 that thousands of iOS devices belonging to Russian domestic subscribers and foreign diplomats had been compromised, and alleged Apple was complicit. Apple denied the allegation.

When Coruna surfaced, iVerify's co-founder Rocky Cole reignited that debate, stating publicly that the exploit chain shows clear similarities to frameworks previously developed by U.S. government-affiliated threat actors. Speaking to Wired and CyberScoop, Cole described the code quality as something he had never encountered outside of a U.S. government context. He told CyberScoop the codebase was elegantly written, fluid, and structurally cohesive in a way consistent with professional U.S. defense industrial base development. He noted that code comments were reminiscent of insider humor familiar to anyone with that background, and that the developers were clearly native English speakers. Cole called it the first documented case, based on code indicators, of tools very likely developed by the U.S. government proliferating into the hands of both adversaries and criminal organizations.

"It's highly sophisticated, took millions of dollars to develop, and it bears the hallmarks of other modules that have been publicly attributed to the US government." — Rocky Cole, co-founder and COO, iVerify, iVerify press release, March 3, 2026

Larin told The Register that shared CVEs are not proof of shared authorship: "A vulnerability is not a component." Any skilled team, he argued, could independently develop their own exploits from public CVE disclosures, without access to the original exploit code. — Boris Larin, Principal Security Researcher, Kaspersky GReAT, speaking to The Register, March 4, 2026

Larin's point is technically sound. Once a vulnerability is publicly known and its CVE is published, independent exploit development is entirely possible. Shared CVEs do not prove shared authorship. But the debate itself reveals something important: the knowledge needed to exploit undocumented Apple hardware features has now escaped whatever circle originally discovered it. Whether Coruna's authors reverse-engineered the Triangulation exploits from public disclosures, obtained them through a secondary market, or had independent access to the same information — the outcome is the same. That knowledge is now in criminal hands.

The EternalBlue Parallel Nobody Is Talking About

The cybersecurity industry has a reference point for what happens when government-grade exploits reach criminal ecosystems: EternalBlue.

In 2017, a hacker group called the Shadow Brokers stole a cache of NSA hacking tools and leaked them publicly. Among them was EternalBlue, an exploit targeting a vulnerability in Microsoft's SMBv1 protocol (CVE-2017-0144). The NSA had known about the vulnerability for years and had used it for offensive operations rather than disclosing it to Microsoft. When the Shadow Brokers leak became inevitable, the NSA apparently tipped off Microsoft, which released the MS17-010 patch on March 14, 2017 — exactly one month before the public leak on April 14.

But the patch adoption rate was catastrophically slow. On May 12, 2017, the WannaCry ransomware weaponized EternalBlue, infecting over 230,000 computers across 150 countries. UK hospitals were locked out of medical equipment. Factories in Russia, Ukraine, India, and Taiwan ground to a halt. Six weeks later, the NotPetya attack used the same exploit to cause an estimated $10 billion in damages worldwide.

iVerify explicitly drew this parallel in its Coruna press release, and for good reason. The pattern is structurally identical:

1. A government agency (or its contractor) develops or acquires a powerful exploit. With EternalBlue, it was the NSA exploiting Microsoft Windows. With Coruna, the original developer remains unidentified, but the kit was first observed in the hands of a surveillance vendor's government customer.
2. The exploit escapes controlled use. EternalBlue was stolen by the Shadow Brokers. Coruna's proliferation mechanism is unknown, but GTIG describes an "active market for second-hand zero-day exploits."
3. Patches exist, but adoption lags. Microsoft had patched EternalBlue a month before WannaCry hit, and systems were still vulnerable. Apple patched the vulnerabilities Coruna exploits as far back as 2021, yet devices running iOS 13 through 17.2.1 remain in the wild.
4. Criminals repurpose the exploit for mass attacks. WannaCry and NotPetya followed EternalBlue. With Coruna, UNC6691 turned a surveillance tool into a cryptocurrency-draining operation with no geographic targeting restrictions.

The difference this time is the target platform. EternalBlue hit Windows — the dominant desktop operating system in enterprise and government environments. Coruna hits iOS — the platform that billions of people carry in their pockets, use to manage their finances, store their passwords, and increasingly, hold their cryptocurrency. The attack surface is not just larger; it is more personal.

The "Lazarus" Seed: A Clue Hiding in Plain Sight

There is one technical detail in the Coruna analysis that has received surprisingly little scrutiny. According to both GTIG and multiple independent analysts, the PlasmaLoader implant embedded in the UNC6691 deployment uses a custom Domain Generation Algorithm (DGA) as a fallback communication mechanism. If the hardcoded command-and-control servers are taken down, the malware algorithmically generates a list of predictable 15-character .xyz domains to find alternative C2 infrastructure.

The seed string for that DGA is "lazarus".

The Lazarus Group is, of course, one of the best-known threat actors in the world — a North Korean state-sponsored hacking operation linked to the 2014 Sony Pictures hack, the 2016 Bangladesh Bank heist, and the WannaCry ransomware attack itself. Lazarus has also been one of the most prolific cryptocurrency thieves in history, responsible for billions of dollars in stolen digital assets.

Now, a seed string in a DGA is not attribution. Developers choose seed strings for technical reasons — predictability, length, character distribution — and sometimes for no reason at all. It could be a deliberate false flag, an inside joke, or a coincidence. GTIG did not attribute Coruna to North Korea, and there is no public evidence linking the kit's development to Lazarus Group operations.

But the choice is worth noting precisely because of the context. Coruna's final payload is a cryptocurrency stealer that targets eighteen wallet applications. Lazarus Group is the world's foremost state-level cryptocurrency thief. The DGA generates domains using a string that is the name of that group. Whether this is misdirection, homage, or something else entirely, it is a detail that future attribution analysis will need to reckon with — especially as GTIG has stated that its investigation is ongoing.

What we can say with certainty is that UNC6691's PlasmaLoader payload carries clear indicators of Chinese-speaking developers. According to Cybersecurity News, all logging strings and code comments within the implant are written in Chinese, and some comment structures show evidence of generation by a large language model. Spencer Parker, iVerify's Chief Product Officer, described the quality gap between the two codebases to Betanews in stark terms: the Coruna exploit framework itself was professionally written at an elite level, while the financial theft components added by UNC6691 were notably inferior. That gap in craftsmanship bolsters the theory that UNC6691 acquired the kit secondhand and grafted on their own monetization layer — a criminal team stapling a rough payload onto architecture built by someone else entirely.

Why MDM Won't Save You: The Mobile Security Architecture Problem

Coruna exposes a structural weakness in enterprise mobile security that goes well beyond patch management. The standard enterprise approach to mobile security relies on Mobile Device Management (MDM) solutions that enforce policies, push updates, and monitor device compliance at the application layer. Coruna operates beneath all of that.

Goel told CSO Online that once an attacker achieves WebKit code execution and reaches kernel access, "the device can lie about its own state, and many policy controls become irrelevant in practice." — Gautam Goel, Senior Analyst, Everest Group, quoted in CSO Online, March 5, 2026

This is the critical point that goes underappreciated in the Coruna discussion. Once the exploit chain achieves kernel-level access and injects into a root daemon, the compromised device is capable of reporting a clean bill of health to its MDM server while simultaneously exfiltrating data. Enterprise security teams checking their MDM dashboards would see compliant devices. They would not see Coruna.

The problem is architectural. iOS's security model depends on layers: the application sandbox, code signing, PAC, PPL, and the Secure Enclave. Each layer is designed to contain failures in the layers above it. Coruna methodically defeats each layer in sequence. When you have a full chain from WebKit RCE to kernel privilege, the application-layer security model that MDM relies on is irrelevant. You are not managing a compromised app; you are managing a compromised operating system that is actively lying to you.

CSO Online reported a further analyst observation that cuts to the core of the problem: enterprise mobile security programs were designed around device management rather than device integrity, and were never built to detect exploitation occurring within the operating system itself. This is a fundamental design assumption that Coruna invalidates.

Apple's Lockdown Mode is the one defensive measure that both GTIG and iVerify confirmed will stop Coruna. The kit explicitly checks for Lockdown Mode and aborts if it is active. But Lockdown Mode is not deployed in enterprise environments at scale. It disables features that many organizations depend on — link previews in Messages, certain web technologies in Safari, wired connections to computers and accessories, and configuration profile installation. For organizations that rely on MDM-pushed configuration profiles, enabling Lockdown Mode can actually break their management infrastructure.

That leaves a gap: the one defensive measure proven to stop Coruna is incompatible with the primary enterprise mobile security architecture. And the primary enterprise mobile security architecture cannot detect Coruna.

The Closed Ecosystem Problem — And What Has to Change

Coruna puts a sharper edge on a debate that has simmered for years inside the mobile security industry: Apple's iOS does not give third-party security vendors the system-level access they would need to independently detect kernel-level compromise.

Rocky Cole, iVerify's co-founder and COO, articulated the problem precisely in iVerify's March 3 press release. Every other enterprise endpoint platform — Windows, macOS, Linux — has a security framework that allows the broader security community to help protect it. On iOS, that framework does not exist for third parties. Cole noted that comparable APIs do exist for macOS, a platform that is increasingly architecturally similar to iOS, and argued it was long past time for Apple to extend that access to iOS security vendors. He characterized the current situation as leaving security teams with three options: blindly trust Apple, try to build something independently with constrained APIs, or use iVerify Enterprise. None of those options, he argued, constitutes a real security ecosystem.

The implications extend to the enterprise context in a specific and concrete way. When an MDM dashboard reports a fleet of compliant, healthy devices, security teams have no independent means to verify that compliance reflects reality at the kernel level. Coruna demonstrates this is not a theoretical concern. It is a documented capability. An attacker who achieves root access via Coruna can, in principle, manipulate what the device reports upward to management infrastructure. The trust relationship between a mobile device and its MDM server has always assumed that the operating system reporting into that server is honest. Coruna removes that assumption.

The solution being proposed in regulatory circles is the Pall Mall Process, an international diplomatic initiative that Google explicitly cited in its Coruna report. The Pall Mall Process, launched in 2024 with participation from over 25 governments and private sector stakeholders, aims to establish shared norms around the development, sale, and use of commercial cyber intrusion capabilities. iVerify directly named it in its press materials as the framework designed to prevent exactly what Coruna represents: an exploit capability sold through commercial channels, losing control of its intended use within months, and proliferating into criminal ecosystems.

But the Pall Mall Process is voluntary. It has no enforcement mechanism. And it does not address the economic structure that makes proliferation inevitable. Sanchit Vir Gogia, chief analyst and CEO at Greyhound Research, identified the structural problem in remarks to CSO Online: the ecosystem involves exploit acquisition programs, vulnerability brokers, and secondary markets that facilitate the movement of offensive capabilities — and regulating a single category of vendor does nothing to address that underlying supply chain. The question of how Coruna moved from its original developer to a commercial surveillance vendor to Russian intelligence to Chinese cybercriminals is unanswered, and the Pall Mall Process offers no mechanism to answer it retroactively or to prevent the next iteration. The regulatory response will be measured in years. The threat it is responding to is operational now.

What would actually move the needle? Several technically deeper interventions are worth examining, none of which appear in standard remediation guidance:

A mandatory kernel attestation API for iOS. Apple already provides hardware-backed security attestations for some purposes — the Secure Enclave, for example, can attest that certain keys were generated on-device. Extending a similar architecture to allow trusted third-party security vendors to attest the integrity of the running kernel, in a privacy-preserving way, would close the gap that MDM cannot bridge. This is technically feasible and architecturally consistent with Apple's existing hardware security model. It would require Apple to accept that meaningful iOS security requires a trusted ecosystem of verifiers, not a single gatekeeper.

Exploit chain telemetry at the browser layer. WebKit executes JavaScript. Coruna's entire delivery infrastructure runs through WebKit. Apple's browser engine already includes some anti-exploitation mitigations, but the logging and telemetry visible to security tools is limited. A standardized hook that allowed enterprise security tools to observe anomalous JIT compiler behavior — the kind that signals a type confusion exploit in progress — would provide early warning that no application-layer MDM control currently offers.

Watering hole detection at the network layer, not the device layer. Because Coruna's delivery relies on a victim visiting a compromised website, enterprise DNS security tools theoretically have an opportunity to block the delivery domain before the exploit ever runs. In practice, Coruna uses a DGA for C2 fallback and rotates delivery infrastructure. But aggressive integration between mobile threat intelligence feeds — like the IOCs GTIG published to VirusTotal — and enterprise DNS security products would convert threat intelligence into active network-layer blocking faster than any device-side patch cycle. Zimperium's independent analysis of Coruna found that its web content filtering layer blocked more than 80% of the reported Coruna delivery domains in a zero-day fashion, before those indicators became publicly available — illustrating what is possible when threat intelligence reaches the network layer at machine speed rather than human speed.

Mandatory client-side monitoring as a procurement requirement. Third-party JavaScript executing in your users' browsers is the invisible attack surface that Coruna's cside analysis documented explicitly. No server-side security control observes what runs in a visitor's browser. Requiring enterprise mobile browser security that monitors in-browser script execution as a procurement standard — the way endpoint detection is now a procurement standard for desktops — would bring this attack surface into scope. It does not exist as a requirement today anywhere in enterprise security frameworks.

None of these solutions are available today at scale. They describe what a realistic post-Coruna mobile security architecture would need to look like to address the actual threat model, rather than the threat model that existed before kernel-level mass exploitation of iOS was confirmed.

The Delivery Vector Nobody Is Watching

Coverage of Coruna has focused almost entirely on the exploit chains, the CVEs, and the proliferation timeline. The delivery vector has received far less scrutiny, and that is a mistake. How Coruna reaches a device matters enormously, because it reveals an attack surface that extends far beyond the compromised and fake websites that headline most threat reports.

The Coruna payload is a JavaScript file. It does not need to reside on the server you are trying to protect. It goes wherever a JavaScript tag goes. And JavaScript tags go everywhere. According to cside's independent technical analysis of live Coruna samples, the payload could be distributed through a compromised programmatic advertising creative, a supply chain attack on a third-party analytics or chat widget, or a poisoned CDN cache. If any of those delivery mechanisms were used, the origin server's logs would show nothing unusual. The exploit runs entirely in the visitor's browser and reports results to a C2 domain the site owner has never heard of. The site owner would have no way of knowing their users were being exploited.

This is not a theoretical concern. The cside analysis confirmed that over 50 delivery domains were involved in the UNC6691 campaign, and that the infrastructure strategy involved deliberate abuse of major cloud CDNs to obscure the real origin server. At the time of public disclosure, the active C2 domains were fronted through Cloudflare, confirmed via URLScan passive DNS records — meaning the actual infrastructure behind the attack was hidden behind one of the internet's largest and most trusted network providers. The sites were also designed to encourage mobile access specifically, with prompts telling visitors to open the site from their phone for a "better experience." That social engineering nudge ensured the target arrived in Safari on iOS rather than a desktop browser where the exploit chain would not function.

The implications for web security teams are significant and largely unaddressed. The standard defensive posture for web security focuses on your own code: your servers, your application logic, your deployment pipeline. Coruna — or any payload like it — could reach your users through a third-party tag you did not write, a marketing pixel you inherited, an open source dependency two levels deep in your build chain, or a CDN asset cached from a vendor you have never audited. Your server-side logs would be clean. Your WAF would not have seen it. Your SIEM would have nothing to alert on. The only visibility layer where this class of attack is observable is client-side browser monitoring — a category that, outside of dedicated client-side security platforms, most organizations do not have.

The Orphaned Device Problem

There is a question at the center of the Coruna story that almost nobody is asking, and it is one that will matter for every mobile threat that comes after this one: who is responsible for iPhones that cannot be updated?

Coruna targets iOS 13 through iOS 17.2.1. iOS 13 was released in September 2019. Devices that shipped with iOS 13 include the iPhone 6s and iPhone SE (first generation), both of which cannot run any iOS version beyond iOS 15. That means there is a category of hardware in the real world that received no patch for several of the vulnerabilities Coruna exploits, and never will. The end of security update support is the end of security. Full stop.

According to Apple Insider reporting from early 2026, approximately 74% of iPhones capable of running iOS 26 (the current version) had updated to it as of February. That figure sounds encouraging until you calculate what it means for the other 26%, and until you account for devices that cannot run iOS 26 at all. In enterprise environments specifically, the gap compounds. MDM compliance reporting may flag a device as "up to date" relative to the latest version it can receive while that device remains vulnerable to multiple Coruna chains. A device cannot comply its way out of a hardware support limit.

This is a structural failure of the consumer device ecosystem that no patch cycle resolves. Enterprise security programs have well-established processes for handling end-of-life Windows or Linux machines: they get air-gapped, decommissioned, or replaced. Mobile device lifecycle management rarely operates with the same rigor. Phones get handed down, kept as backups, used by family members, retained as secondary devices — and in that long tail of use, they continue connecting to the same networks, the same Wi-Fi, and the same websites as devices with active security support. The question of who is responsible for communicating risk to the users of those orphaned devices — manufacturers, carriers, enterprise IT, or nobody — has no satisfying answer under current policy. Coruna makes that gap visible in the most concrete way possible.

Whether you are an individual user or managing devices at the organizational level, the response is the same in principle, even if the execution differs in scale.

Restart your device daily if you cannot patch. PlasmaLoader does not survive a full hardware reboot. It injects into the powerd daemon and lives in memory, which means a reboot clears an active infection. iVerify explicitly recommended daily restarts as a stopgap for devices that cannot immediately update. Critically, this is not a solution: a restarted device can be reinfected the next time it visits a compromised site. The restart clears the payload; it does not close the vulnerability. But if you are on an unpatched device and you have visited any suspicious financial, gambling, or cryptocurrency website, a restart is the fastest way to interrupt an active infection while you work toward patching.

Update immediately. Coruna does not work on iOS 26, the current version of iOS. Every device running iOS 13 through 17.2.1 is potentially vulnerable. If you cannot update a device, enable Apple's Lockdown Mode (Settings > Privacy & Security > Lockdown Mode). This is the single defensive measure confirmed to neutralize Coruna.

Use Private Browsing for unfamiliar sites on unpatched devices. The Coruna framework aborts if it detects Safari is in Private Browsing mode. This is not a patch, and it will not protect you from every threat, but it is a confirmed exploit-level abort condition for this specific kit. On any device you cannot immediately update, using Private Browsing when visiting unfamiliar financial, gambling, or cryptocurrency sites is a direct mitigation against the UNC6691 delivery mechanism.

Stop storing seed phrases on your phone. Coruna's PlasmaLoader payload specifically scans Apple Notes for BIP39 seed phrases and keywords like "backup phrase" and "bank account." It also decodes QR codes from your photo library. If you have ever saved a wallet recovery phrase in Notes, taken a screenshot of a QR code for a wallet, or stored banking credentials in a note, that data is at risk on any unpatched device. Move cryptocurrency holdings to hardware wallets. Store recovery phrases offline, on paper or metal, never on a connected device.

Audit your mobile device fleet. For enterprise security teams: identify every device in your environment running iOS versions older than 17.3. Those devices are within Coruna's targeting range. Do not rely solely on MDM compliance reporting if you suspect compromise — Coruna operates at a level that can subvert application-layer reporting.

Check iVerify's indicators of compromise. iVerify published detailed IOCs for Coruna-triggered infections and made its iVerify Basic app free through May 2026 specifically to help users detect compromise. GTIG published IOCs and YARA rules in a free collection on VirusTotal. Google has also added all identified malicious domains to Safe Browsing. Zimperium independently confirmed that its web content filtering layer blocked more than 80% of identified Coruna delivery domains as a zero-day response, before public IOC availability.

Key Takeaways

1. Coruna is the first confirmed mass exploitation of iOS devices in the wild. What was once the exclusive domain of nation-state surveillance operations — chaining together zero-days and advanced mitigation bypasses to compromise iPhones — is now being used at scale by financially motivated cybercriminals with no geographic targeting restrictions. iVerify confirmed at least 42,000 devices were infected in the UNC6691 campaign alone. The barrier between intelligence-grade exploit development and criminal deployment has collapsed.
2. The EternalBlue pattern is repeating on mobile. Government-developed or government-acquired exploit capability leaked into the broader threat ecosystem and was weaponized for mass criminal activity. EternalBlue gave us WannaCry and NotPetya. Coruna has given UNC6691 a cryptocurrency harvesting operation that targets anyone with an unpatched iPhone. The specific mechanism of proliferation — whether stolen, sold, or independently reconstructed from public vulnerability disclosures — remains unknown, but the outcome is identical.
3. Enterprise mobile security architecture has a fundamental gap. MDM solutions operate at the application layer. Coruna operates at the kernel layer. A fully compromised device can report compliance to its MDM server while actively exfiltrating data. The one proven countermeasure — Lockdown Mode — is largely incompatible with enterprise MDM workflows. This architectural tension needs to be resolved, and it will require changes from Apple, from MDM vendors, and from enterprise security teams.
4. No persistence does not mean no risk. PlasmaLoader clears on a full hardware reboot. That sounds reassuring, but a rebooted device visiting the same compromised site is immediately re-exploitable. The absence of persistence is a forensic artifact, not a safety feature. Restart your device as an interim measure; patch it as the only real solution.
5. Patch age is not the same as risk age. CVE-2021-30952 was patched in iOS 15.2. CVE-2023-43000 was patched in iOS 16.6. Neither was known to be actively exploited until March 2026. Vulnerabilities can sit in the wild, silently exploited, for years before anyone raises an alarm. The window between when a patch is available and when an exploit is publicly documented can be measured in years, not days. If your patching strategy assumes that old patches cover old risks, Coruna proves that assumption wrong.
6. Update your iPhone. Today. Coruna does not work on iOS 26, the current version of iOS. That single fact is the most powerful defense available. If you are reading this on an iPhone running iOS 17.2.1 or earlier, stop reading and update your device. Then come back and finish the article.
7. The delivery surface is wider than the headlines suggest. Coruna's JavaScript payload does not need to live on a malicious website to reach your users. A compromised third-party ad tag, a poisoned analytics script, or a hijacked CDN asset are all sufficient delivery mechanisms. Your server logs would be clean. Your WAF would see nothing. The only layer where this class of attack is visible is browser-level client-side monitoring, which almost no enterprise has implemented for mobile.
8. Nobody has answered the orphaned device question. A meaningful percentage of iPhones in the world cannot receive patches for Coruna's oldest vulnerabilities, because the hardware they run on has no supported path to a newer iOS version. Enterprise mobile lifecycle management has not kept pace with this reality. Coruna makes the cost of that gap explicit and measurable for the first time.

Coruna is not the last exploit kit of its kind. Both GTIG and iVerify have stated that their analysis is ongoing, with additional technical details expected in future publications. The commercial surveillance industry continues to develop tools of this caliber. The secondary market for exploits continues to operate. And the gap between targeted espionage and mass criminal deployment continues to shrink. What Coruna has proven is that this gap is now measured in months, not years — and that mobile devices are no longer exempt from the kind of systemic exploitation that has defined the desktop threat landscape for decades.

Sources: Google Threat Intelligence Group | iVerify Technical Blog | iVerify Press Release | CyberScoop | SC Media | SecurityWeek | BleepingComputer | The Register | CSO Online | Kaspersky Securelist | Cybersecurity News | The Hacker News | cside Technical Analysis | Help Net Security | Zimperium Technical Blog | Privacy Guides | Wired (original reporting)