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.
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.