If you run server-side GTM, there’s a security update you should know about. Not because the sky is falling, but because your tagging server is quietly sitting on top of the software that just got patched.
Last updated 23 October 2026. This is a moving story. I’ll update this post when Google ships a tagging server image that includes the fixes.
What actually happened?
On 21 October, the Node.js project released fixes for 10 vulnerabilities across its three supported versions (22.x, 24.x and 26.x). The fixed versions are 22.23.4, 24.22.1 and 26.12.1.
Quick jargon check. Node.js is the engine that runs JavaScript on a server rather than in a browser. A CVE is just a catalogue number for a publicly known security flaw. And RCE, or remote code execution, is the scary one: it means someone on the internet could make your server run their code.
Why should an analyst care about any of this? Because Google’s server-side tagging image, the thing you deploy to Cloud Run or that Stape and friends host for you, runs on Node.js. Google’s release notes say the image moved to Node.js 24 in 2025.
The four that matter most
Node.js rated four of the ten as High:
- CVE-2026-111497: the Brotli bug. Brotli is a compression format, like a zip file for web traffic. Feed a vulnerable server some deliberately broken Brotli data and it can corrupt its own memory. Worst case, that’s remote code execution. Singapore’s Cyber Security Agency rates it 9.8 out of 10, which is higher than the Node.js “High” label.
- CVE-2026-105482: DNS name truncation. DNS is the internet’s phone book, turning names into addresses. This bug lets a specially crafted hostname get chopped short, so the server looks up a different name from the one it thinks it checked.
- CVE-2026-105483 and CVE-2026-106069: TLS certificate check bypasses. TLS is the padlock in HTTPS. Certificates are how a server proves it’s who it says it is. These bugs let a certificate pass a check it shouldn’t, but only when the connection is made to an IP address written in an odd format (fullwidth digits, or a leading zero).
Is anyone actually exploiting this?
On 23 October, The Hacker News reported that researchers at Imperva got the Brotli bug to run code on an official Node.js 24.22.0 build. That’s the version just before the fix. A few caveats worth keeping: it took several attempts, it was tested on one setup (Linux on arm64 processors), and no attacks in the wild had been reported as of 22 October. Not panic stations. But a working demo tends to shorten the gap between “theoretical” and “someone’s trying it”.
So is my sGTM server affected?
Honest answer: probably, but nobody has confirmed it. Here’s what we know and what we don’t.
What we know:
- The latest image, 4.5.0, was released on 8 October 2026, thirteen days before the Node.js fixes. So it can’t include them, unless Google has done something it hasn’t told us about.
- sGTM faces the internet. It receives hits from browsers on your first-party subdomain (think
metrics.analyticsedge.co.uk) and makes outbound calls to GA4, Google Ads, Meta and the rest. That’s exactly the kind of software these bugs are about, at least in principle.
What isn’t confirmed (please read this bit):
- The exact Node.js version inside the image. Google doesn’t publish it for recent releases. The last version it named was 22.16.0, back in 2025.
- Whether sGTM actually decompresses incoming Brotli data. This is the big one. According to the researchers, a plain Node.js server doesn’t decode a Brotli request body just because it receives one. It needs specific code to do so. If sGTM never does that with incoming hits, and doesn’t decode Brotli responses from vendors, the RCE path may not be reachable at all. We don’t know, and Google hasn’t said.
- When Google will ship a rebuilt image. No date, no announcement.
As of 23 October I couldn’t find a statement from Google, Stape, Addingwell or TAGGRS about these specific fixes. Stape’s 15 October update covers 4.5.0, but it came out before the Node.js release and doesn’t mention Node.
On the TLS bugs, I’d keep expectations realistic. They involve connecting to oddly written IP addresses, and your tagging server talks to vendors by name. So the “someone intercepts your calls to Meta” scenario is theoretical rather than likely. Still worth closing off.
What does this mean for your tracking?
This is where it gets relevant to us, rather than just to whoever owns the cloud bill.
The patch itself shouldn’t change your data
Updating means the same container (your tags, triggers and clients) running on a newer engine. Your configuration doesn’t change. In theory your data won’t either.
But redeploying a server is a change, and changes are where tracking breaks. So treat it like any release: check things afterwards rather than assuming they’re fine.
Don’t forget the preview server
Most self-hosted setups have two services: the tagging server that handles live traffic and the preview server that powers GTM’s Preview mode. Update one and not the other and Preview can break or, worse, show you something that doesn’t match what’s live. Update both.
If a server ever were compromised
It’s worth being clear about the stakes without being dramatic about them. A compromised tagging server could:
- Mess with your data. Injected or altered events flowing into GA4 and your ad platforms, quietly skewing reports and bidding.
- Expose personal data. Whatever passes through, like IP addresses, user agents, click IDs and any hashed emails you send for enhanced conversions.
- Create a consent headache. It runs on your own domain and sets first-party cookies, so anything that goes wrong is very much your problem, not a vendor’s.
The best question this raises: who owns your sGTM?
Plenty of analysts I talk to aren’t sure who’s responsible for patching their tagging server. Is it you? IT? An agency that set it up two years ago? A hosting provider? If you can’t answer that in one sentence, that’s the real action point here.
The practical checklist
If you self-host on Google Cloud Run
- Watch the release notes for a version newer than 4.5.0. Redeploying today will most likely just pull 4.5.0 again.
- Check your current version in GTM under Server container > Admin > Container settings.
- When a new version lands, redeploy both services. In Cloud Run, open each service (tagging and preview), click Edit & Deploy New Revision, make sure the image URL is
gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable, and hit Deploy. Google’s Cloud Run guide walks through it. - Confirm it took. Start a Preview session and check the Console tab for messages asking you to update the server. GTM’s own banner can lag for up to a day, so trust the preview page.
If you use Stape or another managed host
- Don’t assume. Stape’s latest public note is about 4.5.0, and it doesn’t cover these fixes.
- Ask support directly. Something like: “Are your sGTM servers running Node.js 24.22.1 or later, and when will you deploy Google’s next image?”
- Keep the reply on file. Handy for your next privacy or security review.
After any update, whoever does it
- Test in Preview first. Fire your key events and make sure tags trigger as expected.
- Check GA4 Realtime and DebugView to see events actually arriving.
- Check vendor dashboards (Google Ads, Meta Events Manager and the rest) over the next day or two for gaps or duplicates.
- Note the date of the update in your tracking change log, so a blip in the numbers doesn’t become a week-long mystery.
The bottom line
This isn’t a reason to rip out server-side tagging. It’s a reminder that sGTM is real infrastructure, sitting on your domain and handling your users’ data, and it needs looking after like any other server. Find out who owns it, keep an eye out for Google’s next image, and check your data once it’s deployed.