Date: 10/25/2026

Crisis Exercise

Two flaws in one week: your next crisis exercise arrived on its own

PHP2Shell and right behind it Node2Shell (CVE-2026-111497): two critical vulnerabilities on one day were, in practice, a crisis exercise. On weighing information, taking the decision, what a firewall does and does not do, and how to rehearse it, patching is briefly at the end.

TL;DR

In one week two critical vulnerabilities went public: two in PHP (CVE-2026-109618 and CVE-2026-109619) and one in Node.js's Brotli decompression (CVE-2026-111497, "Node2Shell"), on the same day. That was, in practice, a crisis exercise nobody scheduled. This piece is not about patching, that is briefly at the end, but about the two skills such a week tests: weighing information and taking a decision, both under pressure, and both something you can rehearse in advance.

Two critical flaws in one week

I described the PHP vulnerabilities of 21 October last week: two critical flaws with public exploit code, and a decision no runbook covers. On that same day Node.js also shipped a security release, with CVE-2026-111497 in the Brotli decompression that Node.js bundles. In the worst case an attacker can run code remotely, without logging in.

On severity: Google, as CVE Numbering Authority, assigns a CVSS score of 9.2 (critical); Node.js itself keeps "High". I name that number with who assigned it. That is not nitpicking, it is exactly the information you need in a crisis, which the next section is about.

The first crisis skill is weighing information, not patching

On the day itself, patching is not the problem; it takes care of itself once the packages exist. The problem is what you believe, and what you decide and communicate on that basis, while the information is still moving.

You saw that live this week. A severity score of 9.2 circulated for PHP without saying who assigned it. It was said that all PHP from version 5 onwards was vulnerable, while the sources wrote "presumably" and "possibly". And the picture of active exploitation shifted by the day. Base your decision, or worse, your customer notice, on the boldest rumour, and you get it back a week later.

The skill is telling apart what an authoritative source confirms and what someone made of it. Practically: designate in advance who is the "source of truth" during an incident, and the few places you check, this week that was the Node.js release and the NCSC, not the timeline on social media.

The pattern that matters: they come one after another

Almost every crisis runbook assumes a single incident. One alert, one team, one timeline that begins and ends. This week was different: a second critical flaw that arrived while the first was still running, in a different technology, with partly the same people.

That tests something a single incident never does: whether you can do it a second time in a row, with a team that is already tired and attention already split. That is where organisations get stuck, not on the technology.

Does a firewall or CDN protect you against this?

A fair question, and often asked this week. The honest answer is: partly, and not in the way you hope.

A WAF, CDN or tunnel in front of your site mainly dampens traffic coming in, and so buys you response time. It does not close the chance.
What your servers fetch outbound themselves does not run through that firewall. That direction is the quiet risk with Node2Shell.
And most of all: a shielded service still runs a vulnerable runtime. The firewall does not replace patching.

Being behind a WAF is therefore good news for your response time and bad news if it is your only answer. It gives you room to act in a controlled way, exactly the room you use in the exercise below.

Three things to check now

Does your authority hold up on repetition? Set who may decide to take a service offline, and at what threshold, and whether that also covers the second decision the same day. One name with a deputy behind it, not a role.
Is the handover arranged between incidents, not only between shifts? A crisis lasts longer than a working day, and with two at once whatever is not written down disappears. We added that handover step to the five of BOBOC, worked out in Crisis in practice.
Do you know where you run PHP and Node? You cannot decide about what you do not know you have. An inventory you make during the incident is not one.

And the uncomfortable one: part of these decisions your host or supplier takes for you. That is depending on a supplier you do not control. The question in advance is whether you know it is so, and how long you can hold out.

This is your next exercise

You do not have to invent this scenario, it presented itself this week. And it is the simplest and most honest crisis scenario there is: no attack, no ransom, no evidence of a break-in. Just a critical vulnerability with public exploit code, a second one right behind it, and the question of what you do.

Precisely because there is no attacker in it, it exposes where things really stall faster than any ransomware drill: who may decide, on what information, and what you tell your customers and from what moment. Play it as a one-hour tabletop, with one escalation halfway, the second vulnerability, so the handover and the split attention come up too.

If you want a guided form for it, with reporting that is defensible at board level, that is what Crisis in practice is about.

Patching, briefly

For completeness, so your technical team does not have to look it up:

Node.js: upgrade to 22.23.4, 24.22.1 or 26.12.1. Older, end-of-life lines get no fix, which is itself the signal to move off them.
PHP: upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
Cannot patch yet? Reject crafted traffic at the edge as a stopgap, then rebuild your environment and verify the versions again.

The details for those running Brotli, Bun or Python themselves are at the source: Node.js, Aikido and the NCSC.

Frequently asked questions

We do not run PHP. Are we done?

For PHP2Shell: yes. But this week's lesson is not about PHP or Node, it is about how you act when the second crisis arrives before the first is done. That scenario reaches you whatever technology you run.

Has Node2Shell been exploited yet?

A proof of concept has been published and there is no confirmed exploitation in the wild at the time of writing. A reason to act quickly, not a reason to wait until there is.

What is the first thing we should do now?

Establish where you run it and who may decide, in that order. The patch follows by itself; the overview, the information triage and the authority are what you lack under pressure.