PHP2Shell alert: CVE-2026-109618 and the PHP patch you need

What happened

On 21 October 2026 the PHP project shipped emergency patches for two critical unauthenticated remote code execution (RCE) vulnerabilities, nicknamed PHP2Shell by the community:

CVE-2026-109618: a memory-handling flaw (OOM corruption) that can interrupt PHP with request-internal data only partially initialised, and the cleanup treats that invalid data as valid.
CVE-2026-109619: a use-after-free: internal state keeps pointing at freed memory, and the next request handled by the same worker may end up using it.

Severity is high (CVSS 9.2) and this is not theoretical: Amazon detected real exploitation before the patch was published, and Sansec successfully reproduced the attack against WordPress, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin and Nextcloud. The UK’s NCSC went as far as recommending shutting down services that could not be patched.

Patched releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your hosting runs cPanel, there is also a fixed build for PHP 7.4 and above, and long-term-support Linux distributions usually backport the fix.

Who is affected

Pretty much any website running PHP that has not been updated: WordPress, WooCommerce, PrestaShop, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin, Nextcloud and many more.

Here is the key point: this is a flaw in the PHP language, not in each application. Updating WordPress or phpMyAdmin alone is not enough; you must update the PHP on the server and restart php-fpm, Apache or LiteSpeed, because the patch only takes effect once the workers are restarted. If your site sits on managed hosting (WordPress.com, SiteGround and the like), the provider has probably already done it, but it is worth confirming.

October 23 update: third CVE officially acknowledged

On October 23 the PHP project officially acknowledged a third vulnerability, CVE-2026-115560: another remote code execution issue, this time tied to session.upload_progress when the application switches the session serializer with ini_set() before session_start(). This is not a bypass of the October 21 patches: it is a new, narrow vector that PHP describes as unlikely in normal deployments. The fix will ship in the next regular bugfix release of each branch.

Meanwhile, the mitigation is one line in the server-level php.ini (an application-level ini_set() comes too late: upload-progress handling runs before application code), followed by a worker restart:

session.upload_progress.enabled = 0

If you already disabled upload progress following the October 21 advisory, you need no further action for this vector. If your application never touches session serializers, the risk is low; still, disabling upload progress if you don’t use it is good practice.

Also worth knowing: the patched versions themselves (8.4.27 and 8.5.12) carry a verified SimpleXML regression (double-free, php-src #24488): it can crash applications that use SimpleXML, but it is not remote code execution. PHP recommends not reverting the October 21 patches; a fix is on the way (PR #24494).

Source: PHP’s October 23 informational advisory and Syhunt’s defensive toolkit.

What to do today

Find out which PHP version your website uses (I explain how below).
If it is older than 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, update the server’s PHP from your hosting panel or ask your provider to do it.
Restart php-fpm, Apache or LiteSpeed after updating. Without a restart, the patch does not protect you.
If you use cPanel, pick an ea-php74 or newer build that already includes the fix.
If an agency or a freelancer maintains your site, email them today and ask for written confirmation that PHP is updated and the workers restarted.
If your website was built with Spain’s Kit Digital programme, contact your digitising agent or maintenance provider and ask for the same confirmation. It is not a new legal obligation, but it is a reasonable check you are entitled to request.

How to check your website

Only on your own domains — never scan other people’s sites:

WordPress: Dashboard → Tools → Site Health → Info → PHP version.
Hosting panel (cPanel, Plesk): look for the “PHP version” selector.
Over SSH: php -v. Careful: the CLI version can differ from the one the web server uses; the reliable way is a temporary phpinfo() or asking your host.
Ask your hosting provider directly.
Online checkers (verified on 22 October 2026): senseforat.cat, a free passive tool in Catalan that sends a single request from the outside, touching nothing, to find out whether a website exposes PHP and which version, in the face of PHP2Shell; php2shell.sh by Imperva, Brandefense, Arvion and Bugshield. An honest caveat: they read the PHP version your server exposes publicly, and many servers hide it, so “not detected” does not mean “safe”. Use them only for your own domains and confirm with the methods above.

Node.js and phpMyAdmin

The same day, Node.js published its own security updates: 10 vulnerabilities (4 high) in the 26.x, 24.x and 22.x branches, the most severe being remote code execution in the Brotli decoder. Fixed releases are 26.12.1, 24.22.1 and 22.23.4. Node 18 and Node 20 are end-of-life and will not get a patch: if anything of yours runs there, it is time to migrate.

phpMyAdmin has no patch of its own: it is protected by updating the PHP on the server where it runs, just like everything else.

Others helping too

Not everything has to come from here. I verified these resources today and share them as they are:

senseforat.cat — a free, passive tool in Catalan: it sends a single request from the outside, touching nothing, to find out whether a website exposes PHP and which version, in the face of PHP2Shell. It keeps a public log of results (10 scans per minute maximum) and also watches the websites of Catalonia’s 947 municipalities using open data from the Generalitat.
YesWeLab — an experiment built on public sources (php.net, BOE, NVD, W3Techs) estimating that some 115,500 Kit Digital websites (range 82,900–166,700) still run PHP versions without the PHP2Shell patch. It points out that the requirements for the “Sitio web” solution (€2,000) covered hosting, accessibility and SEO, but the word “security” does not appear once; it cites CISA’s recommendation to disconnect systems running PHP 8.1 or older; and it offers a free script so digitising agents can inventory the CMS and versions across their portfolio of websites.
transparencia.omitsis.com — a good example of the model, built by Omitsis, one of my clients: a free transparency evaluator for foundations, NGOs and associations that reviews up to 30 pages and PDFs and delivers a report citing the specific standard behind each point.

We’re firefighters, not competitors

When the fire is this big, nobody asks which brigade you belong to. PHP2Shell is not a business opportunity: it is a natural disaster on a global scale that can affect billions of people directly or indirectly — the shop downstairs, the town hall, the neighbourhood association’s website. These days engineers are not vendors: we are firefighters. Nobody competes with anybody: we are all holding the same hose.

That is why this page links, without embarrassment, to resources built by other teams: if your website is at risk, it helps all the same, whoever made it. We are all in this together.

Sources

If you need a hand with your website — checking the PHP version, updating safely or reviewing the server — email me and I will help you out.

PHP2Shell alert: update the PHP running your website

Check your website