← Back to articles
Threat awarenessEXPLAINER · 5 MIN READ

DarkSword: six CVEs across several layers of iOS

The public reports connect JavaScript, graphics, shared-memory and kernel flaws. Understanding the kit also requires separating its payloads and following Apple’s later backports.

Conceptual illustration: A phone supports separate browser, graphics, service and kernel compartments with highlighted isolation boundaries.

DarkSword crosses several parts of iOS, from web-content processing to more privileged system components. The public reports describe different failures at those layers, plus different payloads in separate deployments. Keeping them distinct gives a clearer account of what the kit did and which updates address it.

Six CVEs, with three reported as zero-days

Google Threat Intelligence Group’s March 18, 2026 report identifies six CVEs in DarkSword, three of which it says were exploited as zero-days. It reports support across iOS 18.4 through 18.7 and observations involving several actors and countries. The report associates different deployments with GHOSTBLADE, GHOSTKNIFE and GHOSTSABER; behavior attributed to one payload should not be generalized to all three.

Google’s original DarkSword investigation

iVerify examined a configuration covering iOS 18.4 through 18.6.2, a narrower range than Google reported. The samples can differ without the reports contradicting one another. iVerify also describes memory-resident execution and recoverable browser-related evidence, so a short-lived process should not be read as leaving no traces.

iVerify’s independent DarkSword analysis

The reported components and fixes

The table groups the public CVEs by the component and security property involved. It summarizes the findings and historical corrections rather than presenting the entries as an execution sequence.

Component and CVE

Publicly described failure

Historical fix reference

JavaScriptCore: CVE-2025-31277

Memory corruption associated with JIT type assumptions

iOS 18.6

JavaScriptCore: CVE-2025-43529

Use after free affecting object lifetime

iOS 18.7.3 and 26.2

ANGLE: CVE-2025-14174

Out-of-bounds memory access in graphics processing

iOS 18.7.3 and 26.2

Kernel: CVE-2025-43510

Improper changes to memory shared between processes

iOS 18.7.2 and 26.1

Kernel: CVE-2025-43520

Memory corruption with kernel-write impact

iOS 18.7.2 and 26.1

dyld: CVE-2026-20700

Memory corruption associated with a code-flow protection bypass

iOS 26.3

Google supplies the association with DarkSword and the JIT and code-flow context. Apple’s release records supply the corresponding product fixes and vendor impact descriptions. These are historical release references; later backport guidance appears below.

Apple’s iOS 18.6 security content

Apple’s iOS 18.7.3 security content

Apple’s iOS 18.7.2 security content

Apple’s iOS 26.3 dyld correction

Type assumptions and object lifetimes

A just-in-time compiler makes execution faster by specializing it around assumptions about values and objects. If an assumption stops being valid, execution needs a safe fallback. Interpreting an object using an incompatible type or representation can produce type confusion.

Garbage collection tracks which objects remain alive. A use-after-free occurs when code accesses storage after an object’s valid lifetime ends. Optimized execution and runtime bookkeeping still have to agree about that lifetime, even with automatic memory management.

Two bugs in one JavaScript engine can therefore need different fixes. Their presence does not establish that ordinary JavaScript escapes the process or that every engine memory error provides access to the rest of the phone.

Shared memory and protected pointers

Sharing memory between processes makes the ownership of changes a security concern. Copy-on-write designs are intended to separate a writer’s modifications when required, while allowing safe sharing beforehand. A mismatch between the intended isolation and the actual memory state can undermine that contract. Google connects CVE-2025-43510 to this class; Apple describes its repair in terms of improved lock-state management.

Pointer authentication addresses another property: the integrity of protected pointer use. It should not be confused with encryption of all application data or with the authorization policy for a system service. Apple’s CVE-2026-20700 entry explicitly includes an existing memory-write capability in its impact description. That prerequisite matters when interpreting the flaw as part of a broader chain.

Read each correction against the restriction it restores. A graphics-process flaw, a shared-memory flaw and a kernel flaw concern different parts of the design. That also helps explain why a bug’s role in a chain can be more consequential than its standalone description suggests.

Include Apple’s later backports

Apple released iOS 18.7.7 on March 24, 2026 and expanded its availability to more devices on April 1, explicitly referring to DarkSword protections. An early report’s first-fixed-version table must not be used to claim that the iOS 18 branch necessarily remained unprotected afterward.

Apple’s iOS 18.7.7 release and expanded availability note

Apple’s later web-attack guidance says current updated releases across supported older branches are protected from these specific attacks and still urges installation of the latest compatible update. It also identifies protection from Lockdown Mode for the reported attacks. Neither statement is a guarantee against unrelated future vulnerabilities.

Apple’s updated guidance for these web attacks

A vanished process does not close an investigation

Handle software repair, evidence preservation and account recovery as separate tasks. An update corrects covered vulnerabilities; a reboot changes running state. Neither tells you whether information or reusable sessions were copied earlier. If targeting is credible, preserve the records and review affected access from a trusted device.

The useful account of DarkSword combines the individual failures with the payload and version actually observed. Keep that context alongside the later patch guidance, rather than treating one recovered configuration as a permanent description of every iPhone’s exposure.

Source check: September 8, 2026. The underlying research and incident observations belong to the organizations cited below. This article discusses public mechanisms and remediation history, not an operational reconstruction of the exploit.

Published by Short Circuit LLC. Questions or corrections? Contact us