What We Did the Day PHP2Shell Hit
On October 21, 2026, PHP released emergency fixes for two flaws that let an attacker take over a web server with a single request, no login required. Attacks started before the fix was even public. By that afternoon, every site we manage had been checked, and every one that could be patched was patched or confirmed patched.
PHP runs most of the web, including every WordPress site. This post walks through how we handled the day, what we found, and what every site owner should check now.
What PHP2Shell is
PHP2Shell is the name for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. They affect PHP from version 5.4 all the way through 8.5.
- No login needed. A single crafted web request can trigger the attack before the website’s own code even runs.
- Any PHP site is a target. Attackers scan the whole internet automatically. Nobody has to pick your site out.
- Attacks came first. Exploitation attempts were seen days before the official fix was released.
The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Versions 8.1 and older get no official fix, though some hosting providers and Linux vendors backported the fix into their own builds.
How we triaged
The first question for every site was simple: is the PHP it runs patched, patchable, or neither? That sorted everything into three groups.
| Situation | What we did |
|---|---|
| Managed WordPress hosting | Confirmed the host had rolled out patched builds, including backports for older PHP versions, and verified a sample of sites directly over SSH |
| A custom application on an older PHP version | Took a full server snapshot, switched to the Linux vendor’s patched package for that version, ran the application’s compatibility checks, and tested the key workflows |
| Very old sites on PHP 5.4 | No patch exists, so the work became risk reduction and a decision for the owner |
One lesson from the checks: a patched server doesn’t always show a new version number. Several vendors fixed older PHP versions without changing the version. We confirmed each one by checking the build date and the package’s change notes, not the version string alone.
The hard case: a site that can’t be patched
The toughest situation was a set of older sites running PHP 5.4, a version that stopped receiving fixes in 2015. The hosting company confirmed no patch was coming. Upgrading PHP wasn’t a quick switch either, because code written for 5.4 usually breaks on modern PHP.
We then laid out the options for the owner, with honest trade-offs:
| Option | Keeps the site running | Protection |
|---|---|---|
| A simple notice page with contact details | No | Complete |
| A static copy of the site with no PHP | Yes, read-only | Complete |
| A security service (Cloudflare) in front of the site, with the server locked to it | Yes, fully | Strong, but not complete |
| Rewrite the old code for modern PHP | Yes | Complete, but takes weeks |
| Leave it as is | Yes | None |
We prepared the first three so any of them could be switched on within the hour, and we didn’t change anything on the owner’s infrastructure without their approval. It’s their site and their decision. Our job was to make the choice clear and make any choice quick to carry out.
Lessons for site owners
- Old software is a standing risk, not a someday risk. A site on unsupported PHP can’t be fixed when the next emergency arrives. Retiring or upgrading it before then is far cheaper than scrambling during one.
- Know who hosts your site and who can log in. In an emergency, the first hours go to finding the hosting account, the domain registrar and working passwords. Keep those somewhere you and your developer can reach.
- A security service in front of a site buys time. It’s not a substitute for patching, but it can protect a site that can’t be updated until it’s replaced.
- Take a backup before any fix. Every change we made started with a snapshot that could restore the server in minutes.
What to do now
- Find out which PHP version your site runs. In WordPress, go to Tools → Site Health → Info → Server.
- If it’s 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer, you’re patched for this flaw.
- If it’s an older 8.2 through 8.5 release, update to the latest. If it’s 7.4 through 8.1, there’s no official fix: ask your host whether they’ve applied a backported fix, and get it in writing.
- If it’s PHP 7.3 or older, plan to upgrade, replace or retire the site. There’s no fix.
- Mark December 31, 2026 on your calendar. That’s when PHP 8.2 stops receiving security fixes. Sites on 8.2 are safe from this flaw today, but they won’t be covered for the next one.
Not sure where your site stands, or what moving off an older PHP version before the deadline would take? A PHP compatibility evaluation answers both. Get in touch with Kinetic Thoughts.
Sources: PHP security advisory, October 21, 2026 · Help Net Security: PHP2Shell patched