Critical PHP vulnerabilities, October 2026: what to do now

Update: 21 October 2026, 10:00 UTC. The PHP security release is scheduled for 14:00 UTC today. This article will be updated with the CVE identifiers, affected versions and fixed versions as soon as they are published.

On 20 October 2026 the PHP Foundation announced a security release for two critical vulnerabilities in PHP, each rated 9.2 on the CVSS v4.0 scale. The release is due on Wednesday, 21 October 2026, at 14:00 UTC. Any organisation that runs PHP, directly or through applications, hosting or appliances that bundle it, should be ready to patch the same day.

Key points

Two critical PHP vulnerabilities, each scored CVSS v4.0 9.2. Technical details, affected versions and fixed versions are released together with the patch.
The release is scheduled for 21 October 2026 at 14:00 UTC, but PHP may release earlier if details become public or active exploitation is observed.
The UK National Cyber Security Centre (NCSC) has issued an alert to UK organisations. The risk, however, is global: PHP runs on 69.3% of websites whose server-side language is known (W3Techs, 21 October 2026).
According to the NCSC, systems that cannot be patched immediately should be considered for temporary removal from service until fixed.
End-of-life PHP versions (8.1 and older) receive no official fixes. Roughly a third of PHP websites still run version 7 or older.

What was announced, and why it matters everywhere

The PHP Foundation notice is short and deliberately light on detail: two critical vulnerabilities, a CVSS v4.0 score of 9.2 for each, and an exact release time. This is typical of coordinated disclosure. Maintainers give administrators advance warning so they can prepare, without publishing anything that would help attackers before a fix exists.

The NCSC turned the notice into an official alert for UK organisations, with unusually firm advice: if a system cannot be remediated immediately, consider taking it offline until it can be. The alert is addressed to the UK, but nothing about the problem is local. PHP powers WordPress, Drupal, Joomla, Magento, Laravel, Moodle, Nextcloud, most e-commerce platforms and a large share of the world’s shared hosting. Attackers scanning the internet do not respect borders.

Why this should be treated as urgent

A CVSS score of 9.2 usually indicates a flaw that can be exploited remotely, with no or minimal authentication, and with major impact on confidentiality, integrity and availability. For a language that runs directly on internet-facing servers, that typically means a risk of code execution or full server compromise.

Recent history shows how short the window is. CVE-2024-4577, a PHP-CGI flaw on Windows disclosed in June 2024, was exploited within days, including by ransomware groups. Once a fix ships, attackers compare the old and new code and rebuild the vulnerability. The gap between a patch and the first automated attacks is now measured in hours or days, not weeks.

Where PHP hides in your infrastructure

The NCSC’s first recommendation is to identify every system running any version of PHP. In practice, PHP shows up in more places than most organisations expect:

websites and web applications: the corporate site, the online shop, the customer portal, the intranet, the e-learning platform;
shared hosting and cPanel/Plesk: the provider updates PHP, but each site often picks its own version and old versions stay available;
containers: Docker images based on php do not update themselves; they must be rebuilt and redeployed;
Linux distribution packages: Debian, Ubuntu, Red Hat and their derivatives backport fixes into their own versions, so the version number will not match the one announced on php.net;
third-party appliances and products: management interfaces of firewalls, NAS devices, routers, monitoring systems or VoIP platforms that bundle PHP without making it obvious;
vendor-managed services: the web agency, integrator or SaaS provider running the application on your behalf.

What to do today, step by step

Before the release (until 14:00 UTC)

Inventory. List every system running PHP, with its exact version (php -v or the application’s information page) and an owner for each. Internet-facing systems come first.
Prepare the patch window. Book people for the evening of 21 October and for 22 October. Make sure you have recent, tested backups.
Decide the fallback in advance. For each critical exposed system, decide now what happens if it cannot be patched quickly: restricted access, maintenance mode or temporary shutdown.
Contact your vendors. Ask your hosting provider, web agency and appliance vendors when they will ship the fix and what you need to do.

After the release

Read the official announcement on php.net: CVE identifiers, affected branches and fixed versions.
Patch internet-facing systems first, then internal ones. Restart PHP-FPM, Apache or the web service afterwards, otherwise old processes keep running the vulnerable code.
Rebuild container images and redeploy them; updating the host is not enough.
Check the version actually running after the update, not just the installed package.
Monitor web server logs for unusual requests, new processes spawned by the web server user, and recently created PHP files in upload directories.

If you run an end-of-life PHP version

As of 21 October 2026, the officially supported PHP branches are 8.2 and 8.3 (security fixes only) and 8.4 and 8.5 (active support). Branch 8.2 reaches end of life on 31 December 2026. Versions 8.1, 8.0, 7.x and older no longer receive fixes from PHP.

According to W3Techs, 27% of PHP websites still run version 7 and almost 8% run version 5. It is not yet known whether these versions are affected. If they are, there will be no official fix. The realistic options are migrating to a supported branch, using an extended-support provider or a Linux distribution that still maintains that version, or strictly isolating the application. It is also a good moment to plan migrating applications off 8.2 before the end of the year.

What it means for NIS2 entities

In the European Union, essential and important entities under the NIS2 Directive must handle vulnerabilities and apply technical measures proportionate to risk, and management bodies are accountable for those measures. A publicly announced critical vulnerability with a known release date is exactly the kind of event an auditor will later look at: how quickly you reacted and how you documented your decisions. Keep a record: when you learned about it, which systems you identified, when you patched them and what you did with those you could not patch.

If you find signs of compromise after patching, it becomes an incident. For NIS2 entities, significant incidents must be notified to the competent authority or CSIRT (in Romania, DNSC), and if personal data is affected, notification to the data protection authority under Article 33 GDPR must also be assessed.

Frequently asked questions

When is the PHP security release?

The PHP Foundation scheduled the release for Wednesday, 21 October 2026, at 14:00 UTC. It may come earlier if details of the vulnerabilities become public or if active exploitation is observed.

Which PHP versions are affected?

Affected and fixed versions are published together with the release. The officially supported branches at this date are 8.2, 8.3, 8.4 and 8.5. Versions 8.1 and older receive no official fixes.

Does the NCSC alert only apply to the UK?

The alert is addressed to UK organisations, but the vulnerabilities are in PHP itself, which runs on about 69% of websites whose server-side language is known. The risk is the same for any organisation in the world that uses PHP.

What if I cannot patch immediately?

The NCSC advises considering taking the system offline until it can be remediated. Interim options include restricting internet access, putting the application in maintenance mode and closely monitoring logs. For third-party appliances, follow the vendor’s advisories.

I have a WordPress site on shared hosting. Do I need to do anything?

Check in your hosting control panel which PHP version the site uses and whether it is a supported branch. Ask the provider when they will apply the update. If the site runs on PHP 7 or an end-of-life 8.x version, ask to move to a current one.

How do I check whether a server has already been compromised?

Look in web server logs for unusual requests, check processes started by the web server user and recently created PHP files in upload or temporary directories. If you find indicators, do not delete anything before preserving evidence, and request a technical analysis.

Sources

Alexandru Angheluș, ProDefence. Cybersecurity specialist working in cyber incident investigation, malware analysis and NIS2 compliance.