PHP2Shell: The Internet Had a Rough Week, Here’s the Plain Version
Cliff Notes: Two serious bugs turned up in PHP, the software that quietly runs a huge slice of the web, including WordPress. They let a stranger run commands on your server without logging in. Fixes dropped October 21, 2026, a day early because the news leaked. If you run a website, your host needs to update PHP itself and restart it.
So what happened
Grab a tea, because this one moved fast.
On October 20, two CVE numbers (CVE-2026-109618 and CVE-2026-109619) started floating around forums and social media before the fix was ready. The PHP team had planned to release on October 22. Instead, they pushed it up to October 21, because sitting on a leak with a critical bug attached is a bad plan.
Even if you’ve never heard of PHP, you’ve used it. WordPress, MediaWiki, Drupal, Joomla, and a big chunk of old-school forums all run on it. Some of the bigger names reportedly took their sites offline while they scrambled. 4chan and Something Awful were two of them.
What “remote code execution” actually means
Both bugs fall under the label RCE, which stands for remote code execution. It sounds dry. It’s not.
It means someone sitting anywhere in the world can make your server run their instructions. Sometimes that’s a harmless prank. Sometimes it’s installing malware, grabbing a database full of customer info, or planting spam pages on your site that you never find until Google flags you.
The part that makes this one nasty is that no password is needed and nobody has to click anything. If your site can be loaded, it can be poked.
Here’s the human-sized version of how the two bugs work:
- Bug one: PHP runs out of memory at a bad moment and leaves its internal bookkeeping half finished. The cleanup then trips over the mess and that corrupts memory.
- Bug two: PHP finishes a request but forgets to let go of a few memory references. The next request can grab them and use them in ways it shouldn’t.
Two separate problems, one shared nickname: PHP2Shell.
How this stayed hidden for so long
This is the part I find fascinating, and a little humbling.
Back in 2024, a security audit of PHP by Quarkslab turned up early hints of the memory problem. Nobody could prove an exploit, so it sat there as a “huh, that’s weird” kind of finding.
Fast forward to 2026. A security firm called Calif started digging through PHP with help from OpenAI’s models, and on August 11 they reported working remote code execution tied to that same root cause. Wiz also found and reported both flaws independently.
Calif’s own write-up makes a point I appreciate. They said no secret model was involved. What made the difference was a human who knew PHP’s bug history, had a theory about where trouble was hiding, and used AI as a very fast assistant to test it. The AI didn’t wake up one morning and find this on its own. A person steered it.
The PHP Foundation was candid, too. Tradeoffs and limited resources slowed down the fix for the memory issue after those 2024 hints. That’s a small team protecting a massive chunk of the internet, and it shows.
The confusing first 48 hours
Once the leak hit, things got messy.
People started posting proof-of-concept exploits written by AI tools, some with bugs, some with claims that had to be corrected after the fact. Then other people fed those into AI tools to analyze them. A security researcher quoted in the video I watched summed it up as a storm of chaos and uncertainty, with humans and robots both guessing.
My advice for moments like this is simple. Don’t panic, and don’t trust the first hot take you read either. Wait for the dust to settle and lean on the official advisories.
Are attackers really using it?
Yes. Amazon’s threat team caught an exploitation attempt on a decoy server (a honeypot) on October 17, four days before the public heard anything. Cloudflare has also seen attack traffic, including attackers tweaking their payloads to slip past its filters.
Careful, though. Attempts are not the same as successful hacks. Being exposed, being probed, and being compromised are three different things. Most sites are in the first group. You just don’t want to drift into the third.
What to do if you have a website
The good news is the fix is boring, which is how I like my security fixes.
- Find out which PHP version your site runs. Check staging sites and side projects too, the ones you forgot about.
- Make sure it’s a patched release. The first fixed versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.
- Restart after updating. Installing the update while the old process keeps running changes nothing.
- Check for weirdness going back to October 17. Odd files, strange redirects, unexpected admin users.
If you’re on managed hosting, send your provider one email: “Has the PHP runtime serving my domain been patched for CVE-2026-109618 and CVE-2026-109619, and have the workers been restarted?” A real answer is a good sign. A vague one is your cue to push.
A few honest caveats:
- Updating WordPress, your theme, or plugins will not fix this. PHP is underneath all of that.
- Running PHP 8.1 or older? Those are unsupported by the PHP project, but some Linux distributions backport fixes into their own packages. A version number that looks old can still be patched. Ask your host instead of guessing.
- Behind Cloudflare? It rolled out protections to all plans, including free. That buys you time. It doesn’t replace patching.
Taking a breath
Here’s what sticks with me. This was a bug that lived in one of the most widely used pieces of software on the planet for years, and it took a human with a hunch plus some very fast tools to drag it into the light. The same tools are available to people with worse intentions, which is exactly why patching promptly matters more than it used to.
The scary part isn’t this bug. It’s wondering what else is out there that nobody has found yet. For now, patch what you can, restart what you patched, and go touch some grass.
If You Remember Nothing Else…
PHP2Shell isn’t a WordPress problem, so updating WordPress or installing another security plugin won’t fix it. The problem is in PHP itself, which means your hosting provider needs to patch it and restart the affected processes. If you’re not sure whether that’s happened, ask your host directly, and check for anything suspicious on your site going back to October 17. Cloudflare can help keep the bad guys out, but it’s not a substitute for fixing the actual problem.
Patch it, check your site, and then go touch some grass.
