PHP's 9.2/10 CRITICAL Vulnerabilities: Remote Code Execution? Be Ready for 3PM

PHP has confirmed two CRITICAL security vulnerabilities, each scoring 9.2 out of 10. That's an extremely serious rating, particularly when you consider how many websites and business applications rely on PHP. What makes this announcement more concerning is that we still don't know which versions are affected, what the vulnerabilities involve or whether the reports of remote code execution are accurate.

The PHP Security Team has scheduled an official disclosure and security release for 3PM UK time today.

If you're responsible for maintaining PHP websites, applications or servers, I'd suggest using the time between now and then to get organised. There are quite a few things we can be doing already, even without knowing the technical details.

This article is going out a little later than I'd originally planned, but there's a good reason for that. We've spent the morning making sure our server documentation is accurate, checking that we have the correct credentials and access for our production, staging and local environments, reviewing client backup files and testing our automated PHP upgrade scripts in preparation for the release.

We've also contacted all of our clients to give them a heads-up, even though some of them are probably still asleep and won't see our messages until later.

I'd rather have those preparations completed before sitting down to write about what everybody else should be doing. I'll explain a little more about our approach further down.

What exactly has been found?

Yesterday evening, Tuesday 20 October 2026, the PHP Security Team announced that two CRITICAL vulnerabilities had been discovered and that a security release was being prepared.

PHP's announcement mailing list carried the warning yesterday evening, at around 8:33PM UK time. It was posted by Jakub Zelenka on behalf of the PHP Security Team, and the announcement also appeared on PHP's official website.

Here's the TL;DR of what we know right now

What's confirmed: PHP announced two CRITICAL vulnerabilities on 20 October 2026, each scoring 9.2 out of 10. An official security release is scheduled for 3PM UK time today (2PM UTC).

What we still don't know: Which PHP versions are affected, which components contain the vulnerabilities, how the exploits actually work or who discovered them.

What's being reported: Remote code execution has been mentioned in cybersecurity warnings, but PHP hasn't officially confirmed it. There's also been no confirmation from PHP that attackers are actively exploiting these vulnerabilities.

One thing that caught my attention was PHP's statement that it may release the fixes earlier if the vulnerability details become public or if evidence of active exploitation appears.

I find that a little worrying, although I want to be careful about what it actually means. PHP hasn't said that attackers are currently exploiting these vulnerabilities, and the possibility of bringing forward a release is a sensible precaution for a security team to take.

My concern is what happens if an attacker does manage to exploit a server before its owner knows there's a problem. From experience, attackers aren't always interested in doing something immediately obvious. They can attempt to establish persistence by modifying application files, creating additional credentials or installing backdoors that allow them to regain access later.

If that happens, installing a security patch may close the original vulnerability, but it won't necessarily remove whatever the attacker has already installed.

Again, there is no official confirmation from PHP that this is happening with these particular vulnerabilities. It's simply one of the reasons I take announcements like this seriously.

You can read the announcement yourself on the official PHP website or through the PHP Foundation's announcement forum.

One thing worth mentioning is that PHP's original mailing-list archive at news-web.php.net is currently returning a 502 Bad Gateway error. It's an official PHP archive, but its web interface wasn't working when I checked. The PHP website and PHP Foundation forum are accessible alternatives.

As for who found these vulnerabilities, we simply don't know yet. We don't know whether it was an independent security researcher, a company or somebody working on PHP itself, and we don't know how long they've known about the issues. They could have been reported privately some time ago, giving PHP's developers an opportunity to work on a fix before telling everybody else.

Until somebody publishes that information, I'm not going to guess.

What does a score of 9.2 out of 10 actually mean?

The rating comes from the Common Vulnerability Scoring System, usually shortened to CVSS. It's an industry standard that helps organisations understand how serious a security vulnerability could be.

The scale runs from 0 to 10, with the highest scores reserved for vulnerabilities that have the potential to cause substantial damage.

The rating considers several factors, including whether an attacker can exploit the issue remotely, how difficult exploitation might be, whether authentication is required and what the consequences could be for the affected system.

At 9.2, both vulnerabilities sit firmly in the CRITICAL category, which is why I'd recommend treating this as an urgent maintenance and security issue.

However, I want to make something clear. A score of 9.2 doesn't mean there's a 92% chance of your website being hacked, and it certainly doesn't mean every PHP installation is vulnerable.

It also doesn't automatically mean remote code execution is possible.

From what I've been able to establish, the RCE claims appear to originate from leaks and information circulating on social media. Those claims have subsequently been repeated in cybersecurity warnings, but I haven't found confirmation of the technical mechanism from the PHP Security Team itself.

Until those details are published, we shouldn't be presenting RCE as a confirmed fact.

European Union warning about PHP

The European Union's cybersecurity service, CERT-EU, has published its own security advisory covering these vulnerabilities.

If you're wondering what CERT-EU has to do with PHP, it's an official EU public-sector cybersecurity body responsible for helping protect European Union institutions, agencies and their systems. It's broadly comparable to the UK's National Cyber Security Centre, although the two organisations have different responsibilities.

CERT-EU monitors cybersecurity threats, investigates incidents and provides guidance to organisations that may be affected.

Read the warning here: CERT-EU: Security Advisory 2026-018

CERT-EU recommends identifying PHP applications, preparing to deploy patches and considering temporary isolation for publicly accessible systems that cannot be updated promptly.

It also mentions possible remote code execution and reports suggesting that PHP versions as far back as PHP 5 could be affected.

Remote code execution. How bad could this be?

Remote code execution, commonly referred to as RCE, means an attacker may be able to make a vulnerable system execute code or commands remotely. Depending on the vulnerability, they might not even need a username and password to do it.

Now imagine somebody discovering a way to execute commands on a production server containing your website, customer database and application files.

If the compromised process has sufficient permissions, an attacker could potentially download sensitive customer information, modify your application's source code or install malware. They might change your website to steal credentials from visitors, encrypt accessible files and demand payment in Bitcoin, or even delete the application and its databases entirely.

Another possibility is that they establish a backdoor, giving themselves another way into the server after the original vulnerability has been patched. They might also attempt to use the server as part of a botnet or move into other systems connected to the same network.

The consequences could extend well beyond the website itself, particularly if the application has access to databases, other internal services or credentials stored on the server.

Of course, this doesn't mean a successful RCE automatically provides unrestricted root access. The damage an attacker can cause depends heavily on the permissions of the compromised process, the server configuration and how effectively the application has been isolated from other systems.

But even with those limitations, I think you can appreciate why remote code execution is something administrators take extremely seriously.

And to repeat, PHP has not yet confirmed that either of today's vulnerabilities allows RCE. We also don't know whether they require authentication, specific PHP extensions or particular server configurations. Those are some of the questions I'm hoping will be answered at 3PM.

Why Git is brilliant

There's another point worth making here, particularly if somebody has managed to modify your application's code.

If you've been using Git properly, with your source code stored in a trusted repository, you have a significant advantage when it comes to recovering from a compromised server.

For example, suppose somebody manages to get into your production server and starts modifying PHP files, inserting malicious code or creating additional files that shouldn't be there.

If you have a trustworthy copy of your application in Git, you can compare the deployed code against the expected version, identify unexpected changes and potentially redeploy a known-good release.

More importantly, if the server itself can no longer be trusted, you can rebuild the operating system using a clean installation or a verified restore point, install the patched software and redeploy your application from a trusted Git commit.

I wouldn't trust a compromised server simply because somebody has deleted a few suspicious files.

Rebuilding from a known-good state is often the safer approach, provided you've preserved any evidence needed for an investigation. You also need to make sure the restore point or Git repository hasn't itself been compromised, otherwise you could simply reintroduce the problem.

At this point, the more difficult part is usually your data.

Code stored in Git is relatively straightforward to restore because you know what should be there. A live database is another matter entirely, particularly for an e-commerce website that's constantly processing orders, payments, customer accounts and other transactions. You can't necessarily restore yesterday's database without losing legitimate information created since then.

You also need to make sure the data itself hasn't been manipulated. Malicious content could be sitting in database records, uploaded files or other storage, ready to cause problems when the application starts using it again.

And don't forget that credentials, API keys and sessions may need to be revoked or replaced if they've been exposed.

Recovering clean application code is one thing. Recovering accurate, uncompromised live data can be considerably harder.

That's probably a separate article in itself, but it's another reason I strongly recommend version control, proper backups and having a tested recovery process.

What should we be doing immediately?

Without knowing exactly where the vulnerabilities are, we can't confidently apply a specific configuration change and claim we're protected.

What we can do is prepare our infrastructure, reduce unnecessary exposure and make sure we're in a position to respond quickly when PHP releases the fixes.

Here's how I'd approach it.

1. Load up a spreadsheet and find EVERY PHP system you have

I'd start by opening a spreadsheet and recording every PHP application and server you're responsible for.

I'm not just talking about the company website. Think about customer portals, internal dashboards, APIs, background processes, staging environments, development servers, forgotten subdomains and older applications that may have been running quietly for years.

It doesn't need to be particularly sophisticated. The important thing is having the information in one place so you can work through the affected systems when PHP releases the technical details.

Here's the sort of information I'd record, although I'd encourage you to include anything else that's relevant to your own infrastructure.

Don't forget that systems can be configured quite differently. You might have Apache running PHP through a module, Nginx using PHP-FPM, LiteSpeed, FrankenPHP or PHP running inside containers.

The important thing is identifying the PHP runtime actually executing your application, rather than simply recording which web server you're using.

For checking, you can use:

php -v
php -i
php --ini

There's a catch here, though. These commands normally report information about the command-line PHP installation, which might be completely different from the version serving your website. For example, it's entirely possible to have PHP 8.5 installed for command-line tasks while Nginx continues serving an application through PHP-FPM 8.1. So be careful here.

Check the relevant PHP-FPM configuration, Apache module, hosting settings or container image to establish which runtime the website is actually using. If you need to use phpinfo() through a web request, make sure it's only accessible through a restricted diagnostic endpoint and remove it afterwards. You don't want to expose your server configuration to the entire internet.

Once you've completed your inventory, that spreadsheet becomes your action sheet for the afternoon. When PHP publishes the affected versions, you'll already know which servers need your attention.

2. Back up everything, and make sure those backups actually work

Before touching any PHP installation, I'd want to know that I could restore the application if something went wrong.

That means backing up your application files, databases, uploaded content, environment configuration and anything else required to rebuild the service. If you're using containers, include the relevant deployment definitions and persistent data.

Store your backups in multiple locations, not just on the same server as the application.

Ideally, I'd want at least one copy kept separately from the production environment, with another protected against modification or deletion. Depending on the infrastructure, that might mean encrypted off-site storage, an immutable backup or an offline copy. Make sure you verify them.

I don't mean looking in a folder and seeing that yesterday's backup file exists. I mean checking that the backup contains the data you expect and that you can actually restore it.

I've come across situations where an organisation believed everything was being backed up, only to discover that the backup process had been failing or the resulting files were unusable. You really don't want to discover that during a security incident.

One other thing I'd check is whether you have a clean operating-system image or a known-good restore point available. If a server has been compromised, being able to rebuild it properly is considerably better than having to repair an installation you no longer trust.

Just remember that backups and restore points aren't automatically clean simply because they exist. If an attacker has already been inside a system, you'll need to establish which recovery point can actually be trusted.

3. Lock down unnecessary administrative access

While we don't yet know how these vulnerabilities work, reviewing who and what can access your infrastructure is still worthwhile.

I'd start with anything that provides privileged access, including server management interfaces, internal application dashboards, database administration tools, development environments and deployment systems.

If something should only be available to employees or administrators, consider restricting access through a VPN, an authenticated access gateway or appropriate firewall rules. IP allow-lists can also be useful in environments where access comes from predictable locations.

Make sure multifactor authentication is enabled where supported, and check whether applications and services are running with privileges they don't actually need.

I'm not suggesting that restricting an administrative page will fix these PHP vulnerabilities. We don't know whether an attacker would need access to such a page in the first place.

The point is to reduce unnecessary exposure while we wait for the actual details.

4. Shut down anything that doesn't need to be online

Most organisations accumulate systems that were never really intended to remain online indefinitely.

You might have an old staging environment that hasn't been used for months, a development server that was only supposed to be temporary or a demonstration website running a PHP version nobody has updated in years.

If those systems don't need to be accessible, I'd seriously consider shutting them down or restricting access until you've established whether they're affected.

For systems that are critical to the business, you obviously need to weigh the consequences of downtime against the potential security risk. But for non-essential services, I see little benefit in keeping them publicly exposed just because nobody has got around to switching them off.

5. Make sure your logging and monitoring are working

If you don't already have meaningful monitoring in place, now would be a good time to address that.

At a minimum, I'd want access to web server logs, PHP error logs, application errors, authentication activity and basic server resource monitoring. That should give you some visibility into unexpected errors, unusual requests and changes in system behaviour.

It's equally important to consider what you're recording. You don't want log files full of passwords, access tokens, session cookies or unnecessary personal information.

Make sure sensitive values are redacted where appropriate and that access to the logs themselves is restricted.

If your infrastructure supports it, I'd recommend forwarding important logs to a separate server or centralised logging service. If somebody compromises an application server and attempts to remove the evidence, having copies stored elsewhere could make a significant difference to an investigation.

We don't know what exploitation of these particular vulnerabilities would look like, but having a reliable record of what happened on your servers is going to be considerably more useful than trying to piece things together afterwards.

6. Inform your clients and organisation

I'd also start informing the people who are responsible for, or depend upon, the affected systems. That includes your technical team, relevant managers, clients and whoever makes decisions about production maintenance.

You don't need to frighten anybody or claim that their website is about to be hacked. Simply explain that PHP has announced two CRITICAL vulnerabilities, the technical information isn't yet available and a security release is scheduled for 3PM.

Let them know you're identifying systems and preparing to apply the relevant fixes once they're available.

After the technical details become public, it's entirely possible that automated scanners will start looking for vulnerable servers very quickly. We don't have evidence of a specific timeline for these vulnerabilities, but experience tells us that publicly disclosed security issues can attract attention rapidly.

I'd much rather have my clients informed and my systems documented beforehand than start explaining everything while attempting to patch production servers.

7. This is where your team will really be tested

There's something else I'd strongly recommend checking, and it comes from dealing with servers and operational problems over the years.

When an urgent issue happens, people tend to rush straight for the systems they need to work on. That's often when somebody discovers that their credentials have expired, their SSH key isn't available on the machine they're using or their hosting account has been locked because nobody has logged into it for months.

Suddenly, what should have been a relatively straightforward update becomes a lengthy exercise in recovering access.

Make sure the people responsible for maintaining your servers can actually access them.

Check your SSH connections, credentials, administrative permissions and deployment tools. On Linux servers, confirm that authorised administrators can use sudo or whatever privileged-access mechanism your organisation requires.

I'd also want to know what happens if administrative access is lost entirely. Can the server be recovered through the hosting provider's console? Do you have a documented emergency-access procedure? Has anybody tested it recently?

This isn't an excuse to start sharing root passwords or weakening access controls. Quite the opposite. You want to know that your existing security and recovery arrangements work before you need them.

While you're checking access, make sure your deployment scripts, testing environments and rollback procedures are ready too.

There's no sense discovering at 3:15PM that the person with access to your production servers is on holiday and nobody else can deploy the update.

8. Prepare your update process

Finally, I'd get everything ready for the actual PHP releases.

If you manage your own servers, make sure your package repositories are configured correctly and that you understand how PHP is installed and updated.

If you're using containers, identify which images need updating and how those applications will be rebuilt and redeployed. For managed hosting, find out whether the provider will apply the security updates automatically or whether you need to take action yourself.

Have your deployment automation, backups, tests and rollback arrangements ready so you're not trying to organise everything after the announcement.

I wouldn't recommend downloading unofficial binaries or patches claiming to fix vulnerabilities whose technical details haven't been released.

The sensible approach is to prepare now, then obtain the verified security fixes from PHP or your trusted operating-system, container or hosting provider once they're available.

Does this affect WordPress, Laravel and other PHP applications?

Potentially, yes, although I wouldn't assume every PHP application is vulnerable until we know which versions and components are affected.

PHP is used by WordPress, WooCommerce, Laravel, Symfony, Drupal, Joomla, Magento, Moodle and countless custom-built websites, APIs and business systems.

If the vulnerability exists in the PHP runtime itself, an application running on that affected runtime could potentially be exposed even when the application's own code is properly maintained.

That's why updating WordPress, Laravel or another framework won't necessarily fix a vulnerability in PHP itself.

You need to establish which PHP version is actually running the application and, just as importantly, who is responsible for maintaining it. On a managed platform, the hosting provider may be responsible for the runtime, while on a VPS or dedicated server that responsibility may sit entirely with your own team.

If you're uncertain, now would be a good time to ask.

The other problem: PHP end-of-life. HELP!

There's another issue I want to discuss because today's announcement has highlighted a problem that already exists across plenty of PHP installations.

Some organisations are still running versions of PHP that haven't received official security updates for years.

PHP follows a rolling support schedule. Each release branch generally receives two years of active maintenance followed by two years of security-only updates for critical issues. Once that period ends, the PHP project stops issuing official fixes for the branch.

Here's the current support position as of today, 21 October 2026.

Source: Official PHP support schedule

That means PHP 8.2 is the oldest PHP branch still supported by the PHP project, and its security support ends in just over two months.

If you're still using PHP 8.1 or older without some form of verified extended security maintenance, you really should be planning an upgrade.

Personally, if I were upgrading an application today, I'd aim for PHP 8.5 wherever compatibility allows. PHP 8.4 is also a sensible option, particularly when particular frameworks or dependencies haven't yet been validated against 8.5.

I wouldn't choose PHP 8.2 as a long-term target unless the application couldn't reasonably move any further at the moment.

And remember, moving to the PHP 8.5 branch doesn't automatically protect you against vulnerabilities affecting that branch. You still need to install the relevant patch releases.

PHP 8.1 already has known security issues

This is where running an unsupported PHP version becomes a very real concern rather than simply a question of keeping your software modern.

PHP 8.1 received its final official upstream release in December 2025. Since then, additional vulnerabilities have been discovered and fixed in supported versions, without corresponding official PHP 8.1 releases.

Here are just two examples from 2026.

You don't need to spend your morning reading through these advisories. I've included them to demonstrate that vulnerabilities have continued to be discovered and patched in supported PHP versions while the unsupported PHP 8.1 branch receives no further official releases.

Not every vulnerability will apply to every installation. Some require particular extensions, configurations or application behaviour, but that doesn't change the underlying problem.

If your organisation is still running an unsupported PHP version without extended security maintenance, you may already be exposed to known vulnerabilities that the PHP project will never patch for that branch.

Now, I appreciate that today's two CRITICAL vulnerabilities are what everybody is concerned about, so I won't spend too much longer discussing older security issues.

But you REALLY need to look at upgrading your PHP version, and quite possibly the application code behind it.

There are tools available to make this process easier, including automated code analysis and refactoring tools. I'll come back to those shortly, because upgrading an old application doesn't necessarily mean rewriting everything by hand.

Will PHP 8.1 receive fixes for the new vulnerabilities?

I wouldn't expect an official PHP 8.1 release, because support for that branch has already ended.

What may happen is that maintainers of older PHP packages backport the fixes from supported versions, assuming the vulnerabilities affect the older branches and the fixes can be applied.

For anyone unfamiliar with backporting, it means taking a security fix developed for a newer version and adapting it to work with an older version, without necessarily upgrading the entire PHP runtime.

There are already maintainers doing this work. For example, Remi Collet has a PHP security backports repository, including a PHP 8.1 security-backport changelog.

Some Linux distributions and commercial extended-support providers also maintain security fixes for older PHP versions.

However, that doesn't mean every PHP 8.1 server is receiving them. You need to establish where your PHP packages come from, whether the maintainer is still supporting them and exactly which fixes have been applied.

If somebody tells me an unsupported PHP version is safe because it's been backported, I'd want evidence from the package provider showing which vulnerabilities they've addressed.

Hopefully today's technical disclosure will also help maintainers of older branches assess whether backports are required, but I wouldn't assume every unsupported PHP version will receive a fix.

Personally, I'd rather keep PHP on a branch that's officially supported by the PHP project. If you're running an unsupported version and relying on backports, I'd want to know exactly who's maintaining those patches and which vulnerabilities they've fixed.

What if upgrading PHP breaks your website?

This is something I have quite a bit of experience with, having worked on projects still running PHP 5.4 and other long-unsupported versions.

It wasn't necessarily because the people responsible for those systems didn't understand that newer PHP versions existed. The problem was usually that the applications had been developed over many years, had accumulated large amounts of spaghetti code and relied on libraries or functionality that nobody particularly wanted to touch.

The business depended on the software working, while upgrading it carried a risk of breaking important functionality. As a result, the work kept getting postponed.

PHP 5.4 reached end of life back in September 2015, which means it's now been more than eleven years since upstream security support ended.

Trying to move an application like that directly to PHP 8.5 isn't something I'd recommend doing blindly on a production server.

There have been numerous changes between those versions, and some of them will immediately break applications that still rely on the old behaviour.

Three PHP changes that can break legacy applications

These are just three examples. There are many more changes involving type handling, error behaviour, deprecated functionality, frameworks and third-party dependencies.

PHP provides detailed migration guidance for PHP 7 and PHP 8, which I'd strongly recommend consulting when working with older applications.

Depending on the size and condition of the codebase, modernising a legacy PHP application could involve substantial refactoring, dependency upgrades and regression testing.

I understand why organisations are reluctant to spend money on something they believe is already working. The difficulty is that an application can continue working perfectly well from a user's perspective while the technology underneath it becomes increasingly difficult to maintain and secure.

Eventually, the cost of avoiding the upgrade can exceed the cost of doing it properly.

There are tools that can help you upgrade your code

One tool I'd particularly recommend looking at is Rector.

Rector is an automated PHP refactoring tool that can analyse existing source code and apply transformations to help modernise it. It supports a wide range of PHP versions, including older codebases originally written for PHP 5.x.

For example, rather than manually searching through thousands of lines of PHP to find certain outdated language constructs (which I've done in the past, trust me it's hard), Rector can identify and automatically update many supported patterns.

You can configure which transformations it performs, review the changes and test the results before applying them to production.

It won't magically convert every PHP 5.4 application into a perfectly functioning PHP 8.5 application. There are limitations, particularly with old libraries, complex business logic and spaghetti code that nobody fully understands. You'll still need developers who understand the application, and you'll still need proper testing.

It's also worth remembering that Rector itself needs a newer PHP environment to run, even when it's analysing much older code. That can be handled through a separate development environment or container rather than attempting to install everything on your legacy production server. But the point is that you don't necessarily need to make every compatibility change manually.

Tools like Rector, PHPStan and automated tests can make a large migration considerably more manageable.

If you've been putting off upgrading because the codebase is too large or complicated, I'd seriously recommend investigating what's available before assuming the only option is a complete rewrite.

What if you genuinely cannot upgrade to PHP 8.2 or newer?

I don't think it's particularly helpful to tell somebody responsible for a business-critical PHP 5.4 application to simply upgrade everything immediately.

If that application has thousands of lines of old code, little or no automated testing and dependencies that no longer exist, it's probably going to need a proper migration project.

In the meantime, the question becomes how to reduce the risk while keeping the business operating.

First, I'd look at whether the application actually needs to be accessible from the public internet. If it's an internal business system used by a small number of employees, there may be no good reason for it to accept connections from anywhere in the world. Putting it behind a VPN or appropriately configured private-access service can substantially reduce its exposure.

For applications that genuinely must remain public, I'd review which functionality is essential and whether unnecessary endpoints or services can be disabled. It's also worth checking that the application has the minimum permissions it needs, both on the server and when accessing its database.

Next, I'd investigate extended security support. Some operating-system vendors, hosting companies and commercial providers offer security-maintained builds for older PHP versions. That may be a practical temporary solution, provided you can verify what vulnerabilities are being patched and how long the arrangement will continue.

I'd also consider isolating the legacy application from the rest of the infrastructure. If the application is compromised, you don't want it to have unrestricted access to your other production servers, databases or backups. Network restrictions, limited service permissions and controlled outbound connectivity can all help reduce the potential damage.

None of these measures guarantees protection from a PHP vulnerability, but they can reduce the attack surface and limit the consequences of a compromise.

If the official disclosure confirms that a particular legacy installation is vulnerable to a serious remotely exploitable flaw and no effective patch is available, then temporary isolation or shutdown may be the appropriate decision.

For a public information website, it might even be possible to replace the dynamic application temporarily with a static version that doesn't execute PHP at all.

Obviously, that's going to depend on the application and what the business needs it to do.

Most importantly, I'd establish a proper migration plan. Set up a separate environment on a supported PHP version, identify the incompatible functionality, review the dependencies and begin testing the application against the new runtime.

You don't necessarily have to rewrite everything at once. In some projects, breaking the work into manageable components is a much more realistic approach.

I'd also look at introducing Git if the application isn't already under version control. Having a documented history of your code and being able to review or roll back changes is invaluable during development and recovery.

The important thing is making progress rather than allowing a temporary workaround to become another ten years of technical debt.

Did AI discover these vulnerabilities?

I was discussing this with a few fellow engineers this morning. It certainly feels as though we're seeing more vulnerability reports, automated research and security-related videos appearing than ever before. Whether that's because more vulnerabilities are actually being discovered, or because we're simply hearing about more of them, is another question.

The answer, at the moment, is that we simply don't know. PHP hasn't publicly identified the researchers or organisations responsible for discovering these vulnerabilities, and there's been no official statement suggesting AI was involved.

Would I be surprised if AI-assisted tooling played some part? Not particularly.

AI tools are increasingly being used to analyse source code, identify unusual patterns, assist with fuzzing and help researchers investigate potentially vulnerable functionality.

For anyone unfamiliar with fuzzing, it's a technique where software is automatically fed large numbers of unexpected, malformed or unusual inputs to see whether it crashes or behaves in ways it shouldn't. Those failures can sometimes lead researchers to security vulnerabilities. It's a little like automated testing, except instead of checking whether the software does what we expect, we're deliberately throwing unusual and unexpected inputs at it to see what breaks.

What's interesting to me is that code which has existed for years can now be examined using newer tools and approaches that weren't necessarily available when it was originally developed.

Of course, security researchers have been using fuzzers, static analysis and other automated techniques for years. AI is another development in that process, rather than the invention of automated vulnerability research.

It also presents opportunities for attackers. Once a vulnerability is disclosed and a patch is published, tools can help people compare the changed code, investigate the weakness and look for systems that haven't yet been updated.

That isn't proof that AI discovered today's vulnerabilities or that attackers are using AI against PHP installations. It's simply part of the changing security landscape, and another reason why organisations need to keep their software maintained.

What should you do at 3PM?

The PHP Security Team has scheduled the official disclosure and security release for 15:00 BST, which is 14:00 UTC, today, Wednesday 21 October 2026.

That doesn't necessarily mean every operating-system repository, managed hosting provider or container registry will have updated packages available at precisely 3PM.

What matters is understanding the confirmed technical details and applying the appropriate fixes to the affected systems as quickly and safely as possible.

Here's the order I'd follow:

• Read the official PHP announcement. Establish which vulnerabilities have been confirmed, which PHP versions and components are affected, and what conditions are required for exploitation.

• Open the spreadsheet you prepared earlier. Match the affected versions against your own systems and identify which ones need attention.

• Prioritise your production servers. I'd start with internet-facing applications, particularly those handling customer information, authentication, payments or other sensitive operations.

• Check your package and hosting providers. Find out which patched versions are available and whether your provider is issuing a security update or backport for the PHP build you're running.

• Download the verified updates. Use trusted PHP releases, operating-system packages or official container images rather than unverified third-party binaries.

• Test and deploy the fixes. Use your established testing and rollback procedures, keeping the checks proportionate to the urgency and avoiding unnecessary delays.

• Restart the relevant services or replace affected containers. Simply installing an updated PHP package doesn't necessarily mean existing PHP-FPM workers, Apache processes or running containers are using the corrected code.

• Verify what's actually running. Check the PHP runtime serving each application, rather than assuming the update succeeded because your package manager completed without errors.

• Test the application. Make sure critical functionality still works, including authentication, database access, forms, payments, API integrations and scheduled jobs.

• Review your logs and update your team. Record which systems have been patched, which remain outstanding and whether anything needs further investigation.

If there is evidence that one of your servers has already been compromised, remember that patching the vulnerability may not be sufficient. You'll need to investigate what happened, look for persistence mechanisms, consider whether credentials have been exposed and potentially restore the system from a known-good state.

This is where having clean operating-system images, reliable backups and your application stored in Git can make recovery substantially easier. You can rebuild a server, reinstall the patched runtime and redeploy a known-good version of the application rather than attempting to repair a potentially compromised installation.

But don't assume that redeploying your application means everything is clean. You still need to verify the integrity of databases, uploaded files, credentials and other persistent data.

I also wouldn't treat 3PM as some magical deadline at which every unpatched PHP website becomes compromised. It's simply the time PHP has scheduled for releasing the details and fixes, unless they become available earlier.

The important thing is being ready to respond when we know what we're actually dealing with.

What have we been doing, and what's next?

As I mentioned earlier, this article is a little later than I intended because we've been spending the morning making sure our own systems are ready.

Fortunately, all my own projects are already running PHP 8.5, so I'm not facing the prospect of upgrading years of legacy code just to reach a supported branch. I've made a point of keeping my applications and their PHP versions reasonably current, and situations like this demonstrate why that approach is worth the effort.

We've been going through our server documentation, checking that the information is accurate and that we have the correct access credentials for everything we maintain. That includes production servers, staging environments and our local development setups. There's no point preparing to update production if the staging environment you're relying on hasn't been maintained or you suddenly discover you can't access one of your servers.

We've also been checking client backups and the files needed to restore their applications, while making sure our automated upgrade scripts have been tested ahead of the release.

I already have shell scripts and automation set up to connect to servers and perform maintenance tasks. We've prepared and pre-tested the upgrade automation so we're not trying to write deployment scripts in a hurry once the official security updates appear.

That doesn't mean I'll be executing anything blindly at 3PM. I'll first review PHP's announcement, establish which versions are affected, check the packages and then use the scripts to deploy the relevant fixes.

Because the applications are already running a modern PHP version and the deployment process has been prepared in advance, I'm expecting the work to be relatively straightforward, with minimal downtime.

We've also already contacted all our clients, including those who may still be asleep in other time zones. I wanted them to know what was happening before the technical details were released, rather than receive an unexpected message later telling them their website needed emergency maintenance.

Not everybody follows PHP security announcements, and plenty of businesses depend on developers or hosting companies without knowing exactly which PHP version their website uses.

If any of our clients or organisations I've recently worked with need help checking their PHP installations or understanding the announcement, I'm happy to give them a hand, without charging for the advice.

I'd rather help somebody understand whether they have a problem than have them unknowingly continue running something that could put their business at risk.

Where to follow the official announcements

If you're managing PHP systems today, I'd recommend keeping the following sources handy.

The original news-web.php.net mailing-list archive is also an official PHP resource, but its web interface was returning a 502 error when I checked today. I'd use the PHP website or PHP Foundation forum for the announcement rather than rely on that archive being available.

I'd also keep an eye on announcements from your Linux distribution or hosting provider, since patched packages and security backports may be released on their own schedules.

Final thoughts

At the time of writing, PHP has confirmed two CRITICAL vulnerabilities, each rated 9.2 out of 10, with an official security release scheduled for 3PM UK time today.

We still don't know which PHP versions are affected or whether the reported remote code execution claims are accurate, and I don't think there's much value in pretending otherwise.

What concerns me more is how many organisations could find themselves struggling to respond because they haven't maintained their applications, don't know which PHP versions they're using or no longer have straightforward access to their own infrastructure.

I've worked with enough legacy systems to know how easily that situation develops. An upgrade gets postponed because the application works, then another upgrade gets postponed because the previous one was never completed. A few years later, the organisation is running something nobody wants to touch because nobody fully understands what might break.

And then an announcement like this appears.

We can't do much about the vulnerabilities themselves until PHP publishes the technical details, but we can make sure we're prepared.

I'd spend the time between now and 3PM identifying systems, verifying backups, checking credentials, making sure monitoring works and getting the deployment process ready.

If you're already running a supported PHP version and have a sensible update process, you're in a much better position to deal with whatever PHP announces.

If you're still relying on unsupported versions without security backports, this should be another reminder that keeping software maintained isn't simply about having the latest features. It's about ensuring you're still receiving fixes for vulnerabilities that are discovered long after the software was originally released.

The last thing you want at 3:05PM is to discover a forgotten PHP 5.4 server that nobody can access, nobody knows how to update and nobody is quite sure how to restore.

A note for managers and technical leaders. Don't expect your engineers to complete every recommendation in this article today. Some of this work could take weeks or even months, particularly if you're dealing with legacy applications. But give them the time and support to tackle the immediate security risks now, and make sure there's a proper migration plan for anything that can't be fixed today.