If you run a website or an internal tool built on PHP, this week was probably a busy one.
On 21 October 2026, PHP released fixes for two critical flaws, now called "PHP2Shell". In simple words, they let an attacker take control of a web server without logging in, and it doesn't matter how carefully your own website is built. The NSA asked organisations to patch immediately or take systems offline, CERT-In issued a critical alert in India, and some European government websites went offline as a precaution.
The reach is huge because PHP runs nearly 70% of all websites, according to W3Techs. For many teams, the fix is a few hours of work. While for others, it is a decision they have been avoiding for years.
Start With Your PHP Version
The PHP team has patched every version it still supports, and says updating is the only complete fix. Here is where each version stands:
| Branch | Fix | Security support ends | Position after this advisory |
|---|---|---|---|
| 8.5 | 8.5.12 | 31 Dec 2029 | Patch and done |
| 8.4 | 8.4.27 | 31 Dec 2028 | Patch and done |
| 8.3 | 8.3.36 | 31 Dec 2027 | Patch; plan the next upgrade within a year |
| 8.2 | 8.2.35 | 31 Dec 2026 | Patch now, but unsupported in 10 weeks |
| 7.4, 8.0, 8.1 | Basic backports only | Ended | Stopgap only; get a vendor fix, then upgrade |
| 5.4 to 7.3 | None from PHP | Ended | No fix; upgrade or isolate |
If a hosting company manages your site, ask them to confirm in writing that PHP itself was updated. Updating WordPress or your plugins won't fix this, because the flaw sits in PHP itself.
The harder case is the last two rows. There is no official update for them, and the NSA's own advice is to replace end-of-life PHP that can't be patched.
You would expect old versions to be rare. They are not. According to W3Techs data, close to half of all PHP websites run a version the PHP project no longer patches. Among WordPress sites, it is more than a third, as The Repository reported this week. When a developer on Reddit read PHP's notice about old versions, his only comment was, "This is brutal."
And when PHP 8.2 loses support at the end of December, that becomes about two in three.
One note for Indian readers. CERT-In's alert lists only the supported versions as affected. The older ones are exposed too. They just have no official fix.
Which Software Is Affected?
Because the flaw is in PHP, every application built on it is exposed if the PHP underneath is unpatched. That includes:
- Websites and online stores: WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop and OpenCart
- Learning and knowledge: Moodle and MediaWiki
- Business tools: CRMs like SuiteCRM and vTiger, helpdesks, marketing and analytics tools, file sharing like Nextcloud
- Hosting tools: phpMyAdmin, webmail and control panels
- And the biggest group of all: custom applications built on Laravel, Symfony, CodeIgniter or plain PHP
What really matters is who updates the PHP underneath.
| Where your application runs | Who fixes PHP | How exposed you are |
|---|---|---|
| Managed hosting or SaaS | Your provider | Most likely covered already; ask them to confirm |
| Self-hosted open-source apps | Your team or IT partner | The fix exists, but someone has to apply it, and an old app version may hold PHP back |
| Custom PHP applications | Only you | Nobody else will patch it, and moving to a new PHP version usually means changing code |
The last group is the one I want to talk about. Think of the loan processing system a cooperative bank built ten years ago, the policy servicing portal an insurer still runs, or the collections tool an NBFC depends on every day. These systems work, so nobody touches them. Until a week like this one.
So Why Are So Many Systems Still on Old PHP?
Fair question. I don't think it's because teams are careless. According to Zend's 2026 survey of PHP teams, about 40% still run end-of-life PHP, and the reasons are usually the same.
New PHP versions remove and change things, so old code breaks, sometimes only in production. The business rules, like interest calculations and loan eligibility checks, sit inside the code and are often undocumented. The people who wrote it may have moved on. And the system can't stop, because the business runs on it every day.
Now think about it. Every one of these reasons is valid, so the upgrade keeps moving to next quarter. Teams that did migrate say testing and refactoring took the most time. Both are slow for the same reason: nobody is fully sure what the old code does.
This Won't Be the Last One
The researchers who found these flaws used AI to do it, and the bugs had been sitting in PHP for years. In simple words, old code is getting easier to break into. Supported versions will get the next fix. Unsupported ones won't. A backport or a firewall rule can protect an old system for now, but as the WordPress plugin maker MeowApps put it, that "buys you time, not a future".
What Does a Safe Migration Need?
First, not every system needs one. Here is how I would think about each system, starting from its PHP version:
Whether you move to a newer PHP version or a different stack, the hard part is the same: understanding the system before you change it. In practice, that means three things:
- A clear map of the codebase: every module and how it connects to the rest.
- The business logic written down, so the new version can be checked against it.
- Changes that are reviewed and traceable, so the team can move fast without breaking what the business depends on.
This is what we work on at Vyazen. Our platform, Vyazen Continuum, maps what a legacy PHP system actually does, keeps its business logic intact while it changes, and runs on your own servers or cloud with the LLM you choose.
In a Nutshell
For most teams, PHP2Shell is fixed with an update. The risk sits with systems on PHP 8.1 and older, and from January, on 8.2 as well. For those, the last answer is a planned move to a supported stack, and it starts with understanding the system.
Here is what you can do this week:
- List every system that runs PHP, including internal tools and vendor products.
- Check the PHP version on each one, or ask your host to confirm it in writing.
- Update everything on 8.2 or newer, and restart PHP afterwards.
- Apply a vendor fix to anything older, or take it off the internet for now.
- Check your server logs from 17 October, when Tenable reported the first attack attempts.
If an old PHP system has come up on your list, we would like to help. Vyazen Continuum, our modernization platform, will review one of your legacy PHP applications for free and give you a short report: how exposed it is, what is likely to break when you upgrade, and a sensible way forward. Your code stays with you. Share it read-only under an NDA, or we can run the review inside your environment.
We are taking a limited number of reviews this month. Request a free legacy PHP review