Posted on by VisualHarmony

How We Patched PHP2Shell, the Critical PHP Vulnerability, the Same Day It Dropped

On October 20, 2026, the PHP team announced an emergency security release for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. Details leaked online before the fix landed the next day, October 21. The security community quickly nicknamed them “PHP2Shell.”

Here’s what that meant, and what we did about it for every site we host.

Why This Situation Required Urgent Attention and Remediation

PHP is the language WordPress is written in. Every time someone loads a page on a WordPress site, PHP is doing the work behind the scenes. Most WordPress security issues live in a plugin or a theme. These two live in PHP itself, underneath everything.

A few things made them serious:

  • No login required. An attacker didn’t need an account on the site. A specially crafted request could be enough.
  • Remote code execution. In plain terms, a successful attack could let someone run their own code on the server.
  • Almost every version was affected, from PHP 5.4 all the way through the current 8.5 releases. Both flaws were rated 9.2 out of 10 for severity.
  • Updating WordPress doesn’t fix it. WordPress confirmed no update was needed or planned on their end. The fix has to happen on the server.

And because the details leaked before the patch was ready, attackers had a head start. Attack attempts were already being reported as the fix was released.

How seriously was this taken? Seriously enough that organizations across Europe deliberately took their own websites offline rather than risk running unpatched for even a few hours. Finland shut down its government’s public web services as a precaution. In the Netherlands, the Port of Rotterdam, the national government portal, the country’s five largest political parties and a number of hospitals pulled their public sites. Government websites in Germany, France and the Czech Republic went dark too, and the Wikimedia Foundation, which runs Wikipedia, took systems down until they could be patched. You almost never see organizations of that size choose downtime on purpose. Our sites stayed online the whole time, and I’ll explain how below.

Being on a Current PHP Version Paid Off

Over the summer, we moved every site we host to PHP 8.4, and by late September we had removed the older versions from our server entirely. At the time, it was simply good housekeeping. This week, it mattered.

The PHP team released fixes only for versions 8.2 through 8.5. Anything older, including PHP 8.1 and everything before it, is past end of life and did not get an official release. Servers still running those versions are left with stopgap settings, vendor backports, or patching PHP from source. Because all of our sites were already on a supported version, the patched release was available for us the same day.

What We Did

The patch went on the same day the fix was released, without taking any sites offline. But installing an update is only half the job, so here’s the full picture:

  • Patched and restarted. We updated PHP to the fixed release, then restarted every PHP process on the server. That second step matters: until a process restarts, it keeps running the old code from memory.
  • Patch Verified. We confirmed that every site was actually running the patched version, and that none of our server settings changed in the update.
  • Checked control panel PHP, too. Our hosting control panel and webmail run on their own copy of PHP. That copy had already been updated automatically earlier in the day.
  • Looked for signs of intrusion. Patching closes the door, but it doesn’t tell you whether anyone walked through it while it was open. We reviewed the server back to the day before the leak for the kinds of traces a successful attack leaves behind: unexpected processes, crashes, changed files, new scheduled tasks, unfamiliar outbound connections. We found none.
  • Scanned everything. A full malware scan covered every file across every hosted site, over 750,000 files.
  • Checked every WordPress site against the originals. We compared the core files and plugins of every WordPress installation against the official copies published by WordPress.org, so anything that had been altered or added would stand out.

Every check came back clean. There was no sign that anyone had tried to use these flaws against our sites.

What This Means If You Host With Us

Nothing for you to do. Your site is running the patched version of PHP, it’s been checked, and it stayed online the whole time.

If you manage your own server, a few takeaways:

  • Patch PHP, not just WordPress. Updating WordPress and your plugins does nothing for a flaw in PHP itself.
  • Restart PHP after you update. Running processes keep the old code in memory until they’re restarted.
  • Stay on a supported PHP version. When something like this happens, end-of-life versions get left behind.
  • Look for intrusion, not just the patch. If attacks started before the fix was out, “we’re patched now” doesn’t answer “were we hit before?”

Keeping a server safe isn’t one big action. It’s a lot of small, unglamorous habits that pay off on days like this one. If you have questions about your site, your hosting, or whether your server is protected, get in touch.

Sources