PHP2Shell: what's happening to PHP right now, and what you need to do today

Two serious PHP bugs let attackers take over websites without a password. Here's what happened, how it was found, and what to do about it, in plain language.

October 22, 2026Betailer Team11 min read

If you run a website, there's a good chance you've seen a scary headline this week, or had your hosting company send an email with the word "critical" in it more than once.

And the first question is always the same: "Is my website safe?"

So here's the honest, no-panic version of what's going on, what it means for you, and what to do about it.

So what actually happened?

On October 21, 2026, the people who look after PHP released an emergency update to fix two serious security holes. Together they've been nicknamed PHP2Shell.

If you've never heard of PHP, that's fine. You've almost certainly used it. It's the engine under about three out of every four websites, including every WordPress site, most online shops, school portals, church websites, and a lot of the business systems we see across Ghana.

The bugs let an attacker do something they really shouldn't be able to: send a carefully crafted request to your website and end up in control of the server behind it. No password, no account, no clicking a dodgy link. Just a visit.

That's why the reaction was so loud. The US government's cybersecurity agency, the UK's NCSC and Europe's security agencies all said the same thing within hours: update now, or take the website offline until you can. You don't see that very often.

The simple version of how it works

Think of a busy chop bar. Each customer gets a plate, eats, and the plate is washed before the next person uses it.

Now imagine that sometimes, when a customer leaves in a hurry, the plate goes back on the shelf without being washed properly. The next customer gets served on it. Mostly that's just unpleasant. But if someone figured out how to make customers leave in a hurry on purpose, and what to leave on the plate, they could control what the next person gets served.

That's roughly what's happening inside PHP. When a web request ends badly, for example when it runs out of memory or crashes at exactly the wrong moment, PHP doesn't always tidy up properly. The next request picks up the mess. A skilled attacker can cause that mess deliberately and use it to run their own commands.

There are two related bugs, if you want the official names for your IT person:

CVE-2026-109618: things go wrong when a request runs out of memory
CVE-2026-109619: leftover data from one request gets reused by the next

Both are rated 9.2 out of 10 for severity.

What could an attacker actually do?

If they get in, quite a lot:

Run their own programs on your server. That might mean installing malware, sending spam, or quietly mining cryptocurrency on your hosting bill.
Read things that should be private. That includes database passwords, your Paystack or mobile money API keys, SMS gateway credentials, and customer details.
Use your good name. A hacked website is perfect for phishing because your customers already trust your domain. Imagine a fake "update your payment details" page sitting on your real website.

That last one is what worries us most for small businesses. Trust takes years to build and one bad week to lose.

Am I affected?

Honestly, if your website runs on PHP and nobody has updated it since Wednesday, probably yes.

You're very likely affected if:

Your site is built on WordPress, WooCommerce, Joomla or Drupal
You're on shared hosting with cPanel, Plesk or DirectAdmin (most cheap and mid-range hosting in Ghana is)
A developer built your system with Laravel, CodeIgniter or plain PHP
You have an old system nobody has touched in years, like a staff portal, a results checker or a booking form

Researchers think more than 5 million servers on the internet run PHP. About 758,000 of those are on versions so old they don't get fixes anymore at all.

One sneaky thing: lots of products use PHP behind the scenes without telling you, including some routers, network storage boxes and billing tools. The Dutch cybersecurity centre keeps a list of products that include PHP if you want to check.

How did anyone find this?

This part of the story is fascinating, and a little unsettling.

The first bug isn't new. People noticed something odd as far back as 2020, and PHP's own security review in 2024 spotted it again. But nobody could show it was actually dangerous, and fixing it properly risked breaking thousands of websites and plugins. PHP is looked after by a fairly small team, and without proof of real danger the fix kept getting pushed back.

Then AI entered the picture.

In August 2026, security researchers started using the newest AI models to take a much harder look at PHP. On August 11, a security firm called Calif and OpenAI separately reported that the old memory bug could be turned into a full takeover. Over the following weeks, Wiz and OpenAI found more ways in, including the second bug.

The researchers at Wiz said the attack needed "an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve." In other words, a person could maybe have done it, but AI made it practical.

And here's the bit that should make everyone sit up: the boss of another security company, Chainguard, later said his team found the same bugs in a single evening, using an AI tool and a basic prompt asking it to find bad vulnerabilities in PHP.

If the good guys can do that, so can the bad guys.

Then the secret got out early

Normally, when a bug this big is found, everyone involved keeps quiet until the fix is ready. That way, website owners and attackers find out at the same time, and owners can update straight away.

This time it didn't go to plan.

On October 17, Amazon's security team spotted someone already trying the attack on their decoy servers. That was four days before anything was public.
On October 20, the bug numbers leaked online, along with a wrong severity score. PHP responded by warning everyone early and bringing the release forward by a day.
That same evening, one of the research firms accidentally posted a video of the attack working.
Early on October 21, Chainguard released its fixed software about six hours before everyone else. That gave attackers a head start to study the fix and work backwards.
Around 2pm UTC on October 21, the official fix finally went out.

By the next day, Amazon reported that PHP2Shell was being "broadly exploited in the wild." Cloudflare, Patchstack and others saw the same thing. That isn't a future risk. It's happening now.

Is there a fix? When?

Yes, and it's already out. You don't need to wait for anything.

The safe versions are:

PHP 8.5.12 or newer
PHP 8.4.27 or newer
PHP 8.3.36 or newer
PHP 8.2.35 or newer

If your site is on PHP 8.1, 8.0 or 7.4, these versions are officially retired. The PHP team published a bare-minimum fix for people who build PHP themselves, and some hosting companies (cPanel included) have shipped patched builds. But really, this is your sign to move to a newer version.

If you're on anything older than that, there's no fix coming. It's time to upgrade.

What does the fix actually do? It changes how PHP cleans up after a request goes wrong, so a crashed request can't leave dangerous leftovers for the next one. Going back to our chop bar, every plate now gets washed, every time, no matter how fast the customer leaves. Simple to describe, but because it sits at the very heart of PHP, the team said it was one of the hardest fixes they've ever had to make.

One sobering number: Cisco's security team estimates that around half of vulnerable PHP servers may never get updated. They'll be forgotten sites on forgotten servers, and attackers will keep poking at them for months.

"Can't I just add a firewall?"

It helps, but it isn't enough on its own.

Cloudflare, AWS and others have added rules that block the attacks they know about, and there are a few settings that close off specific routes in. These are useful for buying a day or two while you arrange the proper update.

But PHP's own developers have been very clear that there's no complete workaround. The update is the fix. If you can't update, the official advice is to take the site offline until you can. We know that's painful for a business, but a few hours offline is much better than weeks cleaning up after a break-in.

What should you do today?

If you own the business

You don't need to understand any of the technical stuff. You just need to ask the right person the right question.

Send this to your web developer or hosting company today:

"Hi, has my website's PHP been updated for PHP2Shell? Which exact version is it running now?"

Then a few things to watch for:

Ask for the full number, like 8.3.36, not just "8.3". Many hosting dashboards only show the short version, which doesn't tell you if the fix is installed.
On shared hosting, your host does the update, not you. Ask them directly and keep their reply.
If the answer is PHP 8.1 or older, ask what it would take to upgrade. It's worth doing now, not after the next scare.
Once it's patched, change your important passwords. That means your hosting login, website admin, database, and any payment or SMS keys. If someone got in before the fix, this locks them out.

If you're the developer or the IT person

You probably know most of this already, but here's the checklist we'd work through:

Make a list of every server, container and product that includes PHP. Don't forget the old ones.
Check the version your web server actually uses, not just what php -v says in the terminal. They're often different.
After updating, restart PHP-FPM and the web server. Old processes keep running old code until you do.
Rebuild and redeploy Docker images. Pulling a new base image isn't enough if the old container is still running.
Put a firewall rule in front of anything you can't patch today, and set a reminder that it's temporary.
Look through your logs for PHP processes starting shells, running curl or wget, or creating new .php files.
If a server was exposed and unpatched, change any secrets it had access to.

What we're taking away from this

Bugs like this aren't new. What's new is the speed. Problems that sat quietly in code for years can now be found and turned into working attacks in days, because AI makes the hard parts easier. Defenders get that help, but so do attackers.

For most businesses, the lesson isn't "learn about memory corruption." It's much simpler:

Know what your website runs on. If nobody can tell you your PHP version, that's the first thing to fix.
Don't let software get old. Retired versions don't get help when the next big bug arrives, and there will be a next one.
Make sure someone is actually responsible for updates. That could be someone on your team, your host, or a partner. It just can't be nobody.

Not sure where you stand?

That's completely normal. Most business owners have no idea what version of anything their website runs on, and they shouldn't have to.

Send us a message or reach us on WhatsApp. We'll check what your site is running, help you or your host get it updated, and tell you straight if anything else needs attention. No jargon, no scare tactics.

Where we got our information

We wrote this on October 22, 2026, and things are still moving quickly. We'll update this post if anything important changes.