Node.js security release fixes ten CVEs as PHP patches two

On Wednesday, October 21, 2026, PHP and Node.js both published emergency security updates, each addressing vulnerabilities that end in remote code execution — the class of bug where an attacker runs their own code on the server rather than only reading data or crashing a process.

PHP's developers released fixes for CVE-2026-109618 and CVE-2026-109619, two critical flaws in the core interpreter rated 9.2 under CVSS v4.0, the standard severity scoring scale. Both allow an unauthenticated attacker to run code remotely on an affected web server, according to the University of Washington IT service status page. The same day, the Node.js security release covered ten CVEs across the 22.x, 24.x and 26.x lines, four of them rated High.

The patched Node.js builds are v22.23.4, v24.22.1 and v26.12.1. The university advisory states that details of the two PHP flaws became public before the fixes were released, which is why it treats patching as urgent rather than routine.

Two advisories with very different paper trails

The Node.js document is a primary source: it names each CVE, its severity and the release lines affected, and credits the people who reported and fixed every issue. The PHP side is harder to reconstruct from the material available. The 9.2 score and the remote-code-execution impact come solely from the University of Washington IT page; Spanish-language coverage of the release confirms only that the two critical CVEs were published on October 21 (Irontec). Neither describes the underlying mechanism, and the material reviewed here gives neither the affected PHP version range nor the build numbers that contain the fixes.

That asymmetry shapes how the two releases get prioritized. For Node.js, a risk assessment can be drafted from the advisory alone. For PHP, the severity and the impact class are documented, but the technical detail sits in the project's own advisory, which engineers will have to read directly.

The Brotli write behind the highest rating

The most serious Node.js issue described in the sources is CVE-2026-111497: an out-of-bounds write in the Brotli decoder bundled with the runtime, which the advisory says permits remote code execution and which affects 26.x, 24.x and 22.x.

An out-of-bounds write is a memory-safety bug: the program writes data past the end of a buffer it allocated, and attacker-crafted input can corrupt adjacent memory and redirect execution. Brotli is the compression algorithm behind the br HTTP content encoding, so the decoder processes data arriving from the network. TuxCare's timeline adds a point with practical consequences: a process does not have to call Brotli directly to be exposed, because the decoder sits inside the runtime's HTTP handling.

The Node.js advisory credits OpenAI Codex Security — Khai Tran and Sylvie Mayer — with reporting the flaw, and contributors mcollina and aduh95 with the fix. TuxCare reports two further details that the primary advisory does not contain: the confirmation of the Brotli fix was incorporated into the google/brotli repository in February 2026 without an accompanying security release, and Antoine du Hamel posted a pre-alert at the highest severity level, "High", to the oss-security mailing list on October 14, a week before patched builds appeared. Both are single-source claims and should be read as such.

Four High ratings, one of them described

The Node.js security release fixes ten CVEs, four of them High. Only one of those four — CVE-2026-111497 — is described in the sources reviewed; Devin's write-up also names CVE-2026-105482 among the High-rated fixes without saying what it does. The CVEs documented in the material reviewed are:

CVE	What the advisory describes	Severity	Lines affected
CVE-2026-111497	Out-of-bounds write in the bundled Brotli decoder, remote code execution	High	26.x, 24.x, 22.x
CVE-2026-105481	Keep-alive socket processes a response written before the request was sent	Medium	26.x, 24.x, 22.x
CVE-2026-106072	Improper certificate validation for non-canonical IPv4 hostnames lets DNS SANs authenticate IP endpoints	Medium	Not stated in the excerpt reviewed
CVE-2026-106071	Permission Model filesystem over-grant via wildcard radix lookup	Low	26.x
CVE-2026-106073	Permission Model bypass with fs.realpathSync	Low	26.x, 24.x, 22.x

The certificate-validation entry deserves more attention than its medium rating suggests. A SAN — subject alternative name — is the field of a TLS certificate that lists the hostnames and IP addresses the certificate is valid for. A flaw that lets a certificate issued for a DNS name authenticate an IP endpoint weakens transport identity checks. That is a different kind of failure from a memory bug: it does not crash anything, it quietly changes who is trusted to be on the other end of a connection.

The branches that will never receive a patch

The release covers the three lines the project currently supports. End-of-life Node.js versions are not patched upstream and remain affected, as easyDNS's customer advisory states, with updating to the new releases as the recommended path. For anything older than 22.x, that leaves migration or a third-party support arrangement; the sources reviewed here do not describe a supported in-place option.

Restarting is part of the fix, not an optional afterthought: the documented PHP mitigation requires restarting every worker once the setting changes, per Devin — a step that reflects how long-lived worker processes keep running code already loaded into memory.

Why the version bump is the small part of the job

Finding every place the runtime exists is the harder half. Devin's remediation write-up makes the point directly: PHP and Node.js binaries are embedded in container images, OS packages, CI pipelines and infrastructure configuration across many repositories, so each affected deployment has to be identified, updated, tested and deployed rather than edited in a manifest. Applications on unsupported versions may also need compatibility work before they can move.

The blind spots follow from that list: base images inherited by dozens of services, CI runners pinned to a fixed tag, build stages that never reach production but hold credentials and network access. None of these necessarily appear in a dependency manifest, and any of them can carry an affected interpreter. Whether a given estate has such images is something only its own inventory can answer; the sources reviewed here offer no estimate of how common the problem is.

A related caveat: GitLab and Linux appear only in the headline of one Spanish-language roundup of the week's vulnerabilities, with no detail on what those issues consist of or whether they relate to these releases, so they are not treated here as part of the same event.

What the exploit evidence actually shows

TuxCare reports that on October 22, a public proof of concept achieved code execution only against a deliberately weakened build of the software — a demonstration that says little about whether shipped binaries are exploitable. The same source notes that Brotli released versions 1.2.1, 1.1.1 and 1.0.10 on October 21, and that Vercel deployed WAF rules for inbound traffic. No source reviewed for this article confirms exploitation in the wild; the absence of reporting is not proof of absence.

If the PHP upgrade cannot happen this week

Devin documents interim measures for teams that cannot upgrade immediately: set session.upload_progress.enabled=0 in php.ini or the FPM pool and restart every worker, and cap request body size and multipart part counts at the proxy layer. One counterintuitive detail belongs in every change ticket: RLIMIT_AS and RLIMIT_DATA should not be used as a stopgap, because they trigger the vulnerable code path.

These measures contain exposure. They do not remove the bug, and they buy time only for as long as the patched build takes to clear testing.

The advisories close with version numbers. What stays open for every organization running these runtimes is a question only its own inventory can answer: how many PHP and Node.js binaries are actually in production, and who is responsible for the ones no team remembers installing.