node2shell Auditor

The node2shell auditor runs the node2shell scanner against the audited URL to tell whether its Node.js stack is affected by CVE-2026-111497, a flaw in applications that decompress an attacker-supplied Brotli request body on the route handler. A crafted body expands far beyond its compressed size, so one request can exhaust memory and crash the process. This is an active probe: it streams one 23,068,764-byte Brotli body. For that reason it never runs from an anonymous Quick Audit (preview_enabled is off) and the platform only runs it against domain-verified targets. The probe uses Expect: 100-continue, so a proxy can reject its advertised size before the body is uploaded, and it does not execute a command.

​

How it works

1. Control requests — sends five one-byte POSTs that vary the Brotli encoding and content type (malformed Brotli with no content type, valid empty Brotli as JSON, malformed Brotli as JSON, an unsupported encoding) to learn how the endpoint answers valid route traffic versus malformed input.
2. Response classes — only continues when the controls establish a distinct route-response class and malformed-Brotli class; otherwise it reports no signal without ever uploading the probe.
3. Probe — streams the 23,068,764-byte Brotli body as application/json with Expect: 100-continue, then repeats the valid control to confirm the endpoint stayed stable.
4. Verdict — the host is vulnerable only when the full probe reaches the route-response class, the malformed class is distinct, and the final control still matches the route class. The scanner returns one verdict (VULNERABLE, NO SIGNAL, INCONCLUSIVE or ERROR), which this auditor maps to a single result.

​

Preferences

​

What it checks

• Whether the route handler decompresses an attacker-controlled Brotli request body without limit (the core of CVE-2026-111497), by comparing the 23 MB probe’s response class against the learned route and malformed-Brotli classes.
• It inspects only the audited page for a block (HTTP 403 / 429 / Cloudflare challenge); the probe and controls are part of the audited request, not separate paths.

​

What it audits

Every row maps to one checkRule* method and one CheckCode. CheckCode suffixes use status ranges: 100 information, 200–299 success, 300–399 warning, 400–499 fail, 500–599 error.

​

Output documentation

​

Risks and considerations

​

This probe uploads a 23 MB body

• On a vulnerable server the probe is the condition that exhausts the process; on any server it uploads 23 MB. Only run this against sites you own or are authorized to test — which is why it is gated on domain verification and is off for anonymous previews. The Expect: 100-continue header lets a proxy reject the size before the body is sent.

​

A clean result is not a guarantee

• NO SIGNAL means the probe did not cross into the route response class. It is reported as a pass, but it is not proof of safety: confirm the affected component is patched.
• INCONCLUSIVE means a WAF, proxy or server error stopped the scan from reaching a verdict. The server may still be exposed — re-run, or test the Node.js origin directly.

​

Verify findings with a human

• This auditor wraps Assetnote’s node2shell-scanner and infers the verdict from the server’s responses, so a result can be wrong in either direction: a WAF, proxy or load balancer can absorb the probe and look like a pass, and an unrelated response change can look like a crossing. Before you act on a FAIL — or rely on a SUCCESS — have a person confirm it against the host (check the running component versions and the server logs for the probe requests).

​

Why it matters

• The flaw lets an unauthenticated request make the Node.js process decompress an attacker-controlled Brotli body, so a crafted upload can exhaust memory and take a site down (denial of service).
• The memory corruption behind the crash raises the risk of worse outcomes than a crash, so patching promptly matters.