PHP2Shell Turns Nearly Half of the Web into Exploitation Infrastructure

TL;DR

PHP2Shell describes two vulnerabilities in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619. Researchers at Calif and Wiz showed that crafted web requests can run commands on the server or leak secrets from its memory, with no login and before the website's own code runs. A fully updated WordPress site is still exposed if the PHP underneath it is not patched.

Researchers used AI to find these flaws and turn them into working exploits across PHP versions and applications. Attackers can use the same tools to write the exploit and find vulnerable sites to aim it at, so the whole chain, from disclosure to mass exploitation, moves faster than most organizations can patch. Cloudflare is already seeing exploitation attempts against its customers.

The exposure is enormous. PHP runs about 70% of the web, and nearly half of those sites run a PHP version that no longer gets security updates. They are the least likely to be patched, which leaves roughly a third of the web exposed for a long time without a mitigating path to protection.

Everyone assumes a hacked website means stolen data. For many attackers, the site's reputation and years of trusted history are worth more. Hacked legitimate sites are a growing channel for phishing pages, malware downloads, fake software updates and ClickFix lures, and a hacked server can also send phishing email from a domain its recipients already trust. PHP2Shell could hand attackers millions more - and from sites we all implicitly trust.

How PHP2Shell works

PHP has to recover from requests that fail. A form can exceed a memory limit. A script can hit a fatal error. A worker then has to clean up and, in many deployments, prepare to handle the next request.

PHP2Shell turns that recovery into the attack. When a request runs out of memory at the wrong moment, PHP skips the steps that would finish or erase half-built data. Cleanup, or the next request, then trusts data that is unfinished or already freed, and an attacker can steer that into running their own code.

Causing that failure doesn't take a huge upload. Calif showed that hundreds of empty file-upload fields can exhaust PHP's default 128 MB of memory in a request smaller than its default 8 MB upload limit. It all happens while PHP is still reading the request, before WordPress, Drupal or any other application code runs.

PHP also reuses the same worker process for many requests, so the damage can carry over to the next one. In one version, Wiz showed the server sending a chunk of its own memory back to the attacker in a cookie, memory that can hold secrets from other requests. Apache's mod_php and PHP-FPM handle failed requests differently, but researchers found working attacks against both.

Because the bug is in PHP rather than in the website, updating WordPress, its plugins or its theme does not help. The fix changes how PHP handles running out of memory, and it only works once it is installed, and PHP restarted, on every server that runs it.

Most of the web runs PHP, and much of it is never updated

According to W3Techs, PHP runs 69.3% of websites. Nearly half of those sites, about 48%, run a PHP version the PHP project no longer supports: PHP 7 alone accounts for 27%, PHP 5 for another 7.7%, and the retired 8.0 and 8.1 branches for most of the rest. That is about a third of the web. 

Patching PHP is much harder than updating a website. WordPress can update itself, but the PHP engine underneath belongs to whoever runs the server: a hosting provider, a Linux distribution, an agency that built the site years ago, or nobody at all. Many site owners don't know which PHP version they run. Moving an old site to a supported version can break themes and plugins written for the old one, so the upgrade keeps getting postponed.

The PHP project recognized this. For PHP2Shell it shipped exceptional source patches even for the unsupported 7.4, 8.0 and 8.1 branches. A patch still only helps once someone installs it and restarts the server. For millions of small-businesses, nonprofits, schools and local-government sites, that may take months or never happen. And being on a supported version doesn't mean being patched: plenty of those servers will lag too. A third of the web is the floor, not the ceiling.

‍

AI makes difficult exploitation easier to repeat

The research leaned on AI from start to finish. Calif began with what was known about older PHP memory bugs and used a model to find a new one, turn it into a reusable recipe, and use the recipe to find more. Wiz used models to adapt the exploits to different PHP versions, applications and memory layouts, work that would normally take a team of specialists much longer.

That is what changes the economics for attackers. Turning an advisory into an exploit that works on someone else's server used to require a specialist for each new configuration. Now AI can help with every step: understanding the patch, writing the exploit, adapting it to each target, and finding the vulnerable sites to aim it at. The whole chain, from disclosure to mass exploitation, can move faster than most organizations can patch. Defenders get the same help, but they still have to install the fix on every server, and that is the slow part.

The site's reputation is worth more than its data

Stolen data is the obvious risk of a hacked website: records, secrets, transactions. But for many attackers, it is the least valuable thing on the server.

What they want is the site's reputation: a domain with years of trusted history, a valid certificate, search rankings, links from other sites and a steady stream of visitors who trust it. Hacked legitimate sites are one of the most common ways to deliver malware, host phishing pages, push fake software updates, redirect traffic to scams and, increasingly, show ClickFix lures: fake "verify you are human" prompts that trick visitors into running a command themselves.

That reputation survives the compromise. The domain, the certificate, the bookmarks and the search results all keep working, and visitors still reach the expected server. It now serves content the attacker changed. A newly registered domain has to earn traffic and credibility. A hacked business site already has both, and every message it shows inherits some of that trust.

In May 2026, attackers exploited a SQL injection flaw in Ghost CMS (CVE-2026-26980), stole administrator keys and rewrote articles to show fake Cloudflare checks. XLab counted more than 700 poisoned sites. That is the full chain this post describes: a server-side bug turned into malware delivery to the site's visitors.

More recently, Check Point's StopAndProtect investigation found hacked WordPress sites serving fake CAPTCHAs and malware, running command-and-control and storing stolen data. The operators' own tools managed the injected content across sites, and their lists held close to 2,000 hacked domains.

A reputation like that takes years to build and can't be bought new. A mass-exploitable flaw in the engine behind most of the web is a new supply of exactly those sites.

The second attack lands on the people who trust the site

A hacked site can turn on its visitors in many ways. It can replace a login page with a phishing copy that sends credentials to the attacker, offer a fake browser or software update that installs malware, serve a download dressed up as the document the visitor expected, or quietly redirect some visitors to scams.

ClickFix is among the newest of these. A fake verification or repair prompt tells the visitor to press a few keys and paste a command into Run or a terminal, often after the page has already copied that command to the clipboard. The visitor runs it, and the operating system downloads the next stage. The attack needs no browser vulnerability.

The server can also reach people who never visit the site. With a shell, an attacker can send mail through the site's own mail setup or the SMTP credentials stored in its configuration. Those messages come from a real business domain, can pass the sender checks that mail filters rely on, and land in the inboxes of customers and partners who already trust the sender.

So one server bug becomes two attacks: the attacker takes over the website, then uses it to take over the computers and accounts of the people who visit it or read its email. Attackers are already trying PHP2Shell against servers, and the second step needs nothing new.

Businesses have two exposure surfaces

The first is the PHP they run: customer sites, online stores, webmail, admin panels and internal tools, including those hosted by a provider or bundled inside a product. A hacked server here is more than a malware host. It can serve malware to the company's own customers and partners, send them phishing email in the company's name, and give an attacker a path into the internal network.

The second is the websites their employees visit. A company can patch every server it owns and still have an employee land on a supplier's site, a local business page or a technical reference that was hacked last night.

Protection has to happen in the browser, at the moment the page asks the user to do something. That means seeing what the page is doing, analyzing its content, spotting a login form that imitates a real one, and controlling what it can put on the clipboard or download, with endpoint controls as a backstop.

What defenders should do now

Patch PHP, not just the website. Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or to your distribution's fixed build. Restart PHP and the web server, then check the version the site runs, which can differ from the command-line version.

Check for compromise. A patch does not remove an attacker who is already in. Look for unexpected changes to site content, new admin accounts or plugins, unfamiliar processes, outbound connections and mail sent from the server. Rotate secrets the server held, because PHP2Shell can leak memory without ever running a command.

Shrink what is exposed. No organization patches everything as fast as AI-assisted attackers can exploit it. Take internal PHP applications off the open internet, even the ones behind a login, and put them behind a controlled access point. Keep WAF protections on for what must stay public, and follow PHP's temporary mitigation guidance until you can patch.

Don't trust a page or an email because you know the domain. When a familiar site suddenly asks someone to sign in again, install an update or paste a command, treat it as a possible attack. Apply the same caution to email from a sender you know. Keep the page, the message and any file or command for investigation, and if anything ran, check the device and the accounts used on it.

How Island helps

Some servers will be patched quickly. Many more won't, and AI makes that gap easier to exploit. Site owners need to update PHP. Everyone else needs protection that doesn't depend on whether they did, because a site's reputation no longer tells you it is safe.

That is what Island is built for.

Judge the page, not the domain. Island's phishing and ClickFix protections look at what a page shows and what it asks the user to do. A fake login form on a ten-year-old business site, or a prompt to paste a command, gets caught even when the URL has a spotless history.

Treat PHP sites with more care. Island can use RPAs to recognize when a site runs on PHP and apply tighter policies to it. That helps mitigate the risk while nobody knows whether the site's owner has patched yet.

Leave attackers less PHP to find. Island Private Access (IPA) keeps internal applications reachable only through Island. An admin panel the internet can't see can't be scanned, fingerprinted or hit with PHP2Shell.