A Week After PHP2Shell: This Is What I Learned

Let me tell you a story.

A week ago I read the news about two critical vulnerabilities in PHP, nicknamed PHP2Shell. I opened my terminal, checked the servers I manage, and realized several of them were still running vulnerable versions in production. This is not a theory article. This is what actually happened on my machines and what I learned from it.

What is PHP2Shell?

PHP is the programming language that powers WordPress and many other websites. PHP2Shell refers to two serious flaws (CVE-2026-109618 and CVE-2026-109619). These flaws were discovered with the help of AI tools from Wiz and researchers working with OpenAI.

Both flaws can let an attacker run their own code on a server without logging in. The bugs sit inside PHP itself, not inside WordPress, plugins, or themes. That means a fully updated WordPress site can still be exposed if the PHP version underneath is not patched.

My own audit

I checked every server I control. Most of the sites were on PHP 8.3.35 (one step behind the fixed release). One was on 8.5.11. The control panel was still on end-of-life PHP 8.1. Some CLI tools were also one patch behind.

Nothing forced me to look that day. That is how many servers end up vulnerable. Not because the owner does not care, but because routine updates feel optional until something critical appears.

What I did

I updated each branch to a fixed version:

8.5.12
8.4.27
8.3.36
8.2.35

For the end-of-life 8.1 instance I applied the vendor backport as a temporary stopgap and marked it for a real migration later. After the updates I restarted the PHP services and checked that every site was still working. The whole process took about twenty minutes.

A week later

As of late October 2026, Wordfence (one of the most widely used WordPress security plugins) reports no confirmed WordPress compromises from PHP2Shell. In their update post, they recorded roughly 77,600 related requests from more than 2,000 IP addresses. Trying is not the same as succeeding.

At the same time, other reports show that attackers are real and active. Dream described a successful chain that took over 24 firewalls. Palo Alto Networks reported active exploitation against PAN-OS management interfaces. Morphisec saw code execution on a Windows/IIS server. Exploitation is not trivial to mass-produce, but it is clearly possible.

The most important lesson

Updating WordPress is not the same as updating PHP.

Many people assume that keeping WordPress, themes, and plugins current is enough. It is not. The four fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older, especially end-of-life branches like 8.1 and below, needs attention. A WAF can help as a temporary layer, but it is not a substitute for patching PHP. If you manage WordPress sites, you may also find my guide on why your WordPress PHP settings aren’t working and how to speed up your WordPress website useful.

How to check your own server

Run this simple command:

php -v | head -n 1

If the version is older than the fixed releases listed above, you need to update. On shared hosting, open a ticket and ask your provider directly: “Has the PHP serving my site been patched for CVE-2026-109618 and CVE-2026-109619, and has PHP been restarted?”