PHP2Shell: Your Host Patched PHP. Your Site Might Still Be Exposed.

Your web host patched PHP. Your WordPress is up to date. Your plugins are up to date. That does not mean your site is patched.

On October 21, PHP shipped emergency fixes for two critical bugs now called PHP2Shell. I've run a crowdsourcing platform in Japan for 22 years, and on the night the fixes came out I was doing emergency work on my clients' sites. Two weeks later, a lot more is known: who actually got hit, why the version number on your dashboard can be misleading, and what to look for in your logs.

I also made a video about this.

The short version

• Two flaws, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 (CVSS v4.0). An attacker with no account may be able to run code on your server.
• Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official release.
• The first attack attempt Amazon saw was on October 17, four days before the fix.
• As of late October, mass attempts are everywhere but confirmed break-ins are few. Palo Alto Networks firewalls were rooted. Defiant knew of no WordPress site hacked this way as of October 28.
• On managed hosting, a patched PHP can keep its old version number. Check the build date too.
• A third, narrower issue (CVE-2026-115560) was disclosed on October 23. One setting covers it until the next release.

What PHP2Shell is

PHP2Shell is the name used for two separate bugs. Both are in PHP itself, not in WordPress or any plugin.

CVE	What goes wrong	Score
CVE-2026-109618	PHP runs out of memory partway through setting up a request. The cleanup code then trusts data that was only half built	9.2 (CVSS v4.0)
CVE-2026-109619	Internal state outlives the memory it points to. The next request handled by the same PHP worker can use that leftover state	9.2 (CVSS v4.0)

PHP says every installation that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where it has a demonstrated exploit that works before any of your application code runs.

watchTowr adds one detail that matters for normal sites. Session Upload Progress, which is turned on by default, is one confirmed path to CVE-2026-109619. So most default setups meet that condition.

Which versions are covered:

Branch	Affected	Fix
PHP 8.5	before 8.5.12	8.5.12
PHP 8.4	before 8.4.27	8.4.27
PHP 8.3	before 8.3.36	8.3.36
PHP 8.2	before 8.2.35	8.2.35 (support ends December 31, 2026)
PHP 7.4, 8.0, 8.1	all	No official release. A distribution or LTS vendor package, or PHP's minimal source backports
PHP 7.3 and older	all	No fix. Upgrade

Hostinger says the affected code goes back at least to PHP 5.4.

The timeline

All times UTC.

Date	What happened
October 17	Amazon's honeypots (MadPot) record the first exploitation attempt, from a commercial anonymization network. The bugs are still under embargo
October 20	Details leak before the planned release. PHP pre-announces a fix for October 21 at 14:00. watchTowr confirms the bugs are real
October 21, 02:00 to 08:00	Amazon sees proof of concept exploits and more attempts from several actors
October 21, 14:00	PHP releases the fixes, a day earlier than first planned. The UK NCSC and US CISA tell everyone to update
October 22	WP Engine finishes its rollout (01:19). Hostinger finishes on all plans except VPS (06:44)
October 23	PHP discloses a third issue, CVE-2026-115560, and calls it unlikely in practice
October 26	PHP ships rebuilt Windows packages (8.5.12-1 and so on) for a separate Brotli bug, CVE-2026-111497
October 28	Defiant: 77,000+ related requests from 2,000+ IP addresses, and no WordPress site known to be compromised
October 29	Palo Alto Networks counts over 22.6 million exposed PHP instances that may be vulnerable

Cloudflare's CEO, Matthew Prince, put the speed into numbers: thousands of attempts in the 10 hours before the announcement, tens of thousands in the 45 minutes after, hundreds of thousands within 2 hours, and then millions.

Who actually got hit

The numbers of attempts are huge. The confirmed break-ins, so far, are not.

• Palo Alto Networks: attackers chained PHP2Shell with a Linux kernel bug to get root on PAN-OS firewalls. The research firm Dream found at least 25 hacked out of a pool of hundreds. Palo Alto says about 0.02% of its installed base had the management interface open to the internet and was impacted.
• WordPress: Defiant knew of no site compromised through PHP2Shell as of October 28. It also found that exploits often need tuning for each server (ASLR, the PHP build, extensions, memory limits, request handling).
• watchTowr: it has seen successful exploitation from a single IP address in Germany. Each time it runs a simple curl command to prove it worked, and stops.
• Cato Networks: about 96% of the attacks it blocked targeted CVE-2026-109618. 41% tried to run code. The rest were scans or broken proof of concept code.

So the WordPress picture is better than the headlines. But Defiant's warning is the right one: attackers are still improving their tools, and a working attack gives them your files, your database and your passwords. One researcher, Marcus Hutchins, called it "like 50% the way towards Log4J".

How many servers are exposed

From October 21 and 22:

• Censys: of 2.58 million internet facing hosts, about 1.58 million showed a PHP version, and about 1.57 million of those were not patched. By October 22 it tracked nearly 3 million hosts running PHP.
• VulnCheck: more than 2.6 million hosts running PHP, nearly all vulnerable. At least 1 million run end of life versions: more than 700,000 on PHP 3.x to 7.3, and nearly 400,000 on 7.4, 8.0 or 8.1.
• VirusTotal: about 5.1 million IP addresses running PHP, but only 1.1 million announce a version. Of those, about 272,000 run a supported version and about 758,000 an end of life one. About 920,000 of these hosts are in the US.

That is roughly three end of life servers for every supported one. And the end of life servers are exactly the ones a host may never patch.

Myth 1: "My host patched PHP, so I'm fine"

Most hosts let you pick the PHP version your site runs. If your site is set to 8.1 or older, there is no official fix from PHP at all. Some hosts and vendors patched old branches anyway (more on that below). Many did not.

There is a second trap, and it goes the other way. On managed hosting, a patched PHP may still show the old version number.

• Hostinger: "the fix is built into the PHP version your site already runs, so the version number may not change." Its check is the build date: in the Hostinger dashboard, Websites, Dashboard, PHP Info. October 21, 2026 or later means patched.
• ActiveSet's host tracker notes that CloudLinux fixes keep old version numbers at some hosts, for example a patched 8.3 still reporting 8.3.35.
• watchTowr: the command line php can be a different version from the one PHP-FPM or Apache actually runs. Check the PHP that serves web requests, with phpinfo() or your package manager.

So "8.3.35" on your dashboard does not always mean unpatched, and "8.3.36" in your terminal does not always mean your website is patched. If you're not sure, ask your host one direct question: is the PHP that serves my site built on or after October 21?

Where the hosts stand now

The video used reports from the day of recording. Here is the later picture, from ActiveSet's tracker (last checked October 29), which quotes each host's own status page. I read Hostinger's and DigitalOcean's own posts myself. The rest are as the tracker lists them.

Host	Status	Note
WP Engine	Patched	Rollout finished October 22, 01:19 UTC
Kinsta	Patched	Patched builds for 7.4 through 8.5
SiteGround	Patched	Official fixes applied on all servers after earlier mitigations
Hostinger	Patched, except VPS	VPS customers update PHP themselves
GoDaddy	Partly	Managed WordPress, Windows and Web Hosting patched. VPS is up to you
Bluehost	Patching	Majority of platforms up to date. VPS and dedicated run package updates
HostGator	Patching	Same notice as Bluehost
DreamHost	Patched	Shared, Dedicated, VPS and DreamPress
Namecheap	Patched	Shared servers show 8.5.12, 8.4.27, 8.3.36, 8.2.35
Cloudways	Patched	Autonomous and Flexible
DigitalOcean Droplets	Your job	"Instances you already deployed don't update themselves"
AWS Lightsail and EC2	Your job	Lightsail blueprints are updated, but running instances must be rebuilt or updated

The pattern is the same everywhere: managed plans got fixed by the host, and anything where you manage the operating system did not.

Myth 2: "I updated WordPress and all my plugins"

Keep doing that. But it does not fix this. The bug is in PHP, the engine under WordPress. Hostinger says it plainly: updating WordPress, themes or plugins won't fix it. Only a patched PHP does.

Myth 3: "I changed a setting, so I'm protected"

PHP did publish workarounds. Here is the full list from its advisory, and what each one actually does.

Setting	For	PHP's own limit on it
memory_limit=-1, set where apps can't override it (for example php_admin_value in the FPM pool)	CVE-2026-109618	Removes the controllable memory limit failure, but a real allocation failure can still reach the bug
Low post_max_size: 8M without uploads, 32M with uploads, upload_max_filesize below it	CVE-2026-109618	Reduces exposure only
Request size, field count, part count, header count and nesting limits at the web server or proxy	CVE-2026-109618	Must also cover requests without a usable Content-Length
session.upload_progress.enabled=0, then restart every worker	CVE-2026-109619	Blocks the confirmed session paths, not other variants
fatal_error_backtraces=0 on PHP 8.5, then restart	CVE-2026-109619	Blocks the confirmed fatal backtrace path only

And the warnings that come with it:

• Don't rely on ini_set() or FPM .user.ini. The setting must apply before PHP parses the request: php.ini, the FPM pool or the server config.
• Hiding errors with error_reporting, display_errors or @ does not help.
• Don't use RLIMIT_AS or RLIMIT_DATA as a memory cap. They can trigger the vulnerable failure.

PHP's summary, word for word: "There are no complete mitigations, updating is the only safe choice." watchTowr goes further and says .ini changes should be understood as ineffective at preventing exploitation. Amazon suggests considering blocking multipart file uploads on servers you can't patch yet, after checking what that breaks.

The third issue: CVE-2026-115560

On October 23, PHP disclosed another session bug. It only applies if all of this is true:

• session.serialize_handler is set to php_binary or php_serialize in your config
• your code switches it to php at runtime with ini_set() before session_start()
• session upload progress is still on

PHP calls this unlikely in practice, so the fix comes in the next regular release. Until then it suggests session.upload_progress.enabled=0. If you already set that on October 21, you are covered and need to do nothing.

Today's checklist, in more detail

1. Find the PHP version your website actually runs. In WordPress: Tools, Site Health, Info, Server.

On your own server, php -v shows the command line PHP, which may not be the one serving your site. Check phpinfo() from the web, then delete that file.

2. Check that it's a fixed build. 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. On managed hosting, also check the build date (October 21, 2026 or later), because the number may not change.

3. On 8.1 or older, move to 8.3 or newer. Not 8.2. It stops getting security fixes on December 31, 2026. On Hostinger, if something breaks, you can switch back within the same login session.

4. Test the site. Home page, contact form, a test checkout. If something breaks, it's usually an old plugin or theme.

5. On a VPS, a dedicated server or a container, update and restart.

• Update PHP from your distribution. Ubuntu, Debian and Red Hat have published patched packages.
• Restart PHP-FPM, Apache and any long running PHP workers. DigitalOcean calls this "a commonly missed step."
• Marketplace images you already deployed don't update themselves.
• Restoring a snapshot or backup from before the patch brings the old PHP back. Update right after any restore.
• For containers, change the PHP version in the base image, rebuild and redeploy. A registry stores images but doesn't patch them.

Were you already hit?

Patching today stops new attacks. It doesn't undo a break-in that already happened. Amazon's advice is to start from October 17, not from the disclosure date.

Before you change anything, save your PHP and web server logs, your config and any suspicious files (watchTowr).

Then look for:

• POST requests with PHP_SESSION_UPLOAD_PROGRESS in form uploads (Amazon)
• Unusually large or deeply nested multipart requests (watchTowr)
• PHP workers that crashed or hit their memory limit (watchTowr)
• Files written to your web root, and outbound connections from PHP that you can't explain (watchTowr)
• Web shells, cron jobs you didn't create, and new accounts (watchTowr)
• Unexpected processes started by PHP (Amazon)

Amazon also published the addresses it saw. They include shared anonymization infrastructure, so Amazon says to investigate hits rather than block them.

IP address	Seen
103.216.220.92	October 17
31.223.184.166	October 21
37.19.200.5	October 21
134.209.159.64	October 21
103.114.163.188	October 21
95.217.98.37	October 21

The UK NCSC adds one point for servers you could not update in time: check them for backdoors before you upgrade, not after.

If you really can't update today

• watchTowr: restrict internet access to that server until you can.
• The UK NCSC: consider taking it offline.
• Cloudflare deployed WAF rules for the known exploit paths to all customers, including the free plan.

Treat all of these as time, not a fix. Hostinger put it well: firewall rules stop the attacks already known, but attackers keep changing their requests to slip past them.

What I take from it

Amazon's lesson from this event is the one I keep coming back to. For a critical bug on an internet facing server, measure your patch time in hours. A 7 day or 30 day plan assumes a delay that no longer exists.

And for most of us the real work isn't the patch. It's knowing every place PHP runs: the old staging site, the forgotten admin panel, the snapshot you might restore one day.

Not sure where you stand? Leave a comment on the video with your host and your PHP version. I read every one.

Sources: PHP security advisories and release notes on php.net (October 20 to 26, 2026), Amazon Threat Intelligence (AWS Security Blog), watchTowr's PHP2Shell intelligence page (last updated October 22), SecurityWeek (three reports, October 20 to 30), Help Net Security, Hostinger's protection post (updated October 23), DigitalOcean's advisory, and ActiveSet's host status tracker (last checked October 29, 2026). Host statuses other than Hostinger and DigitalOcean are as listed by the tracker and were not checked on each host's own page. Read November 2, 2026.