TL;DR

Buying for a business?Offer from Amazon

Get business pricing on monitors, keyboards and dev gear

• Business-only prices and quantity discounts
• Tax-exempt purchasing
• Multiple users, one account, clear invoices

Create a free Business account →Free to register

As an affiliate, we earn on qualifying purchases.Hide

PHP released fixes on Oct. 21 for two critical remote code execution flaws known as PHP2Shell, and Node.js issued fixes for ten vulnerabilities across supported release lines. Server owners need to confirm that patched code is running; cloud and vendor packages may have different update schedules.

PHP released fixes on Oct. 21 for two critical flaws, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell, while Node.js patched ten vulnerabilities across its supported release lines. The updates address risks that can affect web servers and applications, but protection depends on whether the fixed packages have been installed and are serving live requests.

PHP’s security advisory lists both PHP2Shell flaws as Critical, with CVSS v4.0 scores of 9.2. The project describes one issue involving out-of-memory corruption and another involving stale global state. The supplied advisories say an attacker needs no account or user interaction; successful exploitation could allow remote code execution with the privileges of the web worker. That does not by itself grant root access, though a web worker may be able to read application files, configuration and database credentials.

Fixed PHP releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.6.0 RC4 is a release candidate for testing, not a production fix recommendation. The PHP project does not provide official releases for versions 8.1, 8.0 or 7.4; it published minimal source backports for people who build those versions themselves. Users of those older branches should check whether their distribution or long-term support vendor has packaged the fixes, or plan an upgrade.

The PHP advisory says all installations serving web requests may be exposed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies Apache with mod_php as carrying the highest risk and says an unauthenticated request can trigger the demonstrated attack before application code runs. The advisory says the stale-state flaw was validated against mod_php and FPM; it says a complete FPM exploit for the out-of-memory flaw has not been demonstrated. That qualification is not evidence that FPM is immune. Node.js also issued security fixes on Oct. 21, but the supplied material does not list its affected versions or the ten individual vulnerabilities.

Checking Live PHP and Node.js Deployments

A security release only reduces exposure when the fixed code is installed and active. Servers can continue running an older process after a package update until services are restarted, and a website owner may not know whether a hosting provider has applied a fix. Administrators should check the runtime that handles production requests, not rely only on a package manager’s update message.

The PHP advisory’s account of execution before application code runs means an application-level filter or plugin should not be treated as a reliable barrier. The possible access is bounded by the web worker’s permissions, but that account can hold sensitive credentials and files. This makes patch status relevant to small businesses and site operators as well as teams running larger services. Node.js deployments also need a version check because its release covered ten vulnerabilities; the supplied source does not establish that those issues have the same severity or impact as PHP2Shell.

PHP Branches and Vendor Packages

PHP announced the planned security release on Oct. 20, saying it would address two critical vulnerabilities rated 9.2 under CVSS v4.0 and was scheduled for 14:00 UTC the next day. The Oct. 21 advisory and fixed releases followed. The source article describes this as a practical follow-up to an earlier report about PHP2Shell and Dutch government websites, but the material provided here does not independently detail that outage or establish its scope.

Version numbers can be confusing when software comes from a Linux distribution, hosting company or long-term support provider. A package may include a security patch while retaining a version string that differs from PHP’s upstream release number. The source advises checking vendor notices or changelogs for both CVE identifiers. It also says the volunteer-run remirepo repository would not have updates on release day and advises users to switch to distribution packages or build from source.

PHP 8.2.35 is a fixed release, but the branch is scheduled to reach end of life on Dec. 31, 2026, according to its release note. Administrators choosing that update should account for the branch’s approaching support deadline. The source says older PHP versions, including 7.3 and below, have no official release for these fixes and should be treated as unsupported.

“all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”

— PHP security team, as quoted in the advisory

Package Status and Exploit Scope

The supplied material does not identify which cloud hosting platforms apply these PHP or Node.js fixes automatically, or give a platform-by-platform schedule. Hosting customers should ask their provider whether the relevant runtime has been updated and whether the serving processes have restarted. The source mentions a separate incident at Railway but says the platform has not linked it to either vulnerability; no further incident details are provided here.

The material does not provide Node.js release numbers, the vulnerability identifiers, severity ratings or individual impacts, so their exposure cannot be assessed from this account alone. For PHP, the advisory says a complete FPM exploit for the out-of-memory flaw has not been demonstrated, while also describing FPM as exposed to the stale-state issue. The supplied information does not establish whether attackers have exploited either PHP flaw in the wild.

Confirm Fixes on Production Servers

Administrators should inventory the PHP and Node.js versions serving production traffic, then apply the relevant upstream, distribution or hosting-provider updates. For PHP, check that the installed package contains fixes for CVE-2026-109618 and CVE-2026-109619, even if its version number differs from the upstream release. Confirm that updated processes are running after deployment. For Node.js, consult the Oct. 21 release notice or the package vendor’s advisory to identify the applicable fixed version.

Owners using PHP 8.2 should include a move to a supported branch in their maintenance plans before its stated end-of-life date. Those on older PHP releases should check for vendor backports or upgrade options. The next meaningful confirmation for each operator is a verified production runtime and, where a provider manages updates, a clear statement of what was patched and when.

Key Questions

What are PHP2Shell?

PHP2Shell is the name used for PHP flaws CVE-2026-109618 and CVE-2026-109619. PHP’s advisory rates both Critical, 9.2 under CVSS v4.0, and describes remote code execution risks.

Which PHP releases include the fixes?

The listed fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Vendor packages may include the fixes under different version numbers, so check their security notices or changelogs for both CVE identifiers.

Does PHP-FPM need an update?

Yes. The PHP advisory includes PHP-FPM among configurations serving web requests. It says the stale-state flaw was validated against FPM and that a complete FPM exploit for the other flaw has not been demonstrated; that does not establish immunity.

What did the Node.js release fix?

Node.js announced fixes for ten vulnerabilities across supported release lines on Oct. 21, 2026. The supplied material does not list the affected versions or describe the individual vulnerabilities, so consult the Node.js or package-vendor release notice.

How can I tell whether my site is patched?

Check the PHP or Node.js package used by the production service and verify that the vendor update includes the applicable fixes. Confirm the live runtime after deployment and restart services where required; a package update alone may not show what code is currently serving requests.

Source: Thorsten Meyer AI