Is CVE-2023-41990 (Apple Multiple Products Code Execution) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2023-41990 to its Known Exploited Vulnerabilities catalogue on 8 January 2024, 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 that allows for code execution when processing a font file.

What “exploited in the wild” means for this Apple CVE

For a vulnerability page like this, “being exploited in the wild” means more than theoretical risk or a proof of concept. It means there is credible evidence that attackers are actively using the flaw against real systems, which is why CISA’s KEV listing matters as a triage signal. The practical question is not just whether the bug exists, but whether exposure should be treated as an active incident risk.

That changes how teams read the issue: a code execution flaw in Apple mobile and desktop platforms is not a routine advisory item if exploitation is already observed. It should be handled as a time-sensitive remediation and detection problem, not a watchlist item for the next maintenance cycle. CISA’s KEV catalogue is the strongest operational indicator here, while the vendor advisory remains the source of version and fix details.

For background on how to prioritise actively exploited flaws, see the Zero-Day and Exploited Vulnerabilities Guide, which covers KEV-driven triage, emergency mitigation and post-patch hunting.

How to confirm exposure and scope the response

Start by determining which Apple-managed endpoints are in scope: iPhone, iPad, Mac, Apple TV and Apple Watch fleets, plus any shared devices that process untrusted content. The security question is not only whether the operating system is present, but whether the organisation has devices that receive external files, browse untrusted content or handle font parsing in user workflows.

If a device is exposed and the flaw is active in the wild, the first response is to verify whether the vendor fix has been applied and whether any compensating controls were already in place. In practice, this means aligning asset inventory, software version visibility and patch status before deciding whether a given endpoint can remain online. If patching is delayed, the operational objective becomes containment, not normal remediation pace.

Use the CISA Known Exploited Vulnerabilities Catalog to confirm the exploitation status, and check the CVE Program and vendor advisory for authoritative record details and remediation guidance.

Patch first, then look for signs of compromise

When a code execution issue is confirmed as exploited, patching is necessary but not sufficient. Teams should assume some chance of pre-remediation compromise and inspect for unusual process activity, suspicious persistence, unexpected downloads, browser or document-triggered execution paths, and any telemetry showing abnormal font or rendering-related crashes before the fix landed.

Where the flaw may have provided initial execution, the follow-on risk is secondary activity rather than the exploit itself. That is why post-fix review matters: an attacker who got code execution may have already dropped tooling, staged credentials or moved laterally. If you delay patching, you increase the window in which the exploit path stays available and make later investigation less conclusive.

For prioritisation help beyond the KEV signal, the FIRST EPSS resource can help teams compare exploit likelihood across broader vulnerability queues, even though KEV should drive the urgent decision here.

Risk and Threat Considerations

Actively exploited code execution flaws on endpoint platforms matter because they can turn a single malicious file or content object into full device compromise. On Apple fleets, the real risk is not just a crash or a one-off exploit attempt, but attacker foothold through a trusted user workflow that normally looks routine.

Failure mechanism: The attacker delivers or induces processing of a malicious font file, triggering code execution before normal user controls can stop it. Once execution lands, the attacker can stage payloads, harvest tokens or credentials, and establish persistence if the device is not quickly contained and remediated.

Impact: A successful exploit can expose user data, enable lateral movement into managed services, and create a detection gap if defenders treat the event as a generic software bug rather than an active exploitation path.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes prioritised vulnerability handling central to the response.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities on an emergency timeline.
NIST CSF 2.0	ID.RA-05 — Vulnerabilities are identified and mitigated before they can be exploited	The question is about confirmed exploitation and urgent risk reduction.
Recommendation — Use exploitation evidence to drive urgent mitigation and exposure reduction.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The answer depends on confirming exposure and tracking a vulnerable condition quickly.
	SI-2 — Flaw Remediation	The core action is fixing the exploited software flaw and validating the repair.
	SI-4 — System Monitoring	Post-exploit checks require monitoring for signs of compromise and follow-on activity.
Recommendation — Track vulnerable assets and verify remediation across the affected fleet. Apply the vendor fix and verify the remediation is effective. Inspect telemetry for exploitation indicators and suspicious post-compromise behavior.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as an emergency patching queue, then move immediately to exposure validation across all Apple platforms that can process untrusted content. If you have limited response capacity, address internet-facing and high-value user endpoints first.

What to verify: Confirm the vendor fix is deployed, confirm the vulnerable platform is not simply “present” but actually reachable in normal workflows, and confirm there is enough telemetry to reconstruct pre-patch activity if compromise is suspected. If telemetry is thin, preserve what you have before aggressive cleanup.

Practitioner takeaway: Once a flaw is in KEV, the operational question shifts from “is it exploitable?” to “how quickly can we eliminate exposure and prove it was not already abused?”

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org