TL;DR

Buying for a business?Offer from Amazon

Get business pricing on tech for your team

• 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 October 21, 2026, for two critical remote code execution vulnerabilities known as PHP2Shell. Node.js also announced fixes for 10 vulnerabilities that day, but the supplied source does not identify the affected Node.js versions or fixes. Administrators should verify the code and packages actually serving their systems, then follow the relevant vendor advisories.

PHP released fixes on October 21, 2026, for two critical vulnerabilities that can allow unauthenticated remote code execution in web-serving PHP installations. Node.js also issued fixes for 10 vulnerabilities that day, making it necessary for administrators to check both runtimes and confirm that patched packages are actually deployed.

The PHP flaws are CVE-2026-109618 and CVE-2026-109619, collectively referred to in the source material as PHP2Shell. The PHP project’s October 20 pre-announcement said both were rated CVSS v4.0 9.2 and scheduled a release for 14:00 UTC the following day. The advisories describe one flaw involving out-of-memory corruption during request cleanup and another involving stale global state that can remain after memory is freed.

The listed 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 supplied advisory says PHP 8.1 and older no longer receive routine project updates; it notes minimal source backports for some older branches, while advising other users to obtain a fixed package from a distribution or long-term support vendor, or upgrade. Package versions can differ from upstream release numbers, so administrators should check vendor notices for both CVE identifiers.

The PHP advisory says the affected scope includes web-facing PHP installations using PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The supplied material says an unauthenticated exploit was demonstrated against Apache mod_php before application code runs. It also says the stale-state flaw was validated against mod_php and FPM, while no complete FPM exploit had been demonstrated for the out-of-memory flaw. That qualification does not establish that FPM is unaffected.

For Node.js, the source reports 10 vulnerabilities fixed across supported release lines, but gives no CVE identifiers, affected versions, severity ratings or patched version numbers. Those details cannot be confirmed from the supplied material. The separate Railway hosting-platform incident mentioned in the source is not linked there to PHP2Shell or the Node.js release.

Check the Runtime Serving Requests

A patch matters only when it is present in the runtime handling production traffic. A server may still be exposed if an administrator updated a development environment, a package on the host that a container does not use, or one machine in a cluster while other instances remain on older builds. Checking the deployed package and the process serving requests helps identify those gaps.

The PHP advisory describes possible code execution under the web worker’s account. That is not the same as automatic root access, but that account may be able to read site files, configuration and database credentials available to the application. The stated lack of a login or user interaction requirement makes prompt verification relevant to site owners, hosting customers and teams responsible for shared web infrastructure.

Node.js systems need a separate review. The source confirms a security release but does not supply enough detail to determine which installations are affected or what version resolves each issue. Operators should use the official Node.js security release information and their distribution or hosting provider’s notices rather than infer a safe version from the count of vulnerabilities.

The October 21 Runtime Releases

The PHP project announced the planned security release on October 20, then published the fixes on October 21. The source places the follow-up article on October 22 and describes the PHP fixes as a practical response to a previous report about PHP2Shell and Dutch government websites. The supplied material does not independently establish the details or scope of that earlier outage, so it should not be treated here as evidence that a particular site was compromised through these flaws.

PHP 8.2.35 is listed as fixed, but the source says PHP 8.2 is scheduled to reach end of life on December 31, 2026. Administrators using that branch therefore face both an immediate patch task and a near-term upgrade decision. PHP 8.1 and older have no official release listed in the supplied table; the source says users should rely on a vendor or long-term support package containing the fixes, build a supported backport where appropriate, or move to a maintained branch.

The source also warns that the volunteer-run remirepo repository would not have updates on release day and says its users were urged to switch to distribution packages or build from source. That is a dated report about availability on October 21; administrators should check current repository and vendor status before changing package sources.

“two critical vulnerabilities, both rated CVSS v4.0 9.2”

— PHP project, October 20 pre-announcement

Vendor Packages and Node.js Details

The supplied source does not identify the fixed Node.js versions, CVE numbers, severity levels or individual affected components. It also does not provide enough information to assess whether a specific Node.js installation is exposed. Those details should be confirmed against Node.js’s release announcements and the package or hosting provider used in production.

For PHP, a version string alone may not settle whether a system is fixed because distributors and long-term support vendors can backport patches without adopting the upstream release number. The source advises checking vendor changelogs for both CVE IDs. It does not provide a complete system-by-system inventory, evidence of exploitation across the listed PHP configurations, or confirmation that any particular organization has installed the fixes.

The article material mentions a separate Railway security incident but provides no incident details and says it has not been linked to either runtime vulnerability. Its cause, scope and relationship to affected customer systems remain unclear from the supplied information.

Verify Deployments and Track Advisories

Administrators should identify each production PHP and Node.js runtime, including instances running in containers or behind a hosting provider, and compare the deployed package with the applicable security notice. For PHP, check for CVE-2026-109618 and CVE-2026-109619 in the distribution or vendor changelog, then confirm that the updated runtime is the one serving requests. Restart or redeploy services when the vendor’s instructions require it, and verify the running version afterward.

Teams should consult Node.js’s official security release details and their package provider’s guidance to identify the appropriate fixed release. If immediate PHP updating is not possible, operators can ask their vendor about a patched package and consider a supported upgrade path. The supplied source does not describe a temporary mitigation that can be relied on as a substitute for applying the fixes.

Follow-up reporting should establish which Node.js versions were affected, how vendors map backported PHP fixes to package versions, and whether the separate Railway incident receives a public technical explanation. Until then, each organization’s exposure depends on its actual runtime, package source and deployment state.

Key Questions

What are the PHP2Shell vulnerabilities?

They are CVE-2026-109618 and CVE-2026-109619, two PHP flaws that the supplied advisories rate Critical at CVSS v4.0 9.2. The reported impact is unauthenticated remote code execution with the permissions of the web worker account.

Which PHP releases are listed as fixed?

The source lists PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A distribution or long-term support package may carry the fixes under a different version number, so check its advisory or changelog for both CVE identifiers.

Does PHP-FPM avoid the risk?

No such conclusion is supported by the source. It says the stale-state flaw was validated against PHP-FPM and mod_php. For the out-of-memory flaw, it says no complete FPM exploit had been demonstrated; that is not proof that FPM is immune.

What did the Node.js security release fix?

The supplied material says Node.js fixed 10 vulnerabilities across its supported release lines on October 21, 2026. It does not list the CVEs or fixed versions, so administrators should consult the official Node.js release information and their package provider.

Can I rely on the version number shown by my host?

Not by itself. Vendors can backport security fixes while keeping a package’s version number different from the upstream release. Check the vendor’s security notice or changelog for confirmation that both PHP fixes are included, and verify the runtime actually serving production traffic.

Source: Thorsten Meyer AI