Node2Shell: check Node.js patches beyond your firewall

Commerce teams running Node.js apps or custom backends should check the runtime actually deployed in production after fresh Vercel and AWS guidance on CVE-2026-111497, the Brotli decoder vulnerability known as Node2Shell. A provider’s firewall protection is not a substitute for updating the affected runtime.

The Node.js security release of 21 October fixes a flaw that can cause crashes, expose process memory or permit code execution when an application decompresses attacker-controlled Brotli data. The advisory identifies the 22.x, 24.x and 26.x release lines. This is a runtime issue; it is not evidence that Shopify’s hosted checkout or every Shopify app has been compromised.

Vercel: redeploy and check older runtimes

Vercel’s 29 October advisory says all new deployments have used patched Node.js versions since 28 October at 11am Pacific time. Existing projects should be redeployed. Projects still using Node.js 20 need to move to 22.x or 24.x and redeploy; Vercel manages patch versions for those supported runtimes.

The firewall covers traffic passing through Vercel’s network. It does not cover malicious compressed responses fetched from another server. External backends, self-hosted applications, custom container images and CI environments need their own review and updates.

AWS: distinguish managed runtimes from container images

In its 30 October bulletin update, AWS says the Lambda managed service is unaffected, while Node.js and .NET runtimes are affected. Updated Node.js container base images are available: teams using containers must rebuild and redeploy them.

AWS also flags a regression in Node.js 24.22.1, fixed in 24.22.2. It reports the first phase of that newer runtime rollout complete, with the second expected on 31 October. That expectation is not confirmation that a particular function has received it. Check the actual runtime and update mode against the latest bulletin.

A useful request to your developer

Ask for a short deployment inventory covering the app server, workers, integrations and build environments: who operates each one, which runtime is running, and when its patched deployment was verified. For a third-party app, ask its vendor about the affected infrastructure rather than assuming you can patch it from your store admin.

After an update, test the commerce operations that depend on that service, such as order processing and synchronisation. Keep the deployed version and test result with the release record. The objective is evidence that the running service received the fix, not merely that a dependency file or local development machine was updated.