Vulnerabilities

Leaked PHP2Shell flaws force emergency PHP patch today

Two critical PHP remote code execution flaws leaked before a fix. PHP’s emergency release is due at 15:00 BST today: here is how UK firms should prepare.

Warning graphic for leaked critical PHP remote code execution flaws CVE-2026-109618 and CVE-2026-109619

Details of two critical remote code execution flaws in the PHP interpreter leaked before a fix existed, and the PHP project has pulled its emergency release forward to 15:00 BST today. Any UK organisation running PHP-based websites, from a shared-hosted WordPress site to a busy Magento shop, should be ready to patch this afternoon.

What happened

On the morning of Tuesday 20 October, an anonymous post on Hacker News claimed that two serious PHP vulnerabilities were about to be disclosed. The post was removed, but screenshots had already spread across social media. Within hours, the attack surface management firm watchTowr publicly confirmed the bugs were genuine and said it had successfully reproduced one of them, CVE-2026-109618.

The PHP security team responded the same day with an advance notice of a critical security release covering two vulnerabilities, which researchers link with CVE-2026-109618 and CVE-2026-109619, although PHP’s notice does not name them. The project rates both 9.2 under CVSS v4.0. The fix was originally under embargo until Thursday 22 October, but PHP has brought it forward to Wednesday 21 October at 14:00 UTC, which is 15:00 in the UK. The project also said it may ship even earlier if technical details become public or attacks are seen in the wild.

Researchers are calling the issue “php2shell”. According to Sansec, an image of a tool called PHP2Shell, attributed to the research outfit Calif, also escaped along with the advisory details. As of the time of writing, there is no public proof-of-concept code and no confirmed exploitation. Huntress said no indicators of compromise had been confirmed, although a brief exploitation video appeared online before being taken down.

The technical picture

Hard facts are thin by design: PHP says full details, affected versions and fixed versions will only be published with the release, and it has not named the bug class. What we know comes from people who have seen the leak or the research:

  • Remote code execution in the core. watchTowr describes both flaws as remote code execution bugs. Because they sit in the PHP interpreter rather than in an application or plugin, any site built on PHP could be exposed, whatever framework or CMS sits on top.
  • Severity may be understated. According to Cyber Daily, watchTowr says the flaws are in fact a maximum 10, not 9.2.
  • Very wide version range. watchTowr says PHP 5, 6, 7 and 8 are all affected. According to Sansec, the leaked tool’s banner claims it works against every release from 5.4.0 onwards. PHP has not confirmed this.
  • Fixed at the server, not in the app. Sansec stresses that the attack hits PHP itself before any store or application code runs, so application-level filters cannot be relied on.

The size of the unsupported estate is the real worry. According to SecurityOnline, citing Mallory, roughly 1.5 million internet-facing hosts advertise a PHP version, and 59% of those run PHP 8.1 or earlier. Sansec notes that only PHP 8.2 and later is officially supported, so older branches may receive no official fix at all.

One interim measure doing the rounds, according to SecurityOnline, is to switch off PHP’s session upload progress feature (the session.upload_progress.enabled setting) and to block multipart form uploads on routes that do not need them. PHP has not endorsed this, so treat it as a short-term hardening step, not a fix.

Timeline of the PHP2Shell leak from the Hacker News post on 20 October to PHP's emergency release at 15:00 BST on 21 October

Why it matters for UK organisations

PHP is the quiet foundation under a large share of the UK web. It runs WordPress, Drupal, Joomla, Magento, WooCommerce and Shopware, and it sits inside hosting control panels such as cPanel and Plesk. For British SMEs, charities, schools, local councils and e-commerce retailers, that means exposure is likely even where nobody on staff thinks of the organisation as “running PHP”.

Shared and managed hosting is the second issue. Many small UK businesses do not control the PHP version on their server. They depend entirely on their hosting provider to apply the update, and some providers still run old branches for customers with legacy sites.

There is also a compliance angle. Cyber Essentials requires high-risk and critical security updates to be applied within 14 days of release. With exploitation expected within hours, 14 days should be treated as an outer limit, not a target.

Expert view

A pre-patch leak of a remote code execution bug in a language runtime is about as bad as it gets for coordinated disclosure. Normally defenders and attackers start the race at the same moment, when the advisory lands. This time attackers have had a day’s head start on reconnaissance, and when the fix ships this afternoon, diffing the patched source will hand capable groups the root cause almost immediately. Sansec says it expects mass attacks to begin “within 15 minutes of the release”.

In my experience, the hardest part of a vulnerability like this is not applying the patch but finding everything that needs patching. When we test external estates, forgotten marketing microsites, old staging servers and bundled admin panels running end-of-life PHP turn up far more often than they should. They are likely to be hit first and noticed last, as such servers often have no endpoint monitoring.

Until PHP’s advisory says otherwise, plan for the worst case: every PHP version you run is affected.

What to do now

  1. Build your PHP inventory this morning. List every web server, container image, appliance and hosted site running PHP, along with its version. Include CMS platforms, control panels and third-party products that bundle php-cgi or php-fpm. This maps directly to the Cyber Essentials requirement to know your devices and software.
  2. Book a patch window for 15:00 BST today. Prioritise internet-facing systems. Take fixed version numbers only from the official PHP announcement, and check your Linux distribution and container base images for backported packages.
  3. Chase your hosting provider now. If you use shared or managed hosting, ask in writing when they will apply the update and whether your site is on a supported branch.
  4. Deal with end-of-life PHP. Anything on 8.1 or older may get no official fix. Upgrade it, take it offline, or put a VPN or web application firewall in front of it until you can.
  5. Consider interim hardening, carefully. Disabling the session upload progress feature and blocking unnecessary uploads may reduce risk. Test first, because it can break legitimate upload features.
  6. Watch what PHP spawns. Alert when PHP worker processes launch shells, scripting interpreters or download tools such as curl and wget, or run recon commands like whoami. Huntress points to Florian Roth’s free process-watcher tool as one option for unmonitored Linux servers.
  7. Prepare to hunt after the release. Look for new PHP files in web roots and upload directories, unexpected cron jobs, scheduled tasks and accounts. If you find signs of compromise, isolate the host and preserve web and PHP logs before you rebuild.

Bottom line

Treat this afternoon’s PHP release as an emergency change, not routine maintenance. The leak has removed the usual grace period, the affected population is enormous and a large slice of it runs unsupported versions. Do the inventory and the hosting conversations this morning, so that at 15:00 the only job left is to apply the fix.

Sources

Related Posts