On 21st October 2026, patches for two critical vulnerabilities in PHP were released. This event has led to web apps across the world being taken down as patches were being rolled out. Not everyone was able to receive patches so easily though, as systems running PHP 8.1 or earlier no longer receive updates from the PHP project. Forbes called it ‘one of the biggest internet vulnerabilities ever’.
What to do next if you haven’t already:
- Today: patch PHP through your host, your distro or the source patches. If you can’t patch, mitigate through config settings (more on that here).
- This month, if you’re on CI4 or Laravel: stabilise your site, by moving to a version of PHP that has long term security support, and a CodeIgniter/Laravel framework version that has long term security support.
- This month, if you’re on CI3: stabilise by moving to a maintained fork of CodeIgniter 3 that runs on PHP 8.3+.
- Next, if you’re on CI3: plan a conversion to CI4, or port your system to Laravel, which you now have the time to do.
Your sites can be protected today, but you need a plan. Taking your systems offline until you can patch has been recommended as a last resort. That is your call to make.
This post’s purpose is to touch on recent events, and provide steps on how to patch, stabilise and plan for the future if you run a legacy CodeIgniter or Laravel application.
How widespread was this issue?
According to W3Techs, PHP runs 69.3% of websites whose server side programming language is known. Every version from PHP 5.4 up to the patched releases is affected.
Plenty of platforms have seen outages today, as PHP is used to power popular web frameworks like WordPress, Laravel, and CodeIgniter. It’s particularly bad, because PHP is the foundation of many software systems - so it’s not a bug in an app, or even in a framework - it’s a bug in the language itself. A bug in PHP is a bug in everything that uses it!
The advice from cyber-security firms has been to take down sites that are unable to apply the patches, leading to plenty of organisations and even governments to take pages offline while waiting for patches.
Why has this happened, seemingly out of the blue?
Details of the vulnerabilities were leaked online via Hacker News before the PHP security team’s scheduled public disclosure date. This caused them to post an advance notice of the upcoming security release and release patches a day earlier than planned.
What did Novatura do during this incident?
We received notice of the security release in at 07:00 BST 21/10/2026, so we were able to plan an upgrade strategy for all of our projects. We sent out a notification to customers, warning them about potential disruption.
Unfortunately, once the advisories and patches were released, there were bottlenecks and outages - suspected to have happened due to the sheer volume of developers rushing to patch. While we waited for patches to become available through our distro, we followed the mitigation guidelines and ensured all of our systems were protected behind Cloudflare WAF.
After a certain amount of time elapsed, we warned customers about our plans to shut off web traffic to our most critical applications. We waited and monitored for patch availability, and in the evening succeeded in patching every project.
What is PHP2Shell?
PHP2Shell is the name for two critical remote-code-execution flaws in PHP itself, said to be some of the most severe discovered to date with both getting rated 9.2 out of 10 by the PHP security team. They’ve been around since 2004, but they were only recently discovered by cybersecurity researchers at Calif and Wiz, using AI to discover flaws. According to Wiz, the AI that found it was hunting for a Drupal bug and found this one instead.
A hacker can exploit them by sending requests to a server running PHP, with carefully crafted payloads that enable them to crash PHP processes, expose sensitive information and even execute code. The ability to remotely execute code like this is what makes the vulnerabilities so severe, as attackers can use this to take control of entire servers.
What to do next, as soon as you can
Check your PHP version (through your server’s terminal, or by checking with your host). If you’re not sure how to do so, check with your host. They may already have information on which PHP version your application is using.
There’s some mitigation guidance, as well as details about the exploits, in the PHP’s security advisories on GitHub:
In summary, there are some PHP settings you can set to mitigate certain attack vectors. Another piece of advice is to use a Web Application Firewall (WAF), like Cloudflare WAF, which implemented new rules ahead of time to block suspected PHP2Shell payloads. These are only stopgaps, though. The only real fix is to upgrade to a supported version, which you can see here:
| Package | Branch | Patched version | Security support ends |
|---|---|---|---|
| php-src (PHP) | 8.2 | 8.2.35 | 2026-12-31 |
| php-src (PHP) | 8.3 | 8.3.36 | 2027-12-31 |
| php-src (PHP) | 8.4 | 8.4.27 | 2028-12-31 |
| php-src (PHP) | 8.5 | 8.5.12 | 2029-12-31 |
Can you patch PHP 8.1 or older?
Yes. PHP published source backports (with patches) for PHP 7.4, 8.0 and 8.1.
In some cases, you might be running a legacy software system that is on an end-of-life version of PHP. PHP 8.1 reached end-of-life in December 2025, and PHP 8.2 is coming up on end-of-life in December 2026. It’s a good idea to use a supported PHP version, because you’ll receive security updates from the official PHP project.
How to migrate to a supported PHP version if you haven’t got a technical team
We usually say to clients who come to us with outdated software supply chains: “Your house isn’t on fire now, but it’s quietly accumulating kindling.” Well today’s event is the spark that could start the fire. Since the vulnerabilities affect everyone, the risk of being exploited is so great that you need to patch now, or take things down as a last resort.
If you think you can migrate yourself, doing something is better than doing nothing. AI coding agents like Claude Code can be used to help facilitate this. Unfortunately, it’s not as simple to upgrade from PHP 8.1 to PHP 8.2. The issue lies with dependencies.
What are dependencies, and how should I upgrade them?
Most of the software components in your project have dependencies on other software components. You can think of dependencies like recipe ingredients, where your application is the finished dish.
PHP is one of the foundational ingredients (dependencies). This means that when you upgrade it, you may also need to upgrade the things that depend on it, or else they may complain or break.
Upgrading dependencies is no easy task. It helps to have someone who is familiar with maintaining software in the language of the system you’re working with.
Here’s our advice if you’re going to do it yourself:
- Make sure you’ve got good test coverage of important features before you start. These can be used to indicate that breaking changes have been introduced by upgrading a dependency - like a smoke test.
- The art of upgrading dependencies is to do things incrementally. Don’t just jump from PHP 8.1 to 8.5 - or you’ll have more places to look for reasons it broke.
- Follow upgrade guidance for your framework, or get AI to use it. Go one framework version at a time, and run your tests frequently.
For Laravel apps, if you’re on Laravel 9 or above, you should be able to continue with a migration to PHP 8.2.
For CodeIgniter apps, if you’re on CodeIgniter 4, you should be able to continue a migration to PHP 8.2.
However, since PHP 8.2 won’t get security updates from December 2026 onwards, we recommend getting to at least PHP 8.3. If you’re on Laravel, we recommend Laravel 12 as a minimum for similar reasons: Laravel 12 Upgrade Guide.
What to do if you’re on CodeIgniter 3
CodeIgniter 4 is a rewrite of the entire framework, meaning it’s a very complicated to upgrade from version 3 to 4. The framework actually recommends thinking about converting the app (starting again), which is not ideal. Read their upgrade guidance here.
For companies running CodeIgniter 3, it’s not too late to patch and stabilise your codebase.
This is your action plan:
- Today: apply the PHP patch through your host/distro, or a published source backport if you’re on an older PHP version.
- This month: stabilise your system by moving to a maintained fork of CodeIgniter 3 that runs on PHP 8.3+. You can find the fork, run by the community, here. This is to buy you time, not a long term solution.
- Next steps: plan a re-platforming to CI4 or Laravel. We recommend Laravel, as Laravel upgrades go one version at a time and are well documented, with tools like Laravel Shift providing exceptional support and guidance.
Normally, we wouldn’t recommend a community-maintained fork of a framework. Since we can’t vouch for it’s security, that’s a risk you need to assess yourself. It can be worthwhile to reduce your exposure and apply other security patches while you plan a bigger upgrade, but it’s by no means an ideal solution. Official framework versions receiving regular security updates is the gold standard to aim towards.
If you choose to keep your application unpatched or unstable, that’s a bad place to be. Especially if your system is business critical. If you’re in this situation, the best response is to act now to minimise your exposure. For vulnerabilities this severe, especially in an industry experiencing daily AI automated attacks, it’s only a matter of time until you get targeted.
At Novatura, we start with a systems audit, to see what can be salvaged. Once we know what you’ve already got, we can provide a roadmap to safety and offer priority stabilisation services. We can support with migrating PHP versions, upgrading frameworks, or even full re-platforming projects.
If you’ve got concerns about your legacy codebase, and you’d like some friendly advice, reach out to our team today and we’ll guide you through this.
What were Novatura listening to while we stayed up late waiting for patches?
A Thousand Miles by Vanessa Carlton
Listen
