Back to blog
Security

PHP2Shell and Node2Shell: what to do now

On Wednesday 21 October 2026, PHP and Node.js both released an urgent security update. The flaws quickly got names: PHP2Shell and Node2Shell. Between them, these two platforms run a large part of the web, from WordPress and Laravel sites to JavaScript web applications and APIs. Here is what happened, who is at risk and what you can do today.

PHP2Shell: two flaws in PHP itself

PHP2Shell is the name for two critical flaws in the core of PHP, CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on the server remotely.

  • CVE-2026-109618: if PHP runs out of memory while it is still setting up a request, the clean-up afterwards can treat half-built data as valid.
  • CVE-2026-109619: internal request data can survive after its memory has been freed. A later request handled by the same worker can then use that stale data.

According to the PHP project, every PHP installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest with mod_php, where an attack has been demonstrated with an unauthenticated request, before a single line of your application runs.

The fix is to update. These versions contain it:

PHP branchFixed version
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35

PHP 8.1 and older no longer get official updates. The PHP project did publish patches for 7.4, 8.0 and 8.1, and some distributions and long-term support vendors offer patched builds. Note too that PHP 8.2 stops receiving security fixes after 31 December 2026.

If you can’t update today, a few settings reduce the risk, although according to the PHP project they don’t make an installation safe. Set session.upload_progress.enabled=0 in php.ini or the FPM pool and restart every worker; ini_set() or a .user.ini is not enough. Keep post_max_size low and limit the size and complexity of requests at your web server or proxy. After a related advisory on 23 October (CVE-2026-115560), the PHP project recommends keeping upload progress disabled until the next bugfix release.

Sources disagree on whether the flaws are being exploited. Details leaked before the official release, and Amazon reported an exploit attempt on its honeypots. The director of the PHP Foundation, on the other hand, said there was no evidence of working exploits. Don’t wait for that question to be settled: once you’ve updated, the answer no longer matters.

Node2Shell: a flaw in Brotli decompression

Node2Shell is CVE-2026-111497, a flaw in the Brotli decoder bundled with Node.js. Malformed compressed input can write past the end of an internal buffer. According to Node.js, an attacker who can supply Brotli data that your application decompresses with node:zlib can corrupt the process memory, which can lead to a crash, memory disclosure or code execution.

So the risk is in applications that decompress data from outside: for example an API that accepts requests with Content-Encoding: br, a proxy or gateway, or software that processes uploaded files.

Node.js lineFixed version
26.x26.12.1
24.x24.22.1
22.x22.23.4
20.x and 25.xno fix: end of life

Two things to keep in mind:

  • Updating an npm package doesn’t help. The vulnerable code is part of Node.js itself. Only a new Node.js version fixes it.
  • The problem goes deeper than Node.js. The root cause is in Google’s Brotli library (versions 1.0.3 through 1.2.0). The Python Brotli package is affected too, and according to researchers at Aikido, so is the Bun runtime.

Node.js lists no workaround. If you can’t update straight away, rejecting requests with Content-Encoding: br at your reverse proxy or load balancer reduces the risk. The same release also fixes other serious issues, including in TLS certificate checks (CVE-2026-106069, CVE-2026-105483) and DNS lookups (CVE-2026-105482), so updating pays off either way.

What to do today

  • Map where PHP and Node.js run: servers, containers, hosting plans, internal tools and build pipelines.
  • Check the version where the software actually runs, with php -v or node -v inside the container, not on your own laptop.
  • Update to a fixed version. For containers, that means rebuilding the image on an updated base and redeploying it.
  • Plan an upgrade for everything that's out of support: PHP 8.1 and older, Node.js 20 and 25.
  • If you can't update right away, apply the interim measures above, and watch your logs for crashing workers and unusual requests.
  • If your site is hosted or managed by a partner, ask them to confirm the exact version numbers.

How Skedia helps with a security audit

We did the exercise on ourselves first. Within a day we had checked every container we manage, and the sites we build and host all run an updated Node.js release. We offer the same approach as a security audit:

  • Inventory: which software, versions and dependencies are running, and what no longer gets updates.
  • Update plan: in which order to update and redeploy, without taking your site or application down.
  • Configuration: safe settings for PHP, Node.js and your web server, with security headers and a Content Security Policy.
  • Code: a critical look at the places where outside input comes in, such as uploads, forms and file decompression.
  • Follow-up: error reporting and monitoring, so you see a problem before your customers do.
  • Report: a clear write-up in plain language, with priorities and concrete next steps.

Want to be sure your website or application isn’t exposed to PHP2Shell, Node2Shell or the next flaw? Get in touch for an audit.

Sources

Ready for the next step?

Skedia would love to hear from you.

Discuss a project