For crypto holders, the central concern in SlowMist’s DarkSword investigation is not simply a malicious website. It is the possibility that a compromised iPhone could expose wallet storage, keychain data and recovery credentials—and that an attacker could manage stolen secrets and transfer funds from the same control panel.
Reporting context: SlowMist published the original analysis on October 19, 2026, at 17:00 UTC+8, based on forensic work conducted on October 16, 2026. The findings below describe that investigation, not a new incident occurring today.
From a browser exploit to a wallet-theft operation
According to SlowMist, the infrastructure combined browser-based exploit delivery, data-stealing payloads, device-management dashboards and wallet-processing tools. Some lure pages could trigger the delivery process when opened, without an additional click.
The report traces the operation to publicly available exploit code. Google Threat Intelligence Group’s March 18, 2026 report described DarkSword as a six-CVE iOS exploit chain targeting iOS 18.4 through 18.6.2; three vulnerabilities were being exploited as zero-days when observed.
Public repositories followed in March. On July 19, the adoemwanmei/DarkSword-PROV2 repository appeared with an exploit chain, delivery server, administrative interface and database. SlowMist reported that the examined infrastructure was deployed in late September and was still being updated on the October 16 forensic date.
The names describe different parts of the operation: DarkSword is the iOS exploit chain, Coruna is a separate chain for older iOS versions, and DK/DK10 are administrative-panel generations. The source code calls the 18+ chain ueyes.
Claimed coverage is not proof of compromise
The investigation makes an important distinction between a device visiting a page, a payload being listed for its iOS version, and a complete exploit succeeding.
| Evidence examined | What SlowMist reported | What it does not establish |
|---|---|---|
| Delivery entry point | Accepted iPhones running iOS 13.0 onward | That every accepted version could be compromised |
| Payload library | 1,045 entries across 24 version labels, extending to 26.6.1 | That every entry was functional or tested |
| Routing code | Complete paths identified for iOS 18.6–18.7.2 and 26.0–26.1 | Successful exploitation of every device in those ranges |
| Device list | Included devices on iOS 26.3, 26.5.2 and 26.6.1 | That those devices progressed beyond page registration |
SlowMist found that the landing-page loader admitted iOS 18.4.0–18.7.2 into the 18+ chain, but its routing-code analysis placed the complete path’s starting point at 18.6. It also identified complete code paths for several older iOS ranges, while other versions lacked the final privilege-escalation stage.
For newer versions, the report described unfinished research rather than demonstrated coverage. Files associated with CVE-2026-43818 were explicitly marked as not yet validated on physical devices. The actual versions successfully exploited could not be established from the available data.
What the dashboard numbers mean
The dashboard showed 57 devices, 10,125 theft records and 143,802 iOS logs. Its 6,115 visits used an approximately seven-day reporting window.
A separate 30-day funnel showed:
- 20,187 page visits;
- 20,056 collector loads;
- 1,210 device-active events;
- 1,187 exploitation events;
- 10 events labeled successful exploitation;
- 9 data-exfiltration events.
These are panel-reported counters with different time windows—not an independently verified count of compromised wallets. The source does not establish a confirmed monetary-loss total.
Why wallet holders are specifically exposed
SlowMist’s code comparison found wallet-focused additions to a more general data-theft implementation. These included keystore processing, React Native AsyncStorage access and keychain-unpacking functionality.
The examined code named wallets including imToken, TokenPocket, TronLink, MetaMask, OKX, Coinbase, Exodus, BitKeep, Gate and Trust Wallet. Those references demonstrate targeting in the implementation; they do not establish successful theft from every listed application.
The panel’s recovery-phrase management interface displayed mnemonic phrases, private keys, derived addresses and on-chain balances. It also offered decryption, balance checks and a fund-consolidation function. This connects device-data collection to potential asset transfers, although the report does not quantify completed transfers.
The post-exploitation components also contained commands for collecting photos, contacts, messages, Wi-Fi passwords, location information, clipboard contents and iCloud tokens. One control component described itself as running inside SpringBoard until reboot. That description should not be interpreted as evidence that rebooting would make already exposed credentials safe again.
Some apparent capabilities were still unfinished
SlowMist also found interfaces and scripts for WhatsApp, Telegram, notes and browsing records. However, parts of the messaging functionality remained incomplete: code included an unresolved decryption state, and pages could fall back to sample data when backend interfaces were unavailable.
A displayed interface is therefore not sufficient evidence of completed account takeover. The same caution applies to payload labels and registered devices.
Source-supported steps for holders
SlowMist recommends three practical responses:
- Keep iOS updated. Do not remain indefinitely on an older release. The report also stresses that updates alone do not address every aspect of the wider malicious-delivery operation.
- Avoid links of unknown origin, particularly short links received through texts or private messages. In the reported delivery model, opening a page in Safari could be enough to start the exploit attempt.
- Treat suspected exposure as a credential-compromise concern. If a device visited a suspicious landing page, SlowMist recommends creating a new wallet with a new recovery phrase on a separate device that did not visit the page, then transferring assets. Treat the old phrase and private keys as exposed rather than reusing them.
The report further recommends checking accounts across relevant chains for unusual transfers and approvals, revoking unused approvals, and preserving Safari history, crash records and suspicious transaction records.
The key distinction: a suspicious page visit is not proof of successful exploitation, but changing device software cannot undo disclosure of a recovery phrase or private key that has already occurred.
Original SlowMist article — published October 19, 2026, 17:00 UTC+8.