Economy Cybersecurity
Critical PHP and Node.js vulnerabilities, the fixes from October 21
On October 21, 2026, two critical security bulletins were published for PHP and Node.js, which can allow remote code execution. Locarno software house Webcracy explains why updating the website or CMS is not enough, and how to replace a runtime without stopping applications.

On October 21, 2026, two separate security bulletins were published: one for PHP, the other for Node.js. Both concern vulnerabilities that can allow remote code execution, meaning an attacker could run commands on a system without needing credentials.
Two flaws were reported for PHP, CVE-2026-109618 and CVE-2026-109619. The first concerns memory handling when system resources run out: some request data can remain only partially initialized and still be treated as valid during cleanup. The issue was demonstrated on configurations using Apache and mod_php, and can occur before the application checks the user's credentials. PHP-FPM is also considered at risk, although for this variant there is not yet a complete demonstration of the attack. The second flaw concerns internal data that a PHP process can retain after freeing the memory of a previous request: a later request can end up accessing those references, which are no longer valid.
For Node.js, the bulletin reports CVE-2026-111497, a high-severity flaw in the decoder for the Brotli compression format, which is also used in web traffic. Here too, the vulnerability can lead to remote code execution, although the actual risk depends on how the application processes the compressed data it receives. The same Node.js update also fixes issues related to DNS and TLS certificate verification.
The fixes are included in the most recent releases from both projects, but identifying the right version is not always simple. A Linux distribution may have already applied the fix while keeping a version number that looks old: for PHP 8.3 on Ubuntu 24.04, for instance, the fix corresponds to package 8.3.6-0ubuntu0.24.04.13, not to an obvious version jump.
For those running PHP servers there is a free tool, php2shell-audit, published on GitHub. It lists the PHP installations on a machine, reads their exact version and the distribution package they come from, and compares them with the fixed releases, taking into account fixes backported by distributions. It can also search logs for traces of an attack attempt. The scanner does not try to exploit the flaws: on remote sites it only reads the response headers, and it should be used only on one's own systems or with explicit permission.
The same comparison is applied passively to public administration by the Swiss Public-Sector Security Census, a Webcracy project that checks some 2,200 municipalities, cantons and federal offices every day using only public data. Among other things, it shows how many of the bodies that disclose their PHP version are already running a fixed release. A missing header, however, is not enough to say that a site is safe.
The verification work behind the update
Webcracy, a Locarno software house that looks after websites and applications for Ticino businesses, described how it handled the update for its clients. The first step was finding out which versions of PHP and Node.js were actually serving requests: the system PHP, one inside a container and one belonging to a separate application can all coexist on the same server, and fixing one leaves the others as they were. A Node.js already loaded into memory by a process manager such as PM2 also keeps running until it is restarted, whatever version has been installed in the meantime.
Before making changes, previous versions of the containers and copies of the databases were kept, so it would be possible to roll back in case of problems. The changes were tested on isolated copies of the environments, with the applications' automated tests and manual checks on the functions that matter to everyday users: logins, databases, documents. The switch in production happened without interruptions: endpoint monitoring kept receiving correct responses.
The case shows why a site protected by a VPN, or updated only at the CMS level, is not automatically safe: the fix concerns the PHP or Node.js runtime that executes the application, not just the software written on top of it. An application can also keep using an old version of the runtime inside a Docker image, even after the operating system has been updated.
Comments
Liam
https://census.webcracy.ch/
