- The Mess: Attackers planted malicious packages on Packagist that can inject JavaScript into compromised websites and redirect visitors toward an iPhone exploit chain targeting vulnerable WebKit versions.
- The Damage: An unpatched iPhone visiting a compromised site can potentially be pushed into a multi-stage attack designed to escape browser restrictions and reach sensitive device data.
- The Fix: Remove the malicious packages, patch iPhones to the latest security release and treat affected developer environments and websites as potentially compromised.
The attack starts with PHP.
It ends with an iPhone.
That is what makes this campaign interesting.
Security researchers identified 13 malicious packages published through Packagist, the package repository used by the PHP ecosystem.
The packages were designed to infect websites and inject malicious JavaScript into pages.
The final target isn’t necessarily the web server.
It’s the person visiting it.
The Supply Chain Starts in PHP
The attackers published malicious packages that could be pulled into PHP-based projects.
Once incorporated into a website, the injected code can alter what visitors receive.
That’s the classic supply-chain trick:
developer installs package → website becomes compromised → visitor receives attacker-controlled JavaScript
The attacker doesn’t need to compromise every visitor individually.
They compromise the software used to build the website.
The Payload Targets iPhones
The researchers linked the campaign to an exploit chain targeting Apple’s WebKit browser engine.
The chain uses two known vulnerabilities:
CVE-2025-31277
and
CVE-2025-43529
These are not brand-new vulnerabilities.
That’s important.
The danger comes from combining them into an attack path that can potentially move from malicious web content toward deeper access on a vulnerable iPhone.
The campaign therefore isn’t about discovering a secret Apple zero-day.
It’s about weaponizing known flaws against devices that haven’t been patched.
The Browser Is the Initial Target
The victim doesn’t need to download an application.
They don’t necessarily need to enter a password.
They can simply visit a compromised website.
The malicious JavaScript executes inside the browser.
From there, the exploit chain attempts to break out of the normal browser security boundaries.
That’s what makes browser vulnerabilities so valuable.
The browser is one of the few pieces of software that users continuously expose to untrusted content.
Every webpage is potentially hostile.
WebKit Is a Huge Attack Surface
Apple uses WebKit across its browser ecosystem.
That makes WebKit vulnerabilities particularly interesting to attackers.
A successful exploit can potentially affect:
- Safari
- applications using WebKit
- embedded web views
- links opened from other applications
On a fully patched device, the vulnerable code is fixed.
On an old device, the browser can become the first stage of compromise.
The Attack Chain Gets Much Worse After WebKit
The reported campaign goes beyond simply stealing browser data.
Researchers observed an exploit chain designed to obtain deeper access to the device.
One stage targets WebKit memory corruption.
Another targets the underlying operating system.
The objective is to move from:
webpage
to:
browser compromise
to:
device-level access
That’s a very different threat from a phishing page.
The victim may never see a fake login form.
The browser itself is the attack surface.
Why Packagist Makes This Interesting
The malicious packages demonstrate another uncomfortable supply-chain problem.
Developers often assume that package repositories are the trusted part of the development process.
They install a dependency.
Composer downloads it.
The application gets built.
The package becomes part of production.
But the package repository is only as trustworthy as its package ecosystem.
A malicious dependency can turn an ordinary website into an attack platform.
Streaming Websites Are Particularly Useful Targets
Researchers observed the malicious packages being associated with websites offering streaming content.
That gives attackers something valuable:
traffic.
A compromised website with thousands of visitors can become an exploitation distribution point.
The attacker doesn’t need to convince each victim to install malware.
The website delivers the payload.
This is much closer to a drive-by attack than a conventional phishing campaign.
iPhone Users Don’t Get a Free Pass
Apple’s security model makes exploitation harder.
That’s precisely why chained browser exploits are valuable.
Attackers need to defeat multiple security boundaries.
A WebKit exploit may provide code execution inside the browser.
A second vulnerability can then be used to escape restrictions or obtain additional privileges.
The result is a chain rather than one magic vulnerability.
Known CVEs Still Matter
The campaign also demonstrates why patching remains one of the least glamorous and most effective security controls.
Both vulnerabilities used in the reported chain are known.
Security updates exist.
An attacker doesn’t need to invent another exploit if millions of devices remain vulnerable to an old one.
That’s the economics of exploitation.
Why develop a new zero-day when an old vulnerability still works?
Developers Have Two Problems
There are actually two separate groups that need to react.
PHP developers should inspect dependencies and remove malicious packages.
iPhone users should keep iOS fully patched.
The website owner and the visitor are connected by the same attack chain.
That’s the supply-chain problem.
A vulnerability in one ecosystem becomes a threat to another.
Check Composer Dependencies
Organizations running PHP applications should review:
composer.jsoncomposer.lock- installed packages
- package versions
- package maintainers
- unexpected dependencies
- recent changes to production builds
Don’t simply remove a package from the current deployment.
Check previous versions.
A malicious dependency may have already modified application files or build artifacts.
A Clean Build Matters
If a compromised package entered the build pipeline, rebuilding from the current source tree isn’t automatically enough.
The organization should verify:
source → dependencies → build → deployment
Each stage needs to be trusted.
Otherwise the malicious JavaScript can simply return with the next deployment.
Patch the iPhone
For end users, the advice is considerably simpler.
Install the latest available iOS security update.
Don’t postpone it because:
“I don’t click suspicious links.”
That’s not enough.
A browser exploit doesn’t necessarily care whether the link looks suspicious.
A compromised legitimate website can be enough.
The Real Lesson
This attack combines several things security teams usually treat separately:
open-source supply chain
plus:
website compromise
plus:
browser exploitation
plus:
mobile device compromise
The attacker doesn’t need to defeat all of those systems independently.
They chain them.
That’s where the danger comes from.
Bugstoday Opinion
The interesting part of this campaign isn’t that someone found malicious PHP packages.
We’ve seen that before.
It’s the destination.
A dependency installed by a web developer can ultimately become a delivery mechanism for an iPhone exploit chain.
That’s a nasty reminder that software supply chains don’t respect ecosystem boundaries.
Bugstoday verdict: if you maintain PHP applications, audit your Composer dependencies. If you use an iPhone, patch it. The attacker doesn’t care whether you think of the website and the phone as separate security problems. The exploit chain connects them for you.
Today’s Bugs. Tomorrow’s Breaches.
Sources
- Socket — Malicious Packagist Packages Research
- Packagist — Package Metadata
- Apple Security Releases
- NVD — CVE-2025-31277
- NVD — CVE-2025-43529
