CVE-2025-43520

What it actually does

This is a local memory-corruption vulnerability in Apple operating system kernel-level handling. A malicious application running on an affected device may corrupt memory in a way that either causes an unexpected system termination or enables writes to kernel memory. Because the CVSS vector requires local execution with low privileges and no user interaction after execution, the flaw is most relevant after an attacker has already convinced a user to install or run a malicious app, abused enterprise/mobile-device-management distribution, or chained it with another initial-access vulnerability. Successful exploitation can affect system availability and may provide a primitive useful for privilege escalation or sandbox escape, although the provided scoring emphasizes availability impact rather than confirmed confidentiality or integrity loss.

Why it matters to the business

Organizations with affected iPhones, iPads, Macs, Apple TVs, Apple Vision Pro devices, or Apple Watches face risk from malicious applications that can crash devices and potentially tamper with kernel memory. This can disrupt executive, mobile, point-of-sale, field, or kiosk workflows, and in a chained attack may help attackers deepen control over Apple endpoints. The issue is listed in CISA KEV with active exploitation reported in the wild and a remediation due date of 2026-04-03, so it should be treated as a mandatory, time-bound patching item even though the standalone CVSS and EPSS values are moderate/low. It is not currently identified as used in ransomware campaigns based on the supplied KEV metadata.

How an attack unfolds

An attacker first needs code execution on the target Apple device, typically by delivering a malicious or trojanized app, abusing sideloading or enterprise-signed distribution paths where available, or chaining from a browser, messaging, document, or app vulnerability that can launch attacker-controlled code. Once the app is running with ordinary user-level privileges, it triggers the vulnerable memory-handling path in the operating system. Exploitation corrupts memory and may produce a kernel memory write or crash. In the simplest case, this results in denial of service through unexpected system termination. In a more sophisticated chain, the kernel-memory-write condition may be combined with additional primitives to bypass platform protections, escape a sandbox, or elevate privileges. Active in-the-wild exploitation is reported, and the supplied threat context references DarkSword; defenders should assume exploitation may be targeted and may leave few network indicators because the vulnerable action is local on-device.

How to fix it

Upgrade affected Apple platforms to the fixed releases or later: iOS 18.7.2 / iPadOS 18.7.2, iOS 26.1 / iPadOS 26.1, macOS Sequoia 15.7.2, macOS Sonoma 14.8.2, macOS Tahoe 26.1, tvOS 26.1, visionOS 26.1, and watchOS 26.1. Where immediate patching is not possible, reduce exposure by blocking untrusted app installation, restricting sideloading and enterprise-signed apps, enforcing MDM compliance policies, removing unknown configuration/provisioning profiles, limiting developer-mode use, and monitoring for repeated kernel panics or suspicious application crashes. Prioritize internet-facing, executive, privileged-user, mobile fleet, kiosk, and shared-use Apple devices, and complete remediation before the KEV due date of 2026-04-03.

How to confirm the fix worked

Confirm each managed Apple device reports an operating system version at or above the relevant fixed release. For macOS, validate with system inventory, MDM posture, or the local `sw_vers` output. For iOS, iPadOS, tvOS, visionOS, and watchOS, validate through MDM device inventory and compliance reporting. Confirm that no exception groups remain on vulnerable builds and that update deferrals are not preventing installation. Attempted exploit validation should not be performed on production devices; instead, verify that test devices on fixed versions no longer reproduce the crash condition if a vendor-approved regression test is available. Also validate that controls are in place to prevent installation of untrusted apps and that unknown enterprise profiles or developer-mode exceptions have been reviewed.

Typical attack path

1. Identify users or devices running affected Apple operating system versions prior to the fixed releases.
2. Deliver a malicious application or gain local code execution through another exploit chain, social engineering, sideloading, or enterprise-signed app distribution.
3. Run code with low privileges on the affected device.
4. Trigger the vulnerable memory-handling condition from the malicious application.
5. Cause kernel memory corruption resulting in system termination or a kernel-memory-write primitive.
6. Optionally chain the primitive with other techniques to escape sandboxing, elevate privileges, disable defenses, or maintain access.
7. Remove or minimize traces such as the malicious app, provisioning profile, crash artifacts, or command-and-control communications.

How to detect it

There are no reliable public exploit-specific IOCs in the supplied data. Detection should focus on behavioral and forensic evidence: MDM inventory showing vulnerable OS versions, installation of unknown or recently added apps, unexpected enterprise-signed or sideloaded apps, new or suspicious provisioning/configuration profiles, developer-mode enablement, repeated kernel panics, unexplained reboots, and crash logs temporally associated with a specific app. On macOS, review Unified Logs, DiagnosticReports, panic logs, Endpoint Security/EDR telemetry, app quarantine events, Gatekeeper assessments, launch services activity, and new persistence items. On iOS/iPadOS/tvOS/visionOS/watchOS, use MDM telemetry, device analytics, crash/panic logs, installed-app inventory, profile inventory, and compliance history. Look for suspicious activity shortly before device termination events, including new app installation, profile enrollment, certificate trust changes, unusual outbound connections by a newly installed app, or security-control tampering. If DarkSword-related threat intelligence is available internally or from a trusted provider, correlate those indicators with Apple endpoint telemetry, but do not depend on the threat-actor name alone as an IOC.

What your security team should do

• Treat this as an active-exploitation KEV item and patch all affected Apple operating systems to the fixed releases or later before 2026-04-03.
• Use MDM or endpoint inventory to identify all iOS, iPadOS, macOS, tvOS, visionOS, and watchOS devices running vulnerable versions.
• Prioritize devices used by high-risk users, administrators, executives, developers, mobile workforces, kiosks, and shared operational roles.
• Block or tightly restrict untrusted applications, sideloading, developer mode, and enterprise-signed app distribution unless explicitly approved.
• Review and remove unknown or unnecessary configuration profiles, provisioning profiles, device-management enrollments, and certificates.
• Investigate devices showing repeated kernel panics, unexplained reboots, or crashes correlated with recently installed or unknown applications.
• Hunt for evidence of malicious apps and suspicious post-exploitation behavior rather than relying on network IOCs, because exploitation is local and may not produce unique network signatures.
• If compromise is suspected, preserve crash logs, unified logs, MDM inventory history, installed-app lists, profiles, and relevant endpoint telemetry before wiping or reimaging devices.