Node2Shell CVE-2026-111497: patching Brotli in PDF pipelines

Node2Shell, CVE-2026-111497, is a Brotli decoder vulnerability that can turn decompression of untrusted data into memory corruption and possible code execution. Node.js shipped fixes on October 21, 2026. New Zealand's NCSC confirmed active exploitation on October 29. For a PDF service, the first question is which process decodes compressed input, including HTTP responses fetched before the PDF is rendered.

Sources checked on November 2, 2026. The versions below identify the October fix; use a current supported release that includes it.

What happened in the Node2Shell disclosure?

The flaw affects the native Brotli decoder bundled with Node.js. An invalid block-switch condition lets streaming input overrun an internal buffer. Node.js rates the issue high severity and describes possible crashes, memory disclosure, and remote code execution in its October security advisory.

The incident subsequently expanded beyond Node.js. The Canadian Cyber Centre's October 28 alert describes affected Brotli integrations across several ecosystems and records CISA's October 27 addition to the Known Exploited Vulnerabilities catalog. The names Node2Shell, Broccoli2Shell, and HTTP2Shell refer to coverage of the same CVE, rather than three independent Node.js vulnerabilities.

For incident tracking, use the CVE identifier as the key. Store the affected component, the deployed artifact, and its replacement together. A ticket called "upgrade Node" can miss a second decoder in a Python worker or a separate image used by a scheduled export job.

Which Node.js versions should you deploy?

The initial fixed releases are Node.js 22.23.4, 24.22.1, and 26.12.1. For Node.js 24, account for the follow-up 24.22.2 release instead of treating the first security build as the final deployment target.

AWS's bulletin explains the Node.js 24.22.1 regression, the 24.22.2 follow-up, and the absence of updates for deprecated Lambda runtimes. A vendor may backport security fixes, so record the vendor build identifier when the version string alone does not describe patch status.

Check the running worker, rather than only a developer terminal:

node -p 'JSON.stringify({node: process.version, brotli: process.versions.brotli, executable: process.execPath})'

Run the command inside the deployed container or equivalent runtime. The Brotli version is useful inventory data; it is not a universal pass/fail rule for backported fixes. Attach the output and the vendor advisory to the deployment record.

How can a PDF pipeline reach a Brotli decoder?

A PDF application can process untrusted compressed data without accepting an uploaded PDF. Our recommended review starts at the HTTP boundary: list every place where an attacker can influence bytes that a server later decompresses.

Treat these rows as an investigation checklist, not a claim that every listed component is exploitable. A worker that never invokes a vulnerable decoder has a different exposure from one that decompresses arbitrary remote responses.

Separate the output format from transport compression. Creating a smaller PDF, for example with our PDF compression tool, is not the same operation as decoding Brotli HTTP data. Likewise, a patched Node.js process says nothing about whether its Chromium binary is current. Our HTML-to-PDF threat model covers that separate layer.

How do you verify that the fix reached production?

Rebuild and replace each affected artifact, then inspect a process launched from the replacement. Our recommended acceptance record is the runtime version, image digest or provider runtime identifier, deployment time, and a successful representative PDF job.

For a container deployment, update the base image deliberately and build with a fresh base-image pull. Replace existing workers, including long-lived queue consumers. Test a normal HTML-to-PDF conversion, a template with remote assets, and the batch path your customers use. Use controlled fixtures for these checks.

For Lambda, distinguish deployment types. AWS says container functions need an image rebuild and redeployment; managed ZIP runtimes have their own rollout phases and update-mode behavior. Follow the AWS remediation instructions for the exact runtime instead of assuming an npm install updates the provider runtime.

If you operate both an application server and a renderer, assign an owner to each. The same separation applies when you use PDF4.dev: hosted rendering changes who operates the PDF engine, while the application calling PDF4.dev still needs its own runtime updates. Our Docker PDF generation guide explains the deployment boundary, and the Next.js PDF generation guide covers where rendering can sit in a framework application.