Is CVE-2023-38606 (Apple Multiple Products Kernel Unspecified) being exploited in the wild?

Yes. CISA added CVE-2023-38606 to its Known Exploited Vulnerabilities catalogue on 26 July 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple iOS, iPadOS, macOS, tvOS, and watchOS contain an unspecified vulnerability allowing an app to modify a sensitive kernel state.

How to tell whether this CVE is being exploited in the wild

For an exploited-vulnerability question like this, the first check is whether a trusted public authority has already moved the CVE into an active-exploitation list. In practice, that means confirming the CVE in CISA’s Known Exploited Vulnerabilities Catalog and cross-checking the record in the CVE Program and NIST National Vulnerability Database for the canonical vulnerability entry.

The practical question is not just whether exploitation is possible, but whether defenders should treat the issue as already active and time-sensitive. A KEV listing changes prioritisation immediately because it indicates confirmed exploitation in the wild, even before every affected estate has been inventoried or patched.

For a response playbook, the useful distinction is between exploitation confirmation and local exposure confirmation. CISA’s listing answers the first, while your own asset inventory, telemetry and version data answer the second. Both matter because an exploited CVE can still be irrelevant to a specific environment if the vulnerable product is absent, but it should still be handled as a high-priority threat for any potentially affected fleet.

What the Apple kernel flaw means operationally

This CVE matters because the issue sits in the kernel path of multiple Apple operating systems, so successful abuse can have consequences beyond a single app process. When a vulnerability lets an app modify sensitive kernel state, the security boundary being crossed is foundational: attackers may gain a route from ordinary app execution into system-level control conditions.

That makes the operational concern broader than one device class. Apple iOS, iPadOS, macOS, tvOS and watchOS all sit in the same product family, so security teams should assume the same issue may appear across endpoints, managed mobile devices and user-owned systems that are not under the same patch cadence.

For readers who want the broader vulnerability-response context, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide covers the triage pattern practitioners use when a flaw is already in active use, including KEV-driven prioritisation and post-patch validation. The same response logic applies here: confirm exposure, accelerate remediation, and verify that the exploit path is no longer usable.

How to respond when patching cannot happen immediately

When immediate remediation is blocked by change freeze, device ownership, or operational dependency, the right interim response is to reduce blast radius and increase visibility rather than wait passively. That usually means isolating high-risk endpoints, tightening app installation paths, and using mobile device management or endpoint controls to make the vulnerable population smaller and easier to observe.

You should also check for signs of earlier compromise before and after remediation. For kernel-level abuse, that means looking for unusual crashes, process anomalies, permission changes, suspicious persistence, and any telemetry that suggests the device was already controlled when the flaw was still open.

If you need a decision framework for the broader remediation workflow, NHIMG’s Vulnerability Management Guide is the natural companion for prioritisation, exception handling and verification. It is especially useful where a KEV-listed issue must be folded into normal remediation queues without losing sight of exposure, SLA pressure and exception tracking.

Risk and Threat Considerations

KEV-listed vulnerabilities attract rapid exploitation because they compress the attacker’s work: the exploit path is publicly known, defenders are often still catching up, and exposed devices can be targeted at scale. Kernel-impacting flaws are especially attractive because they can turn a single foothold into deeper system control or facilitate persistence that is harder to detect than a user-space compromise.

Failure mechanism: A malicious app or payload abuses the kernel-state modification weakness to cross a trust boundary, which can undermine device integrity and make the compromise harder to contain.

Impact: The likely consequence is elevated attacker control over affected Apple devices, with potential follow-on risks to data access, persistence and lateral movement within managed environments.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Risk Identification	Active exploitation status directly affects vulnerability risk prioritisation.
	PR.PS-03 — Least Functionality	Kernel-level abuse on endpoints is reduced by limiting unnecessary apps and services.
Recommendation — Prioritise remediation of KEV-listed vulnerabilities over routine backlog items. Restrict installable apps and services to shrink exploitable surface area.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-driven response is a continuous vulnerability management use case.
Recommendation — Track, prioritise and remediate exploited vulnerabilities on a tight SLA.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Confirmed exploitation requires exposure checking and remediation verification.
	SI-2 — Flaw Remediation	The question is about response to an actively exploited flaw.
Recommendation — Scan and verify whether affected Apple devices remain vulnerable. Apply and validate vendor remediation as soon as possible.

Practitioner Guidance

What to verify: Confirm whether any Apple devices in scope are running the affected product families, then verify whether they are still exposed in production, BYOD, or high-trust mobile workflows. Do not rely on a general patch-compliance report if device ownership or enrollment status is unclear.

Decision rule: If the CVE is listed in KEV and you cannot prove the device is already remediated, treat it as a live remediation priority rather than a routine backlog item. If patching must wait, use compensating controls and document the exception with an expiry date.

Practitioner takeaway: For a KEV-listed kernel flaw, the correct mindset is exposure-first, not exploit-theory-first, because confirmed active use means the remaining question is where you are still vulnerable and how quickly you can close it.