Node2Shell Is Being Exploited. Google Patched Server-Side GTM — But Your Tagging Server Won’t Update Itself

What Node2Shell is

Node.js fixed CVE-2026-111497 in its 21 October security release, rated High, in the 22.x, 24.x and 26.x lines. In the project’s words: “An attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory, which can lead to a crash, disclosure of process memory, or remote code execution.”

• Fixed in: Node.js 22.23.4, 24.22.1 and 26.12.1. End-of-life lines (20.x, 23.x, 25.x) get no fix.
• Exploited: CISA added it to its Known Exploited Vulnerabilities catalog on 27 October, with a 10 November deadline for federal agencies.
• How it is reached: according to eSecurity Planet, through Express 5 request parsers that decompress Brotli bodies, fetch() reading Brotli responses from untrusted servers, and direct node:zlib use. Imperva’s published proof of concept “required multiple attempts” on Linux arm64 — not trivial, but not theoretical either.
• Next round: Node.js has announced another security release for 11 November, again with a High-severity issue in all three supported lines. Details are not public yet.

Two weeks ago we wrote about PHP2Shell and why a server bug is a consent problem. Node2Shell is the same story for the JavaScript side of your stack.

Why a Consent Mode site should care

If you run server-side GTM, your tagging server is a Node.js process. It receives every hit from your site, reads the consent state that comes with it, and decides what to forward to Google Ads, GA4, Meta and the rest. Whoever controls that process controls what leaves it, whatever your banner says.

We checked Google’s official image, gcr.io/cloud-tagging-10302018/gtm-cloud-image, in the public registry on 5 November:

• Version 4.5.0 (pushed 8 October) ships Node.js 24.21.0 — older than the fix.
• Version 4.6.0 (pushed 29 October, now the stable tag) ships Node.js 24.22.1 — the patched release.
• Google’s release notes still stop at 4.5.0, so the update was never announced there.

Here is the catch. Cloud Run’s documentation says that when you deploy from a tag, “it will be resolved to a digest” and “the revision will always serve this particular digest” (source). So pointing at :stable does not keep you current. Your service keeps running the image it was deployed with until someone deploys a new revision.

To be precise about what we have not shown: we have not tested whether the tagging server’s code ever decompresses attacker-supplied Brotli data, and Google has not said. What we know is that a server-side GTM deployed before 29 October runs a Node.js build that CISA considers exploited, and that the fix is already sitting in the registry.

Check your tagging server in ten minutes

1. Find the version. In Tag Manager, open the server container, then Admin > Container settings. Anything below 4.6.0 predates the patched Node.js.
2. Redeploy on Cloud Run. Open the service, choose Edit & Deploy New Revision, keep the image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable and deploy, as Google’s setup guide describes. Do it for the preview server too.
3. App Engine or your own Docker host? Same idea: pull the image again and redeploy. A running container never upgrades itself.
4. Using a managed host for sGTM? Ask them which Node.js version your container runs, in writing.
5. Put 11 November in the calendar. The next Node.js fix will need the same redeploy once Google ships a new image.

The rest of your consent stack on Node.js

Server-side GTM is the obvious one, but not the only one. Next.js sites, self-hosted CMP backends such as c15t, and the small API that stores your proof of consent are often Node.js too. For each one:

• check the Node.js version actually running in production (node -v inside the container, not on your laptop);
• rebuild container images — updating Express or body-parser alone does not fix the decoder;
• where you never expect compressed request bodies, turn off body-parser’s inflate option;
• if a consent log server was exposed and unpatched, review its records: under GDPR Art. 7(1) you have to be able to show consent, and a log someone could have edited is weak evidence.

Consent Mode cannot help here. It tells Google tags how to behave; it does not protect the server that relays them.

Nothing here is legal or security-incident advice.

A patched server is step one. Step two is checking what your site actually sends before and after consent. Scan your website with CookieInspector to see which third-party requests fire before anyone clicks. (CookieInspector is built by the team behind ConsentModeHQ.)