Security Advisory
Critical PHP & Node.js
remote code execution vulnerabilities
In October 2026, both PHP and Node.js released emergency fixes for critical vulnerabilities that can lead to remote code execution, with working exploits circulating. This page explains what Quant has done and exactly what you need to do.
Published 21 October 2026 · Last updated 23 October 2026
Platform status: protected
- • Quant's Web Application Firewall blocks the known PHP exploit trigger across the whole platform.
- • Our managed base images are patched, and the services we operate have been rebuilt and redeployed.
- • Static sites served by Quant are not exposed — they run no PHP or Node in the request path at all.
- • If you build and deploy your own application, there are steps below to pull the patched runtime.
The vulnerabilities
Two separate runtimes shipped critical fixes within days of each other. Both can lead to unauthenticated remote code execution, and both had public proof-of-concept exploits.
| Advisory | What it affects | Severity |
|---|---|---|
| PHP "php2shell" CVE-2026-109618 / 109619 | PHP core. An unauthenticated attacker can trigger it with a crafted multipart/form-data request to any URL, before application code runs. Affects Drupal, WordPress and any PHP app. | Critical · 9.2 |
| Node.js Brotli CVE-2026-111497 (+ 9 others) | A Brotli-decoder out-of-bounds write, reachable through an outbound fetch() to a malicious server. Any Node.js application that makes outbound requests is exposed. | High |
What Quant has done
- Shipped a platform-wide WAF rule that blocks the PHP exploit trigger at the edge, so traffic is protected immediately rather than after every customer redeploys.
- Patched our managed base images to the fixed PHP and Node.js versions, on both CPU architectures, and rebuilt and redeployed every service we operate.
- Blocked the vulnerable request type on end-of-life PHP 7.4, which will never receive an upstream fix, so the exploit cannot reach it.
What you need to do
If your site is served statically by Quant
Nothing. Your public site is pre-rendered files served from our edge, with no PHP or Node running in the request path, so neither vulnerability has anything to reach. This includes Drupal and WordPress sites we make static, static site generators, and sites on end-of-life runtimes — the old runtime only ever runs on the authoring side, off the public internet.
If you run a PHP application on Quant Cloud
Our WAF already blocks the exploit, but the durable fix is the patched runtime. Rebuild and redeploy your application so it is built on our patched base image (8.2.35 / 8.3.36 / 8.4.27). A redeploy on its own does not rebuild the image.
On PHP 7.4, we block multipart/form-data uploads by default because 7.4 has no fix. Page loads, logins and standard forms keep working; file uploads do not. Plan an upgrade to a supported version.
If you run a Node.js application on Quant Cloud
Rebuild and redeploy so your application is built on our patched Node base (22.23.4 / 24.22.1). Make sure your build pulls a fresh base image rather than reusing a cached layer, or it can rebuild on the old runtime and report success while still vulnerable — in docker/build-push-action, set pull: true.
If you host PHP or Node.js elsewhere
Upgrade to a patched version (see the tables below) as soon as you can — that is the only complete fix. As interim cover for PHP, deny multipart/form-data requests at your web server or CDN before PHP parses them. The mitigations below are the ones we deployed.
Interim mitigations (PHP)
These remove the PHP exploit trigger while a patched runtime rolls out. They are defence in depth, not a replacement for the patch, and they only cost you file uploads while in place.
Block the request at nginx, before PHP-FPM:
# Temporary mitigation for CVE-2026-109618 / 109619. Revert after patching.
if ($content_type ~* "^multipart/form-data") {
return 403;
}Or disable the feature in php.ini (closes the session path):
session.upload_progress.enabled=0Note: the exposure reaches the multipart parser as well, so the ini flag is a partial mitigation. Blocking multipart, or patching, is the reliable fix.
Fixed versions
| PHP | |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
| 7.4 (end of life) | No fix — mitigate and upgrade |
| Node.js | |
|---|---|
| 26.x (Current) | 26.12.1 |
| 24.x (LTS) | 24.22.1 |
| 22.x (LTS) | 22.23.4 |
| 20.x and older (end of life) | No fix — upgrade |
For the background on why the patched runtime took hours to reach production and why serving static changes the exposure, read When the patch diff writes the exploit.
Not sure if you're exposed?
If you are unsure how your site is configured or which runtime version it runs, contact our team and we will check it with you.