Patch PHP and Node.js this week: what broke and who's exposed

PHP and Node.js sit under a huge number of websites and apps, and both patched serious holes on October 21, 2026. If your site, shop or app runs on either, get it updated this week. The rest of this post explains what broke, then what to do if you think someone already got in.

If an attacker uses one of these holes, they get to run commands on your web server as the account your website runs under. From there they can read whatever that account can read: customer records in the database, passwords stored in configuration files, payment or API keys. They can also change your site, plant malware for your visitors, or use the server to move deeper into your network.

Exploitation reports for the PHP bugs were mixed in the first two days. Rapid7 says it hasn't seen exploitation in the wild but has seen reports of attempts, and expects real attacks. Tanium cites watchTowr's honeypots and Cloudflare's CTO reporting early attacks. Rapid7 and SANS both say the public proofs of concept look unreliable. Rapid7 says each one works only on a particular mix of OS, PHP version and web server. When we checked CISA's Known Exploited Vulnerabilities catalog on October 23, neither PHP CVE was listed.

Unreliable exploits still deserve a fast patch. They usually improve fast, and an attacker only needs one setup that matches yours. Rapid7 says to treat this as an emergency update outside the normal patch cycle, and we'd do the same.

Both projects released fixed versions the same day; the table below shows the one for your line. The fixes close the exact memory mistakes these attacks use. We'd patch rather than spend the week debating workarounds, because none of them removes the risk.

PHP's two bugs are the urgent ones. Both are reachable without logging in, and the PHP project says there are no complete mitigations: updating is the only safe choice. The advisory's documented routes to the OOM bug run through multipart form parsing. PHP's advisory describes several ways to force an allocation failure there, and once that happens, request shutdown reads memory that was never fully set up.

Which server setup you run decides how worried you should be. PHP rates Apache with mod_phpdefinitionThe Apache module that runs PHP inside the web server's own processes. PHP calls it the riskiest setup for these bugs, since the attack can fire before your app code even runs. as the highest risk, because an unauthenticated request can trigger the attack before any application code runs, and the advisory says full RCE was validated over HTTP against mod_php. For the OOM bug, PHP says no complete exploit has been shown on FPM yet. The stale-state bug is different. Its advisory reports a validated session-lifecycle RCE on FPM too, so FPM shops don't get to relax.

The stale-state bug needs two requests that land on the same worker. One leaves state behind and a later one acts on it. On PHP 8.5, fatal error backtraces are the strongest confirmed path. Session upload progress is another, and it's on by default and doesn't need your code to call session_start(). Timeouts and other fatal errors can provide the interruption, so an app that throws a lot of fatal errors gives an attacker more chances.

On the Node side, the Brotli bug is the one we'd worry about first. Brotli is the compression behind the Content-Encoding: br header, and that header is harmless on its own. The risk is a vulnerable Node process decompressing Brotli data that an attacker controls. That could be a compressed request body, a response from someone else's API, or a library that decompresses on your behalf without you noticing. The Node advisory gives no workaround, only the fixed versions.

The three TLS bugs matter wherever Node connects to things by IP address and trusts the certificate check to stop a man in the middle. Service meshes, internal APIs called by IP and health checkers all do this. The snapshot bug is narrower but nasty if it applies: if you build single executable apps or startup snapshots, every copy was handing out the same "random" UUIDs and integers until you rebuild on a fixed version.

Knowing the fixed version is the easy bit. Getting it onto every machine is where patch week usually slips: a laptop on nvm, a container built from a tag nobody re-pulled, a Next.js app whose Node version sits in a hosting setting. Then there's the Apache box where the PHP command line reports one version and the web server runs another. Below is how each setup gets the fix, and how you prove it landed.

One thing trips up a lot of patch checks on Debian and Ubuntu. The distributions backport the fix into the PHP version they already ship, so the upstream number often stays put. Ubuntu 24.04 is fixed in 8.3.6-0ubuntu0.24.04.13. The upstream part of that version is still 8.3.6, well below PHP's own 8.3.36, so judge these hosts by the full package version.

# Node: the version this shell runs
$ node -v
# Debian or Ubuntu PHP: the package versions, not just php -v
$ dpkg-query -W 'php8.*' 'libapache2-mod-php*'
# FPM serves the pages, so check its binary too
$ php-fpm -v
# On Debian the binary has the version in its name, e.g. php-fpm8.2
# Containers: ask the one that's running. The image tag can be out of date
$ docker exec <container> node -v
$ docker exec <container> php -v

Next.js isn't a runtime of its own. Its server code runs on Node, the default runtime it uses to render your app. The Edge runtime, with fewer APIs, is what Proxy uses. So the Node fix applies to every Next.js app you build and serve yourself. Next.js's docs set the minimum at Node 20.9, and Node 20 is end of life with no fix, so a build that still passes on 20 isn't safe.

Node's advisory names the trigger: Brotli data that an application decompresses with node:zlib. The decoder ships inside Node, so every library that decompresses through node:zlib uses the runtime's copy. Updating Node fixes all of those at once. What's worth knowing is where your app decompresses data it didn't create, because those paths are exposed until the update is everywhere.

On a classic Linux, Apache, MySQL and PHP box, the PHP that serves your pages is a different binary from the one you run in a terminal. Ubuntu's notice lists libapache2-mod-php8.x, php8.x-fpm, php8.x-cli and php8.x-cgi as separate packages. php -v reports the CLI, and it says (cli) right in its first line. Update every package, restart the service that holds PHP in memory, and then check that service.

Patching once is the easy week. The harder part is knowing, a month from now, which images and hosts still carry a vulnerable runtime. Open-source scanners, plus GitHub's Dependabot if your code lives there, can find most of them and feed one dashboard. Know the split before you trust a clean report: some tools check your app's packages, and only some can see the runtime itself.

npm audit sends a description of your project's dependencies to the registry and reports known advisories against them. It doesn't audit the Node binary. composer audit does the same for Composer packages. Composer's separate check-platform-reqs only compares your PHP version with what your packages need, so it won't flag a vulnerable PHP. Both are still worth running in CI, since app dependencies get patched on their own schedule.

Setting this up across many pipelines is mostly plumbing, and that's work our DevSecOps practice does: SBOMs, dependency and container scanning, and signed builds. If your containers run on OpenShift, the OpenShift page covers the platform and you can bring in OpenShift engineers. Or start with an assessment of where your runtimes stand today.

Both advisories describe the attacker landing as the web worker account. That's the part an identity team can do something about. If the account behind your PHP or Node app can read every database, every secret in the vault and half the cloud subscription, a single runtime bug turns into a much bigger incident. If it can only reach what that one app needs, the same bug stays a contained, ugly afternoon.

Patching closes these particular holes. Least privilege is what still protects you from the next one you haven't heard about yet, so we'd do both in the same change window. Here's the order we'd work in.

For the log search, the most useful public description is SANS's write-up of the proof of concept. Tanium also suggests looking for worker crashes and malformed multipart uploads in web server and PHP-FPM logs. WAF rules from Cloudflare and others help while you patch, but they don't remove the bug.

We work on the identity side of this. That usually means scoping the service accounts and workload identities apps run as, moving secrets into a vault and putting admin rights behind just-in-timedefinitionAdmin rights that exist only when someone asks for them, for a set time, usually with approval and logging, instead of sitting on the account all the time. access. If you want to know what a compromised app server in your estate could actually reach, our privileged access management page explains how we work. The CyberArk and HashiCorp Vault pages cover the platforms, you can bring in PAM engineers, or start with an assessment.