Yes. CISA added CVE-2016-4655 to its Known Exploited Vulnerabilities catalogue on 24 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. The Apple iOS kernel allows attackers to obtain sensitive information from memory via a crafted application. Any organisation running the affected product should treat remediation as urgent.
How to treat this as an actively exploited iOS vulnerability
CVE-2016-4655 is not just a historical iOS flaw to note and file away. Once a vulnerability is in CISA’s Known Exploited Vulnerabilities catalogue, the operational question changes from “is this serious?” to “where is the exposure, and how quickly can we remove it?” For mobile fleets, that means inventory first, then rapid enforcement through managed update channels and exception handling.
Because the issue is an information disclosure in the Apple iOS kernel, the immediate concern is what sensitive data may have been exposed on devices that remain in use or were previously targeted. That makes device population, patch status, and user cohort more important than abstract severity language. If the affected device estate includes corporate email, MDM-managed apps, or access to internal services, the business impact extends beyond the handset itself.
For a broader response playbook, use the Mobile Device Security Guide to anchor remediation in fleet inventory, enrolment state, and mobile policy enforcement rather than treating this as an isolated CVE.
What the vulnerability can expose in practice
The direct risk in this case is memory disclosure, which can leak data that was never meant to be user-visible. On mobile devices, that can include session material, app state, cached content, or other sensitive runtime information depending on what the vulnerable process held in memory at the time.
This is why exploitation questions for mobile kernel flaws are rarely limited to the vulnerable component alone. A crafted application can become the delivery path, but the real concern is whether the device had anything valuable in memory when the flaw was triggered. In enterprise settings, that can include business data, authentication artifacts, or operational information that helps an attacker pivot later.
For readers who need to understand how disclosure issues typically intersect with broader exploitation and downstream abuse, NHIMG’s State of NHI & AI Agent Breach Report 2026 is a useful companion because it shows how leaked secrets and exposed runtime material are often the real prize after initial compromise.
What to do when patching is delayed or devices are already at risk
If immediate remediation is not possible, reduce the device’s value to an attacker. That means tightening mobile application permissions, limiting access to high-value internal systems from untrusted or overdue devices, and reviewing whether the device still needs to carry credentials that can be reused elsewhere.
For iOS fleets, the practical control is not simply “await the next update”. It is to contain blast radius while update windows, user coordination, or legacy compatibility issues are addressed. If a device cannot be updated promptly and it can still reach sensitive services, treat it as a higher-risk endpoint until the exposure is closed or access is curtailed.
When the concern extends to application-level leakage on mobile devices, NHIMG’s iOS apps leaking hard-coded secrets is relevant because it reinforces the separate but connected problem of secret exposure on mobile platforms.
Risk and Threat Considerations
Actively exploited iOS kernel disclosure flaws are attractive because they can be used before users notice anything unusual. The attacker does not need full device control to make the flaw valuable, only a reliable way to trigger disclosure and collect what was in memory at the time. That makes unattended, unmanaged, or slow-to-update mobile populations disproportionately exposed.
Failure mechanism: The kernel leaks memory content after the attacker delivers a crafted application, so the weakness is exploitation of the memory disclosure path rather than a user-visible crash or obvious compromise signal.
Impact: Sensitive information exposed through memory disclosure can accelerate follow-on access, session abuse, or broader compromise, especially when the affected device also holds enterprise data or credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Actively exploited CVEs require prioritised remediation and exposure tracking. |
| Recommendation — Prioritise and verify remediation for KEV-listed iOS devices. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This FAQ is about confirming exposure and responding to an actively exploited CVE. |
| SI-2 — Flaw Remediation | The core response is to apply the fix or mitigation for the exploited flaw. | |
| Recommendation — Scan affected mobile assets and track remediation status. Remediate the iOS vulnerability through approved update channels. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KEV-listed exploitation changes prioritisation and exception handling for mobile fleets. |
| Recommendation — Treat KEV exposure as an urgent risk decision with defined escalation. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Memory disclosure can expose secrets or session material on mobile devices. |
| Recommendation — Rotate any exposed secrets, tokens, or sessions if disclosure is suspected. | ||
Practitioner Guidance
What to prioritise: Start with device inventory and exposure confirmation. Identify which enrolled devices are on the affected product family, which ones are overdue for remediation, and which user groups would face the highest business impact if memory disclosure occurred.
What to verify: Confirm whether the device has been updated to a version that addresses the issue, whether MDM enforcement is actually blocking stale endpoints, and whether access policies still allow outdated devices to reach internal resources.
Decision rule: If a device cannot be remediated quickly but still reaches corporate data or privileged services, treat it as a containment problem, not just a patching problem. Restrict access first, then complete remediation, then review whether any exposed data or sessions need follow-up action.
Practitioner takeaway: For KEV-listed mobile kernel flaws, the operational priority is to shrink exposure immediately, because the real risk is not only the bug itself but the sensitive material an attacker may recover before you can patch.
Related resources from NHI Mgmt Group
- Is CVE-2016-6415 (Cisco IOS, IOS XR, and IOS XE IKEv1 Information Disclosure) being exploited in the wild?
- How do you patch or mitigate CVE-2016-4655 (Apple iOS Information Disclosure)?
- CVE-2016-4655 (Apple iOS Information Disclosure)
- Is CVE-2016-3351 (Microsoft Internet Explorer and Edge Information Disclosure) being exploited in the wild?