On October 21, 2026 the PHP project released emergency fixes for two critical flaws – nicknamed “PHP2Shell”.
The found vulnerability allows attackers take over a web server with just a single request. Not even a login is needed.
Security researchers are calling it one of the biggest IT vulnerabilities in years.
So what exactly is PHP & what is PHP2Shell?
PHP is the programming language behind roughly 70% of websites on the internet today.
Popular CMSs such as WordPress, Drupal and Joomla all run on it.
And PHP2Shell is a pair of memory-handling bugs in PHP itself.
When PHP runs out of memory mid-request, it can leave scraps of that request behind and a later request handled by the same server process can then reuse those scraps.
Attackers can exploit this in two ways:
- Take control of the server. Researchers at found working attacks against fresh, fully updated WordPress, Drupal and Joomla installs, without any login.
- Read sensitive memory. Even without full takeover, attackers can pull out data from other visitors’ requests, including passwords, login tokens, API keys and certificates.
What does AI have to do with any of this?
The bugs had been in PHP for more than a decade, back to version 5.4.
Turning them into a working attack meant chaining several bugs together and adjusting for each server’s memory layout.
IT security experts have described this as being at the edge of what human researchers could practically do.
But researchers used AI tools, including Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol, to find the flaws and build working exploits.
With AI help, they managed to achieve in about a week what would previously have taken a world-class team months.
Their first finding was on August 19th 2026 – with working attacks against Drupal and WordPress websites following within two days.
Why does any of this matter?
It matters because realistically the same tools are available to criminals.
Memory bugs used to be a niche, specialist job – an exploit that may have worked on one server would not necessarily work for others and would need adapting (requiring great skill and expertise).
AI can now do that adaptation rapidly.
The result is that attacks can scale across thousands of different setups with ease.
Bugs once dismissed as too hard to exploit are now realistic targets for cyber criminals.
Which websites are most at risk?
Any server running unpatched PHP to serve web pages is potentially exposed.
That covers every common setup and the highest-risk sites are:
- WordPress, Drupal and Joomla sites. These were the public demonstration targets, and their huge install base makes them prime targets for automated mass scanning.
- Sites on Apache with mod_php. PHP’s own advisory flags this setup as facing the greatest danger.
- Sites on old PHP versions (8.1 and earlier, including 7.x). The PHP project no longer supports these, so there’s no standard update. Many small business sites still run them.
- Sites handling logins, payments or customer data. E-commerce stores, client portals and membership sites hold exactly the data the memory leak exposes.
Sites on large managed hosts are generally in better shape.
Many providers patched or added protections automatically on day one – and Cloudflare deployed blocking rules for all customers.
However, that’s a stopgap, not a fix.
What do you do about it?
Work through these steps in order:
- Find out which PHP version you run. Your host’s control panel, developer or your IT provider can confirm this.
- Patch immediately. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you installed PHP through your server’s package manager, apply your vendor’s updated packages instead.
- Can’t patch today? Take the site offline or shield it. IT security experts advise taking unfixable systems offline for now. At minimum, put the site behind a web application firewall such as Cloudflare. Sites on PHP 8.1 or older need an upgrade plan or a vendor backport now.
- Look for signs of compromise. Check for unfamiliar admin accounts being created, any new or modified files, unexpected plugins or unusual outbound traffic. Review your logs for odd upload requests followed by memory-limit errors or repeated “500” server errors, plus unusually large session cookies.
- Rotate credentials. Because the flaw can leak memory, assume anything the server touched may be exposed. Change admin and database passwords, API keys, payment gateway keys and email credentials, and force all users to log in again.
- If you find evidence of a breach – call in help. Restore from a clean, pre-October 17 backup (you have a recent backup to restore from don’t you? Good.) – rather than “cleaning” a compromised server. If customer data may have been exposed, take advice on your legal notification duties.
Applying the PHP update is the only complete fix – firewall rules and settings changes only buy time.
How to reduce your risk in future
The businesses that patched PHP2Shell within hours already knew what they ran, who owned it and how to update it.
These habits get you there:
- Keep an inventory. List every website, server and web app you run, its software versions and who’s responsible for it. You can’t patch what you’ve forgotten about.
- Stay on supported versions. Plan upgrades before software reaches end of life. Sites still on PHP 7.x had no standard fix this week.
- Patch on a schedule. Apply routine updates monthly – and agree in advance who can push a critical fix within 24 hours.
- Install a web application firewall. This is what protects you in the gap between vulnerability disclosure and patch.
- Keep tested, offsite backups. Backups are only useful if you’ve proven you can restore from them.
- Limit what a breach can reach. Don’t store unnecessary customer data on the web server. Use separate, least-privilege credentials for each service so one leak doesn’t unlock everything.
- Monitor and get alerts. File integrity checks, uptime monitoring and log alerts help you spot trouble in hours, not months.
- Subscribe to security advisories. Follow your host, your CMS and the PHP project, or have your IT provider do it for you.
TL;DR … you need an IT management policy
PHP2Shell won’t be the last flaw of this size.
AI is now being used to find and weaponize old bugs in days, with minimal effort.
The window between a flaw going public and attacks starting has shrunk to hours, and this time attacks began before disclosure.
In that environment, security can’t depend on someone noticing the news.
A robust IT management policy decides in advance:
- what systems you have and who owns each one
- how quickly critical updates must be applied, and who signs them off
- how backups are taken, stored and tested
- who you call, and what you do, when something goes wrong
Businesses with that policy in place spent October 21 applying a patch.
Those without it may spend the next few months finding out what was taken.
If you’re not sure which group you’re in, now is the time to find out.
Talk to your IT provider – or call RAPIDIT about an audit of your websites and servers – and make sure you have a written plan in place for the next emergency.
Because it will happen, sooner or later.