Why I believe dark times are ahead for cybersecurity

My honest opinion is that dark times are ahead for cybersecurity. AI is changing how much work an attacker can attempt, and I worry that many projects and individuals will struggle to keep up. DarkSword is one concrete example of the kind of exposure that makes me take that future seriously.

I also believe we can come out of this stronger: by understanding our tools, learning to protect our secrets and taking more deliberate control of our data. There is strength in keeping our keys, backups and confidential information in our own hands, with the knowledge to protect and recover them.

Author's perspective

Why I expect the pressure to grow

I expect more vulnerabilities to be found, more systems to be compromised and more wallets to be drained as AI tools become more capable and autonomous. This is my assessment of the direction of travel, not a measured claim that the number of attacks rises every single month.

My concern is the combination of local models, affordable compute and repeatable work. A person can buy a small computer or GPUs and run a model locally, subject to its size and memory requirements. A Mac mini or a couple of graphics cards cannot run every frontier model at useful speed, but the broader point stands: access to useful automation no longer depends entirely on a hosted service. With locally controlled weights, an operator can also choose variants whose refusal behaviour has been reduced.

A well-funded group can devote more hardware to parallel agents and keep them working on one target for days or weeks. I see a risk that this could increase the volume and persistence of vulnerability research faster than some projects can investigate findings and ship fixes. More hardware does not guarantee successful exploitation; tools, expertise, access and the target's defences still matter.

Specialised models are already part of this picture. For example, the WhiteRabbitNeo model card describes a model series intended for both offensive and defensive cybersecurity. Fine-tuning means further training a model for particular tasks. A security focus is not proof of malicious intent, and removing refusals is not proof that a model can reliably discover or exploit new vulnerabilities. [18]

In my own observations, an “uncensored DeepSeek 4.1” model reached around 70,000 downloads in a month. This is a personal observation that has not been independently verified. Downloads are not a count of unique people, and they do not establish how many users intend to attack anyone. What concerns me is the interest in running capable models outside the controls of a hosted service.

There is also documented evidence of AI-assisted attacks. Anthropic reported disrupting an espionage campaign in which attackers used Claude Code to automate substantial parts of their operations. Its account also describes limitations, including fabricated credentials and incorrect claims of success. That is evidence of misuse of a hosted model; it does not verify the local-model download figure or establish that DarkSword itself was built with AI. [19]

Defenders can use the same progress to find flaws and improve their response. My concern is that we cannot assume every project will keep pace. If all my money were in crypto, I would take this as a reason to reconsider both that concentration of risk and the way the keys are held. The practical question is how much one compromised device, one exposed backup or one mistaken signature could cost me.

The risk can begin with an ordinary website

This concern is personal for me. In conversations with people I know whose wallets were drained, the suspected routes included ordinary websites, adult sites and compromised advertisements. I treat those accounts as personal testimony: they do not establish the entry point or prove that DarkSword was involved.

In plain terms, a browser downloads and runs scripts as part of loading a web page. There does not have to be a separate file to save or an application to install. Malicious code inserted into a site or a resource it loads can arrive through that same process. DarkSword went further by exploiting browser and operating-system flaws on vulnerable devices. Loading a script alone does not give it access to a wallet. [2]

That is what makes this case relevant to my wider concern. The starting point can be something as ordinary as opening a website. Understanding what has to happen between that visit and access to our secrets helps us make better decisions about where those secrets should live.

DarkSword: a concrete example

DarkSword is an exploit kit publicly described in March 2026 by researchers at Google, iVerify and Lookout. An exploit is a way of using a specific software flaw to violate its security restrictions. The kit contained different initial-stage variants for particular versions of iOS. iVerify examined configurations for iOS 18.4–18.6.2; Google also found support for iOS 18.7. This describes the samples studied, rather than claiming that every iPhone running one of those versions was necessarily infected. [1] [2]

Discussions of theft sometimes mention CVE-2025-43300 in ImageIO and CVE-2026-86950 in CoreGraphics alongside DarkSword. These concern separate file-processing flaws. Neither CVE is part of the DarkSword chain published by the researchers. The browser attack and an attack using a specially crafted image should therefore be examined separately. [1] [10] [11]

The simultaneous loss of funds from several applications makes compromise of the shared device a possible hypothesis. It does not establish a particular CVE, the initial entry method or whether a seed phrase was extracted. Such a conclusion requires device data, attack artefacts and transaction analysis.

The boundaries an attack must cross

Ordinary JavaScript on a web page runs within the browser's capabilities. It has no standard permission to read another application's files. In iOS, applications are isolated in sandboxes, and access to protected resources is further restricted by system permissions called entitlements. Even ordinary UNIX user privileges do not describe Apple's entire access model. [3]

Several boundaries therefore separate loading a page from accessing a wallet. First, the attacker must break the security of code execution inside the browser process. Then they must overcome that process's restrictions and gain broader capabilities within the system. Finally, they must reach a specific secret or a mechanism that allows it to be used. Success at one stage does not prove success at the others.

This architecture explains why attackers need a chain of vulnerabilities. A web-content processing flaw may provide only an initial foothold, while a local kernel flaw becomes dangerous once the attacker can interact with it. Together, they create a path that neither vulnerability provided on its own. [7]

From web content to system access

The initial browser stage

In the campaign examined by iVerify, a visitor opened a compromised legitimate website. An embedded script loaded an invisible iframe and then an exploit loader. The loader selected the appropriate attack variant. The user did not have to download an installation package or confirm access to a wallet. [2]

This is a watering-hole scenario: infection through a resource visited by a chosen audience. It explains why caution when installing applications does not cover every route of entry. In this case, visiting the page was the relevant action. Calling this delivery unconditionally zero-click, requiring no interaction at all, would be inaccurate.

The initial flaws affected JavaScriptCore, the JavaScript engine in WebKit. Its JIT compiler speeds up execution by translating frequently used code into machine instructions. These optimisations must preserve type and memory-management rules. Breaking those rules allows a page to interfere with the engine's own internals. DarkSword used different initial CVEs for newer and older iOS versions. [1]

Type confusion occurs when a program treats an object as a different, incompatible type. The same bytes may then be misinterpreted as a length, an address or another internal field. This can lead to reading or modifying memory outside the permitted object. [4]

Use-after-free means accessing memory after an object has been freed. The program continues using the old reference even though that memory region may already contain other data. If an attacker can influence how the memory is reused, the flaw can provide a basis for memory corruption and code execution. In DarkSword, the variant for iOS 18.6 was associated with garbage collection and the JIT compiler. [1] [5]

Technical reports often describe the result as an exploitation primitive. For example, arbitrary read/write means the ability to read or modify memory at addresses the attacker can control. At this stage, the capability belongs to a specific execution context. Being able to modify browser-process memory does not, by itself, mean access to kernel memory or any other application's memory.

Bypassing pointer protection and escaping sandboxes

A modern system protects transitions between code locations as well as memory contents. Pointer Authentication Codes, or PAC, check the authenticity of certain pointers, including return addresses and function pointers. This makes it harder to redirect execution after memory corruption. Knowing an address and being able to write it to the desired location may not be enough: the check must accept the corresponding pointer. [6]

In DarkSword, CVE-2026-20700 in dyld, the system's dynamic library loader, was used to bypass PAC in user space. It helped turn the acquired memory capabilities into control over execution. It is not a universal switch that disables protection across the device. [1]

The chain then moved from WebContent into the GPU process through a vulnerability in ANGLE, a component that handles graphics commands. Next, a copy-on-write flaw enabled a transition from the GPU process to the mediaplaybackd system service. The final stage used a vulnerability in the XNU kernel to obtain kernel memory read and write capabilities. [2]

Copy-on-write is a mechanism in which several contexts can initially share data, with a separate copy created when changes are made. Security depends on correctly tracking permissions and memory state. A flaw in this mechanism can break the expected isolation between processes. In this chain, it was a separate transition between levels of access.

The kit included six CVEs, but the two initial vulnerabilities were alternatives for different iOS versions. Saying that six flaws were triggered sequentially on every phone would therefore be incorrect. The table shows the roles of the components and the historical patch versions from Google's technical report. [1]

These numbers explain the history of the fixes. For protection today, install the latest system version available for the specific device model. The support branch, backported fixes for older devices and subsequently discovered vulnerabilities cannot be reduced to a single number in a historical table. [17]

What happened after exploitation

After broader access had been obtained, the payload ran: code that carried out the attack operator's objective. In the published research, this included collecting messages, notes, credentials, files and data from cryptocurrency applications. Lookout characterised the operations it studied as rapid data collection and exfiltration, with minimal time spent on the device. [7]

The variant examined by iVerify used JavaScript components in the memory of system processes and had no mechanism for persistence after a reboot. But the absence of a permanently installed application does not make the consequences temporary: a secret already copied remains with the attacker. Restarting a device does not revoke a leaked private key. [2]

The term “root access” is too crude here. In iOS, sandboxes, entitlements, file protection, unlock state, hardware mechanisms and individual process restrictions all matter. Access to kernel memory significantly expands an attacker's capabilities, but does not automatically mean that every cryptographic protection has been removed. [3] [8] [9]

When a compromised phone becomes a compromised wallet

A cryptocurrency wallet manages keys and creates signatures. For an ordinary single-key account, a valid signature allows the network to verify the sender's authority. If an attacker obtains the secret key, they can sign operations on another device. The PIN of the original application does not become an additional condition for the blockchain to verify that signature.

Several situations must be distinguished when assessing the risk. The first is a leak of the seed phrase or private key itself. The second is theft of an encrypted container that still needs to be decrypted. The third is access to data that has already been decrypted while it is in use. The fourth is the ability to obtain an unwanted signature without extracting the key. These are different outcomes, and the protections against them also differ.

In iOS, Keychain stores protected items with different accessibility classes. For some, access depends on whether the device is currently unlocked; for others, on whether it has been unlocked at least once since startup. An application can also set user-authentication requirements. Copying the Keychain database and obtaining all its secrets in plaintext therefore cannot be treated as the same action. [8]

The Secure Enclave is a separate hardware subsystem designed to maintain its security properties even if the main processor's kernel is compromised. This does not mean that every installed wallet's seed exists entirely inside it. We need to establish how the specific application stores the secret, which key encrypts it, when it is decrypted and in which environment signing takes place. [9]

Consequently, a claim that an exploit instantly extracts private keys from any Trust Wallet or Tonkeeper installation requires separate evidence for the specific application versions and their state. The general risk is real, but the name of a piece of malware cannot replace an analysis of the wallet's implementation.

The separate attack surface in image processing

ImageIO and CoreGraphics process graphics data. A specially crafted file can affect decoding code before the user sees the finished image. If previews are generated automatically, processing can in principle begin without the file being opened separately. But the specific path depends on the application, format and system version; mentioning a graphics library alone is not enough to establish a zero-click scenario.

An out-of-bounds write is a write beyond an allocated memory region. For example, a program calculates a buffer size, then writes beyond it because of a validation error. This may corrupt adjacent data, cause a crash or create conditions for changing program execution. Whether code execution can be achieved depends on the flaw's properties and the available protections. [12]

Apple fixed CVE-2025-43300 in ImageIO in iOS 18.6.2, released on 20 August 2025. The company described memory corruption when processing a malicious image and reported possible exploitation in a sophisticated targeted attack. Running iOS 18.6.2 therefore does not establish exposure to this particular flaw: that version contains its fix. [10]

CVE-2026-86950 affects CoreGraphics. In its iOS 26.7.1 bulletin dated 28 September 2026, Apple stated that processing a specially crafted file could lead to arbitrary code execution; an out-of-bounds write was fixed. That bulletin does not establish which messaging application delivered the file or whether any wallet keys were extracted. [11]

A rigorous technical account stays within the confirmed transitions: file processing, a memory error and possible code execution in the affected context. A claim of access to all applications requires evidence of the rest of the chain. A claim of asset theft requires evidence of access to secrets or an authorisation mechanism.

What self-custody means in practice

This is where my preference for holding things myself becomes practical. I want to understand where my secrets live, which systems can use them and how I can recover them. Keeping custody creates the opportunity to make those decisions myself; the protection comes from how carefully I carry them out.

A self-custody wallet means that control of the keys rests with the owner rather than a service operator. But self-custody and cold storage describe different properties. A mobile wallet can be both non-custodial and hot: its secret is used in a system that constantly interacts with the outside world.

Two applications on the same smartphone do not create full independence either. They may have different seed phrases, but they still share an operating system, an update mechanism and part of the storage infrastructure. This arrangement should be understood as a shared dependency. Separating risk requires separating environments and secrets, not just application names.

A hardware wallet moves operations involving keys to a separate device. Its security properties depend on its architecture, firmware, recovery method and transaction verification. A USB connection alone does not mean that the private key is transferred to the computer: a properly designed signing module keeps the secret inside. An air gap adds physical separation of communication channels, but does not replace the device's other security properties. [14] [15]

Generating keys and preserving the secret

Security begins at generation. In BIP39, a mnemonic phrase encodes random input data and a checksum. Standard 12-word and 24-word phrases represent 128 and 256 bits of initial entropy respectively. Words you invent yourself do not provide that randomness. Phrase length does not compensate for a predictable generation method. [13]

Generation should take place on a verified device with a sound source of randomness and trusted firmware. Physical randomness, such as dice rolls, should be added only through a verified procedure for the particular solution: an arbitrary number of rolls and a homemade conversion do not automatically provide good entropy.

BIP39 supports an additional passphrase that participates in deriving the seed together with the mnemonic. It is not the device PIN. A different passphrase produces a different set of keys, and losing the required passphrase can make assets inaccessible even when the mnemonic has been preserved. Use one with a clear storage and recovery plan. [13]

For cold storage, the seed phrase must not end up in a photograph, cloud note, conversation or website form. Moving a phrase previously used in an online environment into a hardware device does not prove that earlier copies no longer exist. If compromise is suspected, safe migration requires new, independently generated keys and transferring assets to their addresses.

A backup should withstand realistic everyday risks and remain confidential. PENGER offers a physical medium for recording a seed phrase yourself, offline. Such a plate preserves a copy; it does not sign transactions or encrypt the record. Representing words as indices or a binary pattern remains encoding according to known rules. Physical access to the backup must be protected. [13] [16]

Air gaps and verifying what you sign

In an air-gapped setup, the signing device has neither a direct network connection nor a cable data connection to the online computer. Data exchange still exists. The online wallet prepares a request, which is transferred to the isolated signing module, and the signed result is returned for broadcast to the network. For Bitcoin, for example, a PSBT can be transferred on a memory card; some devices use QR codes. [14]

The secret stays with the signer

The purpose of this separation is to let the online environment observe the wallet's state and prepare operations without holding the secret key. But a QR code or file is still input that the device must parse. An air gap therefore reduces the number of direct attack paths while retaining requirements for parser security, firmware and checks on outgoing data. A device controlled by an attacker from the outset cannot be trusted simply because it is disconnected from the network.

Verifying the meaning of a signature is a separate task. An infected computer can substitute the recipient or construct a different smart-contract action. Check the address, amount, fee and material transaction parameters on the signing device's trusted screen. If it displays only unintelligible data, a claim made by the website's interface does not provide that verification. [15]

Clear signing helps present the actual data being signed in an understandable form where the device can decode it. Support depends on the particular format and contract. Protecting the key and verifying the user's intent remain separate tasks: assets can be lost by personally signing an unwanted approval, even when the secret never leaves the device. [15]

Finally, isolation must not turn a wallet into a system that cannot be recovered. Before placing significant amounts in it, safely test the backup and recovery procedure. That test should not require entering the real secret on an ordinary network-connected computer. It makes sense to separate everyday transactions from long-term storage so that a mistake in one environment does not expose the entire balance.

The strength in keeping control

For me, the main lesson from attacks like these is the need to understand what our control actually rests on. Cold storage is effective when keys are generated correctly, their copies are accounted for and protected, and they are used in an environment with clear trust boundaries. An air gap has an important role here: it helps separate secrets from devices that receive other people's code and data every day.

I call the habit of checking those boundaries healthy digital paranoia. Where did my key originate? Which devices have ever seen it? Who can access the backup? What can change a transaction before signing? Can I recover access without relying on an outside service? The answers should describe real actions and dependencies.

This approach also applies to personal documents, correspondence, passwords, work materials and anything else a person considers confidential. I see value in keeping these under our own control and knowing where every important copy lives. That includes maintaining protected backups and a recovery path. We can reduce the attack surface, separate critical secrets from everyday devices and limit the consequences of an individual failure.

Self-custody becomes informed when the owner understands the foundations of their system: who can sign an action and under what conditions, where secrets exist and how recovery remains possible. The level of protection should be one the person can actually manage. It is the combination of sound generation, storage, isolation and understanding that gives a cold wallet its practical strength.

How I hope we come out stronger

I expect the years ahead to test us. I also believe they can make us stronger if we respond by learning how our systems work and taking responsibility for what we keep in them. The strength I see in self-custody is the ability to hold our own keys, protect our own information and maintain a way to recover access. That is the kind of independence I want to build: control I understand and can sustain when something goes wrong.

Sources and further reading

1. Google — DarkSword
2. iVerify — Inside DarkSword
3. Apple — App isolation
4. MITRE — Type confusion
5. MITRE — Use after free
6. Apple — System integrity
7. Lookout — DarkSword
8. Apple — Keychain protection
9. Apple — Secure Enclave
10. Apple — iOS 18.6.2 security
11. Apple — iOS 26.7.1 security
12. MITRE — Out-of-bounds write
13. BIP39 — Mnemonic keys
14. COLDCARD — Paranoid Guide
15. Trezor — Clear signing
16. PENGER — Seed backup
17. Apple — Security releases
18. WhiteRabbitNeo — Model card
19. Anthropic — AI-assisted espionage