iVerify Uncovers DarkSword, iOS Exploit Framework That Bypasses…

iVerify published a technical analysis of DarkSword, a sophisticated multi-stage iOS exploit framework that leverages JavaScriptCore JIT vulnerabilities via watering-hole attacks on compromised legitimate websites. The discovery, made in collaboration with Google Threat Intelligence and Lookout, documents a full JavaScript chain from remote code execution in Safari to kernel privilege escalation, leaving no persistent implants. Targeted iOS versions are 18.4 through 18.6.2, per internal exploit configuration files analyzed by the source.

iVerify published the technical analysis of DarkSword on March 18, 2026, a multi-stage iOS exploit framework that targets Apple devices through watering-hole attacks on compromised legitimate websites. The discovery, made in collaboration with Google Threat Intelligence and Lookout, documents a complete JavaScript chain from remote code execution in Safari to kernel privilege escalation, without leaving persistent implants. Targeted iOS versions are 18.4 through 18.6.2, according to the internal configuration of the exploit files analyzed by the source.

Key Takeaways

iVerify identified two compromised Ukrainian domains as entry points: novosti[.]dn[.]ua and 7aac[.]gov[.]ua, with an invisible iframe redirecting to a server in Estonia.
The exploit chain leverages JavaScriptCore JIT vulnerabilities specific to version bands: RegExp match type confusion for iOS 18.4-18.5 and StoreBarrierInsertionPhase use-after-free for iOS 18.6-18.6.2.
Google Threat Intelligence was already aware of the chain and had reported it to Apple; the company also observed DarkSword used against entities in Ukraine, Saudi Arabia, Turkey, and Malaysia.
The attack terminates after data extraction: the code includes no persistence mechanisms and disables itself autonomously, according to the iVerify post.

How the iOS Attack Chain Works

DarkSword stands out for being built entirely in JavaScript, with no binary implant or traditional mach-o libraries. Delivery occurs via an invisible iframe injected into pages of compromised legitimate sites: the source explicitly cites novosti[.]dn[.]ua and 7aac[.]gov[.]ua, both domains relevant to users in Ukraine. The redirect leads to a server geolocated in Estonia that, according to iVerify, served payloads exclusively to IP addresses originating from Ukraine.

The first stage exploits vulnerabilities in the Safari JavaScriptCore JIT engine. For iOS 18.4 and 18.5, iVerify documents a type confusion attack in RegExp matching; for 18.6 and 18.6.2, a use-after-free in the StoreBarrierInsertionPhase. Both techniques achieve code execution within the browser process.

From this position, the chain bypasses three iOS hardware and software mitigations: TPRO (Trusted Process Region Only), PAC (Pointer Authentication Codes), and SPRR (Special Purpose Register Restrictions). The mechanism, detailed by iVerify, abuses internal dyld structures located in writable stack memory. The subsequent sandbox escape passes through the GPU process, exploiting an out-of-bounds write in the ANGLE graphics framework. Kernel privilege escalation completes the device compromise.

"The entire chain is built in JavaScript and does not contain any traditional binary implant or mach-o library which would be injected into other processes"

What iVerify Verified and What Remains Unproven

The primary source documents verifiable elements with precision: the exploit chain filenames (/rce_module.js, /sbx0_main_18.4.js, /pe_main.js), the target iOS versions with their respective JIT techniques, the compromised domains, the Estonia server with IP geofencing, and the collaboration with Google and Lookout. iVerify states it dynamically reproduced the attack on used iPhones running iOS 18.6.x, after failures with earlier versions.

Other claims lack independent corroboration in the dossier. The "MFA bypass" is mentioned by iVerify but the technical mechanism is not detailed in the available material. Similarly, "real-time detection" via iVerify's MEDR product is a vendor promotional claim, lacking external verification. Attribution of the threat actor to Russian operators rests on "Russian comments in early code stages" and links to the Coruna actor reported by Lookout, but the source does not expose infrastructure elements enabling definitive attribution.

The name "DarkSword" derives from a variable in the implant code: const TAG = 'DarkSword-WIFI-DUMP'. The source documents that exfiltration includes WiFi passwords, but does not specify the full nature of extracted data nor the volume of devices actually compromised.

What to Do Now

Users with iPhones running iOS versions 18.4 through 18.6.2 should verify the availability of an update to iOS 26.1 or later, as indicated by iVerify as the version with patches applied. The source does not document alternative mitigations for devices that cannot update.

Organizations with users in Ukraine, Saudi Arabia, Turkey, or Malaysia — the four countries where Google observed targeting — should consider analyzing web traffic toward the known compromised domains. iVerify has published indicators of compromise related to novosti[.]dn[.]ua and 7aac[.]gov[.]ua, along with the Estonia server IP.

DarkSword's lack of persistence has a concrete operational implication: a compromised device will show no residual implants after a reboot, but remains vulnerable to reinfection if the user visits compromised sites again. This pattern requires repeated checks of browsing history rather than traditional forensic scans.

The source provides no instructions for verifying whether a specific device has been compromised, nor open-source detection tools. Claims of detection by iVerify's MEDR product remain independently unverifiable in the dossier.

The Timeline the Source Does Not Close

iVerify reports that the exploit server showed files with a last modification date of December 23, 2025, according to information provided by NGNG. The analysis was published nearly three months later, on March 18, 2026. The source does not clarify when iVerify began its analysis, nor whether exposure of the compromised domains continued during that interval. Apple has not released official confirmation of the underlying vulnerabilities: iVerify indicates patches would be present in iOS 26.1, 26.2, and 26.3, but this data comes exclusively from the vendor source.

Google Threat Intelligence, cited in the post, was already aware of the exploit chain and had reported it to Apple before contact with iVerify. Lookout collaborated by flagging a suspicious URL "possibly related to the threat actor from Russia linked with Coruna." This network of collaborations corroborates the framework's existence, but does not verify iVerify's product promotional claims.

Questions the Brief Does Not Answer

Is DarkSword Still Active Against Vulnerable iPhones?

The source does not document the current status of the compromised domains or the Estonia server. iVerify published the analysis on March 18, 2026, but does not specify whether the infrastructure remains operational or has been taken down.

Why Does the Attack Leave No Persistence Traces?

According to iVerify, the code is designed to "disengaged after successful data extraction." This architectural choice reduces the detection surface for forensic tools, but the dossier does not explain whether it is motivated by evasion or by operational limits of the operators.

What Is the Actual Role of Google and Lookout in the Discovery?

Google Threat Intelligence was already aware of the exploit chain and had reported it to Apple, according to the iVerify post. Lookout flagged a suspicious URL linked to the Coruna threat actor. Both collaborations corroborate the framework's existence, but do not constitute independent verification of iVerify's MEDR product promotional claims.

DarkSword's technical structure — JIT exploit in JavaScript, bypass of hardware mitigations via dyld, graphics sandbox escape, absence of persistence — represents a significant evolution in the sophistication of publicly documented mobile attacks. The cautiously optimistic reading is that this exposure makes the chain more traceable; the cautiously pessimistic one, that its pure JavaScript implementation lowers the detection threshold for traditional tools. Both remain hypotheses: the source provides no data on detection rates or on campaigns observed beyond the four nations cited by Google.

Information is based on the cited source and current as of publication.

Sources

Sources and references