PHP and Node.js: the October 2026 vulnerabilities

On 21 October 2026 we checked hundreds of services across containers, Node.js environments and PHP applications, and updated every exposed one the same day. Then we verified the processes actually running, ran thousands of automated tests on isolated copies of the application environments, and monitored the production endpoints until they returned nothing but correct HTTP responses. The hard part was keeping applications, databases, invoice generation and customisations working while we swapped out the runtimes.

The work was triggered by two separate announcements published on the same day: critical vulnerabilities in PHP and high-severity security updates for Node.js. Both concern the software that runs the applications. For a business, this means the problem can sit underneath the website or the management software, even when the code written for the project hasn't changed.

This is the situation as verified on 21 October 2026. The versions listed are the ones that fix these advisories; for an update carried out later, check any subsequent security releases as well.

Update of 26 October: exploitation attempts before the announcement

Amazon Threat Intelligence detected a PHP2Shell exploitation attempt in its MadPot sensors on 17 October, four days before the public disclosure on 21 October. The research, published on 21 October, also reports attempts from several infrastructures before the embargo ended. AWS notes that the technical analysis is ongoing and does not establish whether those attempts would have succeeded against real systems.

This changes the time window your checks need to cover: for an exposed service, AWS recommends starting no later than 17 October, reviewing logs, unexpected process executions and file changes. Installing the patch and looking for signs of an earlier compromise are two separate checks. An update completed on 21 October does not, on its own, prove that the system was clean in the days before.

The PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619

The official PHP announcement describes two flaws that can allow unauthenticated remote code execution. RCE, in practice, means an attacker can end up running code on the system through a remotely reachable vulnerability. Having a login on your site does nothing against a problem that can occur before the application checks credentials.

CVE-2026-109618 concerns how memory exhaustion is handled: some internal request data can be left only partly initialised and then treated as valid during cleanup. The case demonstrated on Apache with mod_php can trigger before any application code runs. The official analysis considers PHP-FPM susceptible too, with different attack paths and without a complete demonstration of an FPM exploit for this specific flaw.

CVE-2026-109619 instead concerns internal state that a process can retain after the memory of the previous request has been freed. A later request can access those now-invalid references. The conditions depend on how the worker behaves and on which operations are reachable: describing every installation as already compromised would be wrong, but so would considering it safe without the fix.

For anyone running a website, the practical consequence is clear: updating the CMS or its plugins may be necessary, but fixing these flaws also requires an updated PHP runtime. The problem can affect a custom business application just as much as a WordPress site.

Which PHP and Node.js versions contain the fixes

These are the upstream releases the projects point to for the 21 October advisories:

Runtime	Branch	Fixed release
PHP	8.2	8.2.35
PHP	8.3	8.3.36
PHP	8.4	8.4.27
PHP	8.5	8.5.12
Node.js	22	22.23.4
Node.js	24	24.22.1
Node.js	26	26.12.1

The table summarises the PHP releases and the Node.js advisory. It is not a suggestion to jump to the highest major version on every application: first you need to check compatibility, dependencies and native extensions.

There is also a detail that changes the diagnosis: the upstream version number is not enough to judge a Linux package. A distribution can apply the fix while keeping a base version that looks old. For PHP 8.3 on Ubuntu 24.04, for example, the official pages for CVE-2026-109618 and CVE-2026-109619 list the fixed package as 8.3.6-0ubuntu0.24.04.13. You have to read the full revision and the vendor's advisory. The same principle calls for care with unsupported branches: you need a fix documented by your vendor, or a migration to a maintained branch.

The same limit applies to checks from the outside. Our Swiss Public-Sector Security Census checks around 2,200 municipalities, cantons and federal offices every day using only public data, and passively compares the PHP version a site declares in its headers with the fixed release. It is a useful hint for getting an overall picture, not a diagnosis: many servers don't reveal their version, and a package with a fix backported by the distribution can look old. To know what is really running, you have to look inside the server.

Node.js, Brotli and the risk behind compression

The October Node.js advisory includes CVE-2026-111497, a flaw in the Brotli decoder rated high severity that can allow remote code execution. Brotli is a compression format also used in web traffic. Actual exposure depends on the paths through which the application processes compressed data an attacker can control; having Node.js installed does not, by itself, prove that an exploit is reachable.

The same release contains fixes for DNS, TLS certificate verification and other components. That's why we updated the affected runtimes and also tested compression, TLS initialisation and cryptography. A test that correctly compresses and decompresses data checks that the new environment is compatible; proof that the patch is included comes from the fixed version number and the verified provenance of the software.

For applications still on Node.js 20 we prepared a migration to a maintained branch. Native extensions deserve a test of their own: an SQLite module compiled for an earlier runtime may need to be rebuilt when you change major version.

Why updating the server doesn't automatically update Docker and PM2

On real infrastructure, the system PHP, the one inside an Apache container and the one used by a PHP-FPM application can all coexist. Fixing one leaves the others where they are. Even the version a terminal command reports has to be compared with that of the process actually serving requests.

With Docker, we checked the images actually in use, prepared replacements and kept the data volumes. A tag called latest doesn't certify that a patch is included, and a future rebuild can undo the work if the Dockerfile or the deployment procedure keeps selecting an old base. During this intervention we also checked the vendor packages and, where necessary, built runtimes from official sources with verified checksums.

With PM2, changing the shell's default Node does not replace an executable already loaded in memory. We checked the daemon, the child processes and the systemd supervision. The work also required some rollbacks and fixes to the procedure: being able to return to a working configuration was part of the preparation.

Updating PHP and Node.js without losing customisations and data

Before the switch we kept the previous images and prepared copies of the databases and volumes needed for testing. On the monitoring system we compared thousands of PHP and MIB files against the original snapshot, using the same read-only mounts. On the invoicing service we tested, in the clone, logging in, reading customers and invoices, downloading an existing PDF and generating a test document. On production we then rechecked service status and HTTP responses.

The test suites of the business applications completed thousands of tests without failures. The final controlled restart of those services and the definitive switchover of the invoicing service happened without downtime: the monitor on the production endpoints kept receiving correct responses. Across the whole job there were also attempts and rollbacks, prepared precisely so that end users wouldn't be affected.

A green healthcheck tells you that one specific check works. To know whether an application is still usable, you also need tests on the functions that matter: logins, databases, documents, job queues and integrations. It is a concrete part of managing hosting in Switzerland, and it needs to be organised before the next urgent advisory arrives.

Questions to ask whoever manages your site

Does a site protected by a VPN need updating?

Yes. The VPN reduces who can reach a service through the access points it protects; the fix removes the flaw in the runtime. They are measures with different functions. Having a VPN helps assess exposure and prioritise the work, but it doesn't replace a patch.

Is updating WordPress, Laravel or the JavaScript framework enough?

For these vulnerabilities you also need to check PHP or Node.js. Ask your provider which version is serving requests, which package revision includes the fix and which checks were completed after the restart. An application can keep using the runtime inside its own Docker image even after the operating system has been updated.

Can you guarantee 100% security after the update?

We can document the fixes installed, the tests passed and the checks carried out. That does not certify the absence of every other vulnerability or of an earlier compromise. During our checks, for example, we separately recorded a non-fatal warning from an application dependency that was already there before the PHP change. Keeping security patches, compatibility and pre-existing anomalies apart helps you make sensible decisions.

We can run this check for your company too

At Webcracy we can verify which versions of PHP and Node.js are running your website or business application, check whether the fixes are in place and identify which services to update first. We hand you an overview of what we checked, the work needed and the questions still open.

We can also take care of the updates: preparing backups, testing changes on copies of the data and checking the functions you use every day. Beforehand we agree on timing and approach; afterwards we document the changes and the tests carried out.

Tell us what you use and who currently manages your hosting: we'll start from there, involving your current provider if needed.

Let's talk about your website or business application↗

Illustrative photo: Taylor Vick on Unsplash, used under the Unsplash license. The data center pictured is not the one involved in this work.