Opening the Page Is the Download

Status · 2 September 2026

The campaign described in the last third of this article is live as of publication. The lure domain was registered on 31 August and was distributing within hours. If you opened a "free VPS" reservation page on an iPhone in the last two days, read If you opened it before anything else.

A reader pushed back on a security note we published, and the objection was a good one — good enough that it is worth answering at length, because we think most technically competent people still hold the same belief:

Surely just loading a web page cannot compromise a phone. You would have to download and run something.

This is the most load-bearing wrong assumption in consumer mobile security, and it was correct once.

It was a reasonable rule in 2015. It is wrong now. Merely loading a web page is entirely sufficient to take over an iPhone, and as of 2026 this is no longer something only state-level budgets can reach.

Opening the page is the download

The mental model that needs replacing is the word "download". Loading a page already is downloading and executing. Your browser fetches a program written by a stranger — JavaScript — and runs it. It then parses images, fonts, video and stylesheets that the same stranger supplied, in decoders written in C++. All of it happens inside a sandbox, and the sandbox is the only thing between that page and your device.

The sandbox is not a wall. It is an assumption: that WebKit and the kernel contain no reachable exploitable bug today. WebKit is millions of lines of C++, and Apple ships fixes for WebKit flaws marked exploited in the wild several times a year.

"You have to download an .exe to get infected" is Windows-shaped thinking. On iOS you cannot run a downloaded executable at all — and that is precisely why a full Safari-to-kernel chain has historically been worth seven figures. Sideloading being unavailable does not remove the front door. It makes the browser the front door.

The precedent is ten years deep

None of this is new. Three well-documented points on the curve:

Drive-by iOS compromise, in public reporting

2016The Pegasus Trident chain compromised a fully patched iPhone from a single tap on a link in Safari. One tap, no install prompt, no credential entry.
2019Project Zero documented a set of compromised websites that infected any unpatched iPhone that visited them. No targeting, no interaction — visiting was enough.
2023Predator was delivered by hijacking a target's ordinary, unencrypted HTTP browsing traffic and injecting the chain into it. The victim browsed normally.

What changed in 2026 is not capability. It is distribution.

2026: the capability got rented out

In March, Google Threat Intelligence Group — working with iVerify and Lookout — published an analysis of a full-chain iOS exploit kit tracked as DarkSword. It reached iOS 18.4 through 18.7, chained six vulnerabilities — three of them zero-days at the time — and had been in use since at least November 2025.

Two details in that report matter more than the vulnerability count.

The first is the operator list. Activity in Turkey was connected to a Turkish surveillance vendor, another of that vendor's customers was seen using the same chain against Malaysian users in January, and a separate suspected-espionage cluster ran watering-hole attacks against Ukrainian users — planting the chain on sites the intended victims would visit on their own. One exploit chain, many unrelated hands. That is a supplier relationship, not a bespoke operation.

The second is that researchers found evidence the chain's development or customisation may have been AI-assisted. Whatever weight you give that specific finding, the direction it points is the one that matters here: the barrier to entry is falling, and capabilities that were the preserve of a handful of vendors are proliferating outward.

And then it got cheap

On 1 September, Socket published research on the down-market version of exactly that trend — and this one is not espionage at all. It is theft.

Thirteen malicious Composer theme packages were published to Packagist, under several namespaces. Vietnamese movie- and comic-streaming sites installed them with composer require, which quietly trojanised those sites' front-end assets. Every visitor to those sites then received injected JavaScript.

That script ran a fork:

Most mobile visitors were funnelled into an ad-fraud and gambling-redirect chain. Noisy, profitable, unremarkable.
Visitors on unpatched iPhones got a WebKit-to-kernel exploit chain instead, and had spyware installed.

The chain entered through two WebKit bugs and ended in kernel read/write. Note what those bugs are: N-days, not zero-days. Both were already public and already patched. The entire business model is the gap between when Apple ships a fix and when a given person installs it. This kit does not attack iPhones. It attacks iPhones that have not been updated in a while — which, on a device someone treats as an appliance, is an enormous population.

The distance between "state-grade iOS chain" and "commodity crimeware" is now measured in months.

A criminal crew monetising wallet seeds is running the same class of capability that a surveillance vendor was selling to governments six months earlier.

Which brings us to a free VPS offer

On 31 August a domain was registered. By 1 September it was distributing.

The lure is well-chosen for its audience: a cloud provider announcing a closed beta, with free VPS instances — up to three years — for the first 5,000 sign-ups. It spread through VPS, sysadmin and blockchain communities by email invitation and, more effectively, by referral links.

The referral mechanic is the part a defender should sit with. It does not merely distribute the link; it recruits the community's own established members to distribute it, wrapped in their own reputation, because they get a longer free term for doing so. The message does not arrive from a stranger. It arrives from someone whose posting history you have read for years. At least one person who had shared a referral link later posted a public retraction warning others off it.

Reported behaviour of the page:

Reported behaviour

iOS SafariOn 18.6, 18.6.1 and 18.6.2, the exploit chain fires — remote code execution, sandbox escape, kernel read/write, then data-theft spyware. No interaction with the page is required beyond opening it.

Android & desktopOnly the phishing form is shown. The exploit branch never triggers.

TargetsCrypto-wallet material — imToken and TronLink are named — plus keychain, SMS, contacts and photos.

One promotional reply reportedly stressed that the reservation link "must be opened on a phone." No genuine VPS reservation page has any reason to require that. A mobile-only exploit kit has every reason.

What we can and cannot confirm

We want to be precise about evidentiary status, because these three stories do not sit at the same level of confirmation and it would be dishonest to present them as though they did.

DarkSword and the Packagist campaign are vendor-published research. Named researchers, named CVEs, reproducible technical detail, publication under organisational accountability. Treat them as established.

The free-VPS campaign is community-sourced. That the campaign exists is well corroborated: the promotion is documented across multiple threads, the domain's registration date is checkable, and a participant publicly retracted their own referral post. That is more than enough to act on defensively.

The deep technical claims — the specific chain, the exact staging — come from an anonymous analysis without published CVE identifiers or sample hashes, produced within a day. That is achievable if the author recognised a known kit; it would be remarkable if they had reverse-engineered a novel chain overnight. The Socket research above is what makes the report credible rather than the other way round: same version band, same stolen-data inventory, same crypto motive, same architecture of fingerprint-then-load. A rented N-day kit pointed at people who have not updated in a year looks exactly like this.

Our position: credible enough to defend against, not confirmed enough to cite as fact. If that changes we will update this post in place, as we have with previous advisories.

"Zero-click" is the wrong word, and the truth is not much better

The community report is titled as a zero-click attack. That is not what this is, and the distinction is worth keeping clean because it changes what defends you.

Zero-click means no user action whatsoever — a message arrives and the device is compromised before anything is opened. This requires you to open a link. In the standard taxonomy it is a one-click, watering-hole or drive-by attack.

The reason the distinction matters is practical: against a one-click chain, link discipline genuinely protects you. Against a true zero-click chain, it does not, and only patch level and Lockdown Mode do.

But do not take too much comfort from it. "One click" here means opening a link that a person you trust sent you. There is no second prompt, no download bar, no install dialog, no permission sheet. Opening it is the entire user journey. The word is wrong; the practical difference for the victim is one tap.

Is Android safe from this?

From this chain, yes. From this class of attack, no.

This chain is built from WebKit and JavaScriptCore bugs, an iOS IOKit kernel driver, and per-build offsets for specific iPhone models. None of that exists on Android. Both campaigns confirm it behaviourally: in the Packagist case the injected script checked the platform and sent Android visitors to the ad-fraud banner, and in the free-VPS case Android and desktop visitors get only the phishing form.

This class is another matter. Chrome, V8 and Android WebView are the same kind of artefact as WebKit: enormous C++ engines parsing hostile input. Google has patched five Chrome zero-days exploited in the wild during 2026, one of which let a remote attacker run code inside the browser sandbox from nothing but a crafted HTML page. That is the same first step the iOS chains take.

Android drive-by chains are documented too, including one that combined a Chrome zero-day, an Android-only GPU sandbox bypass and a Mali GPU privilege escalation, delivered by SMS link.

Where Android actually differs

Three real differences, and they do not all point the same way.

Android vs iOS, for this threat

FragmentationHundreds of SoC, kernel and OEM combinations mean a criminal kit cannot cover "26 models" the way an iPhone kit can. The iPhone monoculture is exactly what makes an N-day iOS kit high-yield. Android kits therefore lean on GPU driver bugs — reachable from WebGL and WebGPU — as the closest thing to a universal escape.

PatchingChrome and WebView update through the Play Store independently of the OS, which is a genuine advantage over iOS. But only where Play exists. Devices without Google services depend on the OEM browser and on in-app WebView engines, whose Chromium base can lag months behind — and links from these communities are usually opened inside a chat app, not in Chrome.

EconomicsAgainst Android users this scam would not need an exploit at all. "Install our VPS client APK" works. That is the original mental model, and on Android it remains the dominant risk. On iOS the browser is the risk because sideloading is not available.

What actually protects you

For the two documented iOS campaigns, patch level is decisive, and there is a trap in the version numbers:

Patch levels that close the known stages

iOS 18 line18.7.3 or later. 18.6 closes only the first of the two WebKit bugs.

iOS 26 line26.2 or later. 26.0 and 26.1 are not sufficient — CVE-2025-43529 was fixed in 26.2. "I'm on iOS 26" is not by itself an answer.

Lockdown ModeDisables the JIT and much of the attack surface these chains enter through. If you hold significant crypto on a phone, this is the setting for you.

AndroidKeep Chrome, WebView and the security patch level current. Android 16's Advanced Protection blocks sideloading, disables the V8 JIT, enables Memory Tagging on supported chips and disables 2G — the closest equivalent to Lockdown Mode.

Beyond patching, the structural advice: do not keep wallet seed material on the device you browse links on. Both campaigns' final payloads went after the keychain and wallet apps. A hardware wallet or a dedicated device turns a total loss into an inconvenience.

And treat "open this on your phone" as an anomaly. A legitimate signup page does not care which device you use. A mobile-only exploit kit cares very much.

If you opened it

Assume compromise rather than hoping otherwise, in this order:

Move funds first. If wallet apps were installed on that device, treat the seed phrases as disclosed. Transfer assets to a wallet whose keys were generated elsewhere. Do not simply change a passcode — the seed is the account.
Then update, then reboot. Install the current iOS release. Many of these implants do not survive a reboot; updating and restarting both closes the hole and clears a non-persistent stage.
Rotate what was in the keychain. Saved passwords, Wi-Fi credentials, session cookies. Sign out of all sessions everywhere, then change passwords from a different device.
Check your accounts for additions, not just logins. New 2FA methods, new recovery addresses, new API keys, new authorised devices. Exfiltrated cookies are used to add a durable way back in.

Why there are no links in this article

Every hostile address we publish is written in defanged form and none of it is a working link. A phishing hostname rendered as a live anchor turns an article into a redirect, lends the campaign a fragment of our reputation, and asks a search engine to associate the two. Our publishing pipeline enforces this: a host that appears defanged anywhere in a post cannot carry a live link anywhere else in it.

The vendor research referenced here is easy to find by name. We would rather you arrived at it through a search you performed than a link we placed.

Reporting

If you have received one of these messages, or you operate a site you believe is serving an injected script, we read threat@uniauth.id. We do not publish reporter identities, and we strip evidential detail that would identify an affected account.

Full technical advisory

This article leaves out the decoded payload chain, the endpoint list, the infrastructure timeline and the indicators. Those are published in full in the technical advisory, written for abuse desks, registrars and CERTs: read the full advisory.