Critical PHP Security Release: Two CVSS 9.2 Flaws and What to Do Right Now

The PHP security team does not usually announce patches before they ship. So when it posted an advance notice on the evening of 20 October 2026 warning of an out-of-cycle security release for two critical vulnerabilities, both rated 9.2 under CVSS v4.0, the message was clear enough. If you run PHP anywhere that faces the internet, today is a patching day.

The release is scheduled for Wednesday 21 October at 14:00 UTC. Details of the flaws, the affected versions and the fixed builds are being withheld until then. Here is what we know, what is still rumour, and what you should be doing in the meantime.

What the PHP security team has actually said

The official notice is short. It confirms two critical vulnerabilities, gives the release time, and encourages all PHP users to prepare now so they can upgrade the moment the builds are available. It also reserves the right to release early if either flaw becomes public or if exploitation is spotted in the wild.

That last line matters. The team is treating this as a live embargo rather than a routine patch cycle, which tells you how seriously they rate the risk.

What is rumour and what is confirmed

The story leaked a day early. A post on Hacker News on 20 October claimed two PHP remote code execution bugs, scored CVSS 10.0 and affecting every version since PHP 5, were due for disclosure on Thursday 22 October. Researchers at watchTowr confirmed the leak was real and that the flaws were under embargo, and PHP’s notice followed that evening with the release pulled forward to Wednesday.

Two CVE identifiers are circulating, CVE-2026-109618 and CVE-2026-109619, and the pair has picked up the nickname “php2shell” in the research community. Neither the identifiers nor the name appear in PHP’s own notice. The claim that every version back to PHP 5 is affected is also unconfirmed, as is the suggestion that the bugs sit in a specific component. Until the advisory lands, treat the scope as unknown and assume every PHP installation you own could be in it.

What is confirmed is the severity. A 9.2 on CVSS v4.0 sits firmly in the critical band, and watchTowr’s own FAQ describes both as remote code execution. As of this morning, no exploitation has been reported and neither CVE is in CISA’s Known Exploited Vulnerabilities catalogue. That window will not stay open for long. When CVE-2024-4577 went public in June 2024, Akamai saw exploit attempts against its honeypots within a day.

Which PHP versions can receive the fix

Whatever the affected range turns out to be, PHP only ships security fixes for its four supported branches. Several trackers expect the patched releases to be PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, although PHP has not confirmed the numbers.

Anything older, including 8.1, 8.0, 7.x and 5.x, is end of life and will receive no fix from PHP. That is the part of this story that should worry UK businesses most. On 20 October, security firm Mallory counted roughly 884,000 internet-facing hosts whose HTTP banner reported PHP 8.1 or older, around 59 per cent of all hosts that reported a version at all. A further 740,000 hosts reported PHP with no version. Those are banners rather than confirmed vulnerable systems, but the scale of the legacy estate is obvious.

Some Linux distributions and hosting providers backport fixes to older packages, so check with your vendor before assuming you are stranded. If nobody is going to patch your PHP version, you need another plan.

What to do before 14:00 UTC

PHP has published no workaround, so preparation is about readiness rather than mitigation.

Find every PHP install you run. This is harder than it sounds. PHP turns up inside vendor appliances, Windows software, monitoring tools, intranet apps nobody has touched in years, and control panels such as cPanel and Plesk. If you have not run an asset discovery exercise recently, now is the time.

Prioritise internet-facing systems. Public web servers, customer portals and anything reachable without a VPN go first. Internal systems follow, but do not treat them as safe. An attacker with a foothold on the network will go looking for exactly this kind of bug.

Know where your update is coming from. For some systems that means a package manager. For others it means a hosting provider, a container base image, or a software vendor who bundles PHP and may be days behind. Work out who owns the patch for each system before the release lands rather than after.

Protect what you cannot patch. For end-of-life installations, take the system off the public internet, put it behind a VPN or a web application firewall, or isolate it until you can upgrade. CERT-EU has gone as far as advising organisations to consider isolating internet-facing PHP applications entirely until a fix is available.

Watch what PHP starts. Alert on php-fpm, php-cgi, httpd or apache2 spawning shells, interpreters or download tools. Florian Roth has published a lightweight process-watcher script for Linux servers without endpoint detection. It logs every program a PHP process launches, along with its command line. It will not stop anything, but it will tell you if you have already been hit.

Have an incident plan ready. If you find something, isolate the server, preserve the web server and PHP logs, and search for web shells, new files in the web root, unexpected cron jobs, scheduled tasks and new user accounts.

Why this matters for UK businesses

PHP still powers an enormous share of the web, including WordPress, Laravel, Drupal, Magento and a long tail of bespoke applications built a decade ago and never revisited. For many small and mid-sized UK firms, the PHP version in production was chosen by a web agency that no longer exists.

William Fieldhouse, Director and Senior Penetration Tester at Aardwolf Security, said: “Every year we test environments where the client has no idea what PHP version they are running, let alone whether it is still supported. A critical pre-auth RCE in the interpreter itself is the scenario that turns a forgotten staging server into a full network compromise, and the only real defence is knowing what you have before the exploit code appears.”

If you are not certain where PHP lives in your estate, a vulnerability assessment is the fastest way to find out. An external network penetration test goes a step further and shows you exactly what an attacker would see from the outside, including version banners you may not realise you are leaking.

Frequently asked questions

Is PHP being actively exploited?

Not as of the morning of 21 October. No exploitation has been reported by Huntress, watchTowr or any other tracker, and the CVEs are not in CISA’s KEV catalogue. Expect that to change quickly once the patch diff is public.

Does this affect WordPress sites?

If the flaws are in the PHP interpreter, every WordPress site is exposed, regardless of plugins or themes. You can check your PHP version in WordPress under Tools, Site Health, Info, Server. If you are on managed hosting, your provider should be patching for you, but confirm it rather than assume.

What if I am on PHP 7 or 8.1?

PHP will not release a fix for end-of-life branches. Check whether your Linux distribution or hosting provider backports security fixes. If not, isolate the system or upgrade. Running an unsupported interpreter on the public internet after this release is a risk that no WAF will fully cover.

What is the difference between the CVSS 10.0 and 9.2 scores?

The 10.0 figure comes from the leaked Hacker News post, not from PHP. The official rating is 9.2 under CVSS v4.0. Both are critical, but only the 9.2 is sourced.

Should I wait for the full advisory before patching?

No. The patched builds will be available at 14:00 UTC and the advisory will arrive alongside them. The purpose of reading the advisory is to understand your exposure on the systems you cannot patch immediately, not to decide whether to patch the ones you can.

Get ahead of the next critical release

Emergency patches like this one expose a simple truth: you cannot protect what you do not know you have. Aardwolf Security helps UK organisations map their external attack surface, identify unsupported software before attackers do, and test whether a critical vulnerability in a single component can be turned into a full compromise.

Whether you need a one-off assessment following today’s release or an ongoing testing programme, get in touch with our team and we will help you work out where to start.