PHP2Shell alert

What happened

On 21 October 2026, the PHP project released emergency patches for two critical vulnerabilities that allow code execution on the server without any authentication. They are known as PHP2Shell and score 9.2 out of 10 on the CVSS scale:

• CVE-2026-109618: PHP’s memory manager can interrupt execution when memory runs out, leaving the request’s internal data only partially initialised; the subsequent cleanup may treat that invalid data as valid.
• CVE-2026-109619: a use-after-free: internal state keeps pointing at freed memory, and the next request processed by the same worker may end up using it.

This is not a theoretical flaw. Amazon (via its MadPot honeypot) detected real exploitation before the disclosure, from 17 October, and Sansec has reproduced the attack against WordPress, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin and Nextcloud. The UK’s NCSC has gone as far as recommending shutting down services that cannot be patched.

Who is affected

Practically any website running PHP on a server that has not applied the patch: WordPress, WooCommerce, PrestaShop, Moodle, phpMyAdmin, custom applications… and also sites on shared hosting if the provider has not updated.

The key point: this is a flaw in the PHP language itself, not in each application. Updating WordPress, phpMyAdmin or any plugin is not enough: you must update the server’s PHP and restart php-fpm, Apache or LiteSpeed. The patch only takes effect once the workers are restarted.

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

1. Update the server’s PHP to one of the patched versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you run a long-term-support distribution, the fix has been backported; cPanel has also backported it down to 7.4 (ea-php74 and above).
2. Restart php-fpm, Apache or LiteSpeed. Without a restart, the patch protects nothing, even if the package is installed.
3. If you are on managed hosting (WordPress.com, SiteGround and the like), the provider should have done this already, but it is worth asking for written confirmation.
4. If your website was built by a Kit Digital digitalising agent, write to them and ask them to confirm the server’s PHP is updated and restarted. Many of the affected sites are SMEs in exactly this situation.
5. If you maintain the server yourself, check the version and restart the services; if you cannot patch it, consider temporarily switching off anything non-essential.

How to check your website

For your own websites only: never scan other people’s sites. Reliable ways to find out which PHP version your server runs:

1. WordPress: Dashboard → Tools → Site Health → Info → PHP version.
2. Hosting panel (cPanel, Plesk): look for the “PHP version” selector.
3. Over SSH: php -v. Careful: the CLI version may differ from the one the web server uses; the reliable options are a temporary phpinfo() or asking your host.
4. Ask your hosting or maintenance provider directly.
5. Third-party online checkers, verified on 22 October: senseforat.cat, a free, passive Catalan tool that makes a single request from outside without touching anything; php2shell.sh (by Imperva), Brandefense, Arvion and BugShield. One honest caveat: they read the PHP version the server exposes publicly, and many servers hide it; if they return nothing, use methods 1 to 4.

Node.js and phpMyAdmin

phpMyAdmin has no patch of its own: it is protected by updating the PHP of the server it runs on.

The same day, Node.js released fixes for 10 vulnerabilities (4 high, 3 medium, 3 low) in the 26.x, 24.x and 22.x branches: patches in versions 26.12.1, 24.22.1 and 22.23.4. The most severe is an RCE via an out-of-bounds write in the Brotli decoder. Node 20 and 18 are EOL and will not receive a patch: if you run them, it is time to migrate.

Others helping too

When a problem is this big, many teams put real work into it and do it well. These three resources, verified on 22 October, strike us as useful and we link to them with no strings attached:

• senseforat.cat: a free, passive tool in Catalan that makes a single request from outside —without touching anything— 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 monitors 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 (in a range of 82,900 to 166,700) are still on PHP versions without the PHP2Shell patch. It also points out that the requirements of the “Website” 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 digitalising agents can inventory the CMS and versions across their portfolio.
• transparencia.omitsis.com: a free transparency assessor for foundations, NGOs and associations, reviewing up to 30 pages and PDFs and delivering a report with the specific rule behind each point. A good example of the model, built by Omitsis, one of our clients: free, useful tools that build trust.

We’re firefighters, not competitors

When the fire is this big, nobody asks which crew 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 pulling on 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.

Don’t know where to start? We’ll do it for you

If your website came back vulnerable and you have nobody to patch it, we can do it: we analyse your server, apply the PHP2Shell patch and verify it is properly closed. While we’re at it, we also check the other recent holes (Node.js, phpMyAdmin) and leave you a clear report of what was touched and how it ended up.

No small print: tell us your case and we’ll tell you what needs doing and how long it takes. If you can do it yourself with the instructions on this page, we’ll say so all the same.

Write to us → or directly at hola@file.cat.

Sources

• PHP: releases
• Node.js: October 2026 security releases
• UK NCSC on PHP2Shell
• Wiz analysis
• Help Net Security: PHP2Shell CVE-2026-109618 and CVE-2026-109619

If you need help updating your website, talk to us: we do this every day and we will explain it without unnecessary jargon.