Opening the Page Is the Download

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:

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:

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.

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:

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.

The five are CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 and CVE-2026-11645. The last is an out-of-bounds read and write in V8.

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.

What actually protects you

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

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.

Chain stages, as reported

Reconstructed from Socket's published analysis of the Packagist campaign. Stage boundaries matter for triage: each one leaves different residue, and only the last is persistent.

The two facts a defender should take from this shape. First, stage 1 is the only stage that touches every visitor — a site serving the injector is dangerous to its whole audience even though almost nobody reaches stage 4. Second, the entry condition is a patched bug in both cases, so exposure is a function of update lag, not of user behaviour.

Exposure matrix

Triage for a device you believe was hit

This ordering differs deliberately from the reader-facing advice. The blog tells an owner to update and reboot immediately, which is right when the goal is to stop the bleeding. If the goal is to establish whether a device was compromised, a reboot destroys the evidence — several of these stages are non-persistent and exist only in volatile state.

• Decide first which you want: recovery or proof. You usually cannot have both. If funds are at risk, take recovery and accept the evidence loss.
• If proof: capture before rebooting. A sysdiagnose taken before restart preserves far more than one taken after. Repeated WebContent or GPU-process crashes around the visit time are the artefact most likely to survive.
• Treat wallet material as disclosed, not as at risk. Stage 5 targets it directly. Key rotation is not optional and cannot be undone by patching.
• Audit for additions, not access. Exfiltrated cookies are used to enrol a durable second way in — new MFA factors, recovery addresses, API keys, authorised devices. A clean login history proves nothing.
• Check the network, not just the phone. Wi-Fi passwords were in scope. A compromised handset implies exposed network credentials for every network it held.

Assessment, and what would change it

Stating confidence explicitly, because these three are not equally established and an advisory that blurs them is worth less than one that does not.

What would raise the low-confidence assessment: a published sample hash, a second independent analysis, or vendor confirmation naming the same CVEs. What would lower it: the lure resolving to an ordinary credential-phishing page with no version-gated payload — which is the null hypothesis, and is not excluded by anything we have seen ourselves.

We hold no captured sample for the free-VPS campaign. Everything in this advisory about it is second-hand, and we say so rather than let the site's standing offer to share payloads imply otherwise.

Timeline

Verifying it yourself

If you want to check the gating behaviour rather than take anyone's word for it, do it from a machine that is not the target: fetch the page's script from Linux with an iPhone user-agent and the community forum as referer, and compare it with what a desktop user-agent receives. Payload-by-user-agent gating is standard in these kits, and a desktop user-agent will very likely be served clean JavaScript.

Do not do this from a phone, and do not do it from a device holding wallet material. Cloaking cuts both ways: a scanner reporting a live phishing site as clean is the expected result, not a reassuring one.

Indicators

event.polarnode[.]vip          lure host, registered 2026-08-31
CVE-2025-31277                 WebKit, fixed iOS 18.6
CVE-2025-43529                 WebKit, fixed iOS 18.7.3 / 26.2
AppleM2ScalerCSCDriver         IOKit user client used to reach the kernel
Packagist namespaces:          vsmov, vsphim, haiau009, chilltvcms, ophimcms

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.