THREATS AND VULNERABILITIES
Coruna iPhone Exploit Kit: How Outdated iOS Devices Became a Business Risk
Coruna shows why “eventually updated” is not a defensible mobile-security policy. Google Threat Intelligence Group reported in March 2026 that the exploit kit targeted iOS 13 through iOS 17.2.1 and combined 23 exploits into five full chains. Google observed the toolkit in surveillance, suspected espionage, and financially motivated activity. At the time of Google’s report, devices running the latest iOS were not affected.
That last point is the business takeaway: supported updates can remove an attacker’s known path, while devices left behind accumulate exposure. The challenge is operational—knowing which phones access company data, proving their installed build, managing exceptions, and replacing hardware that cannot remain supported.
What Google reported
The Google Threat Intelligence Group report describes Coruna as a powerful exploit kit covering a broad range of older iOS releases. Google said the kit used five complete chains composed of 23 exploits and targeted versions from iOS 13 through 17.2.1.
GTIG reported several different uses during 2025: deployment by a surveillance vendor, watering-hole activity it associated with suspected Russian espionage actor UNC6353 against Ukrainian users, and a broad financially motivated campaign called UNC6691 that Google said operated from China. These are Google’s observations and attributions. They should not be converted into unsupported claims about a particular victim, operator, or business.
The research illustrates a commercial reality: exploit kits can preserve older vulnerabilities and select a chain based on the visiting device. That makes an outdated phone valuable even after public attention has moved to newer flaws.
Why outdated iPhones persist in business environments
Organizations commonly discover mobile update gaps in four places:
- personal devices allowed to reach business email without centralized compliance checks;
- devices that stopped checking in to management but retained valid cloud sessions;
- older hardware kept for a single executive, field, clinical, or authentication workflow;
- updates deferred because storage, application compatibility, travel, or user availability was never resolved.
Each exception may sound reasonable in isolation. Together they create a population that can remain reachable by well-maintained exploit tooling. A user-level iPhone security review can identify visible settings, but it cannot replace an enterprise inventory and deadline-based exception process.
A defensible mobile patch policy
Record more than the device name
Inventory should include model, serial or managed identifier, ownership, assigned user, OS build, update capability, management state, last check-in, business applications, and the identity account used. Where personal devices are allowed, collect only what the policy and legitimate business need require.
Define update deadlines by risk
Not every release has the same urgency. When Apple or a reliable primary source reports active exploitation, the policy should trigger an accelerated deadline and leadership visibility. Routine updates can follow a normal maintenance window, but critical exceptions should not disappear into a generic help-desk queue.
Apple’s security releases page is the authoritative place to verify current releases. Apple also publishes product-specific advisories and guidance for web-based attacks. Record the release and advisory reviewed, not just an informal statement that the phone is “current.”
Enforce the outcome
A deadline without an access consequence is a suggestion. Depending on business risk, enforcement may involve device-compliance policies, restricted application access, removal of business profiles, replacement, or a time-limited documented exception. Test enforcement on a controlled group before broad deployment, and provide a recovery path for legitimate failures.
Deal with unsupported hardware
An unsupported iPhone should not receive an indefinite waiver simply because it still powers on. Determine whether Apple provides the required security release for that model. If not, replace it or remove it from sensitive access. Document the owner, decision, compensating controls, and expiration date until replacement is complete.
Where Lockdown Mode fits
Google advised enabling Lockdown Mode when an affected device could not be updated. Apple describes Lockdown Mode as an extreme optional protection for the small number of people likely to face highly sophisticated attacks. It restricts selected messages, web technologies, invitations, wired connections, and profile behavior.
Lockdown Mode is not a substitute for updating or replacing an unsupported phone. It is an additional risk-reduction option for high-risk users or temporary situations. Organizations should test necessary workflows and document who can approve a temporary exception if a business function is affected.
Detection and response limitations
Ordinary iPhone applications do not have unrestricted visibility into other apps or the operating system. A mobile security app may provide useful network, configuration, or reputation signals, but it should not promise to detect every sophisticated exploit or certify that a device is clean.
If targeting is suspected, preserve the delivery message, full URL if available, time, device model, iOS build, network context, and account events. Review mobile-device-management, identity, email, and cloud logs. Specialist forensic assistance may be warranted for a high-risk person or a credible Apple notification.
Business controls to validate
| Control | Evidence to request | Failure that needs action |
|---|---|---|
| Inventory | Export showing assigned user, model, build, and last check-in | Unknown or stale devices still have cloud access |
| Patch policy | Written deadlines by severity and exploitation status | Critical updates rely only on user reminders |
| Enforcement | Test result for a noncompliant device | Outdated device continues sensitive access |
| Exceptions | Owner, reason, safeguards, expiration | Permanent exception without replacement plan |
| High-risk users | Named support and Lockdown Mode decision path | Executive or public-facing users have no escalation route |
| Incident response | Preserved message/device/account evidence | Factory reset occurs before triage decision |
The mobile-device security assessment can be used as an initial governance check. It does not test the phone for exploitation or replace a professional audit.
Sources
Validate mobile patch governance
A patching process should produce evidence, enforce deadlines, and close unsupported-device exceptions. Contact OC Security Audit for an independent review, and learn about Ali Hassani, CISO, who brings 25+ years of IT, cybersecurity, compliance, and infrastructure experience to practical risk decisions.
Update and correction history
- August 2026: Apple source links were revalidated and updated to current official canonical destinations; the surrounding analysis and conclusions were unchanged.
- July 2026: Initial analysis prepared from Google and Apple primary sources available through July 31, 2026.