13 Poisoned Packagist Themes Turn Websites Into iPhone Spyware Traps

• The Mess: Researchers found 13 malicious Composer themes on Packagist that inject hostile JavaScript into websites and can send visitors with unpatched iPhones into an exploit chain ending in spyware and crypto-wallet theft.
• The Damage: A website operator can unknowingly become the attacker’s delivery system, exposing visitors to stolen messages, passwords, photos, browser data and cryptocurrency wallet seeds.
• The Fix: Remove the affected packages, audit all themes from the identified vendor namespaces and update iPhones immediately.

The developer didn’t install malware.

At least, that’s probably what they thought.

They installed a theme.

The theme then injected JavaScript into every page.

Visitors arrived.

And some of those visitors — using vulnerable iPhones — could be pushed into a WebKit-to-kernel exploit chain ending with spyware.

Welcome to the latest supply-chain mess.

The Malware Was Hiding in Website Themes

Researchers at Socket identified 13 malicious Composer theme packages published on Packagist.

The packages targeted websites built around Vietnamese movie and comic streaming platforms.

The affected packages were distributed across five vendor namespaces:

vsmov

vsphim

haiau009

chilltvcms

and

ophimcms.

The important part isn’t just that malicious packages existed.

It’s what happened after a website operator installed one.

The trojanized theme injected JavaScript into pages served to visitors.

The website became the delivery mechanism.

The administrator could unknowingly infect their own users.

The Attack Has Two Different Paths

The malicious code doesn’t do exactly the same thing to everyone.

One branch handles mobile advertising fraud and gambling redirects.

The other is considerably nastier.

When the visitor matches the right iPhone and iOS conditions, the injected code can start an exploit chain designed to install spyware.

The website itself may look completely legitimate.

The visitor isn’t necessarily downloading a suspicious application.

They are simply loading a page.

That’s what makes the campaign particularly ugly.

The iPhone Version Is Checked First

The exploit chain fingerprints the visitor’s iOS version.

Then it decides whether the device is a suitable target.

The campaign analyzed by Socket targeted vulnerable iPhones running older iOS versions.

The operators weren’t trying to magically compromise every current Apple device.

They were targeting systems that hadn’t been updated.

That distinction matters.

This is exploitation.

Not theoretical vulnerability research.

The chain relied on known WebKit vulnerabilities already patched by Apple.

Two WebKit Bugs Open the Door

The campaign weaponized:

CVE-2025-31277

and

CVE-2025-43529.

These vulnerabilities were used as the browser-side entry point.

The attacker first gains the necessary control inside the browser environment.

Then the chain continues.

The goal isn’t simply to crash Safari.

It’s to move deeper into the device.

The Browser Sandbox Wasn’t the Final Destination

After the WebKit stage, the attack chain continues beyond the normal browser process.

Socket’s research describes a path that moves through the GPU process before reaching a kernel-level stage.

The final payload gains extensive access to sensitive data.

This is where the story stops being:

“malicious JavaScript on a website.”

And becomes:

“a compromised website delivering spyware through an exploit chain.”

That’s a completely different level of risk.

The Payload Wants Everything

The spyware payload was designed to collect data including:

• keychain databases
• Wi-Fi passwords
• SMS data
• contacts
• photos
• browser cookies
• browsing information
• call history
• location history
• account databases

That’s already enough for a serious privacy disaster.

Then the operators added something else.

Crypto Wallet Seeds

The newer payload includes functionality designed to search for cryptocurrency wallet material stored in the iOS keychain.

The research identified references associated with wallet applications including:

• Bitget
• BitKeep
• Bitpie
• Phantom
• Tonkeeper
• Trust Wallet
• OKX

This is where the financial motivation becomes obvious.

Stealing a password is useful.

Stealing a wallet seed phrase can be considerably worse.

A password can usually be changed.

A stolen seed phrase may give an attacker direct access to cryptocurrency holdings.

If the victim doesn’t act before the attacker moves the funds, the damage can be immediate.

The Website Operator Is Also a Victim

This is one of the most interesting parts of the campaign.

The streaming website administrator may not be the attacker.

They may have installed a theme from a package repository believing it was legitimate.

The malicious code then becomes part of the website.

Every visitor receives it.

The attack therefore creates multiple victims.

The website operator.

And:

everyone visiting the website.

That’s supply-chain compromise at the browser level.

The developer installs a dependency.

The dependency modifies the website.

The website delivers hostile code.

The visitor gets attacked.

Packagist Is Only One Step in the Chain

Developers often think about malicious packages as something that compromises the developer workstation.

For example:

npm package → malicious install script → compromised developer.

This campaign is different.

The package compromises the software being deployed.

Then the software reaches users.

The chain looks more like:

malicious package → website → visitor → browser exploit → spyware.

That gives the attacker leverage far beyond the original development environment.

One poisoned theme can potentially reach every visitor to an affected website.

The Packages Were Published Under Multiple Names

Socket identified 13 confirmed malicious packages across five namespaces.

That matters because package ecosystems can make identity difficult to interpret.

A developer may see:

a package name

a vendor name

a GitHub repository

and assume those things represent independent projects.

They don’t always.

The research found connections between the operators behind multiple packages.

The same campaign infrastructure and code appeared across different identities.

Changing the package namespace doesn’t automatically mean a new developer.

Attackers understand that developers trust names.

So they create more names.

There Is Also a Sleeper Problem

The 13 packages are the confirmed malicious set.

But Socket warned that additional packages from the same vendor namespaces should also be treated as untrusted.

Some did not contain an active payload at the time of analysis.

That doesn’t make them safe.

A package update can change what the code does later.

This is one of the most uncomfortable realities of dependency security.

The package you audit today isn’t necessarily the package you will run tomorrow.

The Malware Doesn’t Need a Fake App

Apple users are frequently told:

Don’t install unknown apps.

That’s good advice.

But this campaign demonstrates a different attack model.

The victim may never install anything.

They may simply:

1. open Safari
2. visit a website
3. run an outdated iOS version

The malicious website handles the rest.

That makes patching significantly more important.

Older Devices Become Attractive Targets

The campaign was designed around known vulnerabilities affecting older, unpatched software versions.

Attackers don’t need a new zero-day if millions of devices remain behind on updates.

Known vulnerabilities can be:

• cheaper
• easier to test
• easier to automate
• less risky for the attacker

A public patch doesn’t end exploitation.

Sometimes it starts it.

Once researchers know what Apple fixed, attackers have another opportunity to study the vulnerable code.

The users who delay updates become the target pool.

Supply-Chain Security Doesn’t End at the Server

This story should concern every developer.

A dependency isn’t safe simply because it doesn’t execute a shell command during installation.

Front-end assets are executable too.

JavaScript delivered through a package can execute inside every visitor’s browser.

That means developers need to review:

• themes
• templates
• JavaScript libraries
• browser assets
• dependency updates
• vendor namespaces

A malicious front-end package may not compromise your server.

It may compromise your users instead.

In some cases, that’s worse.

What Website Operators Should Do

Operators using affected platforms should immediately audit installed Composer packages.

Any theme from the identified malicious namespaces deserves investigation.

Remove affected packages.

Then inspect:

• theme JavaScript
• modified jQuery files
• unexpected script loaders
• hidden iframes
• obfuscated code
• external domains
• recently modified dependencies

And don’t stop there.

If the compromised website processed sensitive user information, investigate whether visitors may have been exposed to the malicious delivery chain.

Developers Should Pin and Review Dependencies

“Install latest” is convenient.

It’s also a supply-chain gamble.

Developers should:

• pin dependency versions
• review package changes
• monitor maintainer activity
• inspect low-reputation vendors
• audit new dependencies
• use dependency security scanning
• review front-end assets as executable code

A CSS theme can contain JavaScript.

A JavaScript package can contain an exploit loader.

The category name doesn’t define the risk.

The code does.

iPhone Users Need to Update

The most direct defense is simple.

Update the device.

The exploit chain described in the research targeted older versions of iOS and relied on vulnerabilities Apple had already patched.

Users running current supported releases are not exposed to the known stages described by Socket.

That doesn’t mean future attacks won’t appear.

It means this particular chain has a known defensive answer.

Patch.

The Supply Chain Has Become a Delivery Network

Attackers used to compromise websites directly.

Now they can compromise the software used to build the website.

That’s more scalable.

Instead of attacking:

one website

they poison:

one dependency

and wait for developers to distribute it.

The package repository becomes the first stage.

The website becomes the second.

The visitor becomes the final target.

Everyone trusts the previous link.

That’s why the attack works.

Bugstoday Opinion

This is supply-chain malware with a particularly nasty twist.

The developer may never be compromised.

The server may never be compromised.

The package simply turns the website into an attack platform for its visitors.

And for vulnerable iPhones, that platform can lead all the way from a normal web page to spyware and cryptocurrency theft.

Bugstoday verdict: developers need to stop thinking of themes and front-end assets as harmless decoration. If a dependency can inject JavaScript into every page, it can turn your website into someone else’s exploit delivery network. The next supply-chain breach may not steal your source code. It may use your own users as the target.

Today’s Bugs. Tomorrow’s Breaches.

Sources

• Socket Threat Research — 13 Malicious Packagist Themes
• Packagist — Composer Package Ecosystem
• Apple Security Releases
• CISA Known Exploited Vulnerabilities Catalog
• NVD — CVE-2025-31277
• NVD — CVE-2025-43529