Google Tag Manager Malware: Find and Remove Rogue Tags

By Glenn Lyvers · Updated September 28, 2026 · 7 min read

Google Tag Manager malware is malicious JavaScript delivered through a GTM container instead of through your own files. Either an attacker added a tag to your container, or they planted their own container ID on your site. Both routes survive a file-level cleanup completely, because the payload is served from Google’s infrastructure, which is exactly why this is showing up more often in skimmer and redirect cases.

Two different problems with the same name

When someone says “the malware is in Tag Manager” they usually mean one of two things, and the fix is different for each.

1. Your own container was modified. Someone with access to your Google account — or to the account of an agency or former contractor you once added as a user — created a Custom HTML tag and published it. Your site’s code is untouched. Every page loads your legitimate GTM-XXXXXXX snippet, and GTM faithfully delivers the attacker’s script along with your analytics.

2. A rogue container was injected into your site. The attacker compromised the site itself and added a GTM snippet with a container ID that belongs to them. From the outside it looks like ordinary analytics code. In early 2025 Sucuri documented exactly this on Magento stores: a GTM snippet with the ID GTM-MLHK2N68 was stored in the cms_block.content database table and loaded an obfuscated credit card skimmer on checkout pages. The same technique works on WordPress, where the snippet usually ends up in a header-and-footer plugin setting, a theme option or wp_options.

Case 1 is an account-security problem. Case 2 is a site compromise that happens to use Google as its delivery network. You may have both.

Symptoms that point at a tag manager

• A skimmer, redirect or pop-up that keeps appearing after a clean reinstall of every file.
• A file-and-database scanner reports nothing, yet a browser shield or Google flags the site.
• The malicious request in the browser’s Network panel is initiated by gtm.js.
• More than one GTM- ID in your page source, or an ID you don’t recognise.
• The problem only affects certain pages — checkout, a landing page, mobile visitors — because GTM triggers make that kind of targeting trivial. See mobile-only redirects for how conditional delivery hides from owners.

Step 1: check which containers your site loads

View the rendered source of several page types — home, a post, the cart and checkout — logged out, and search for GTM- and googletagmanager.com. Write down every container ID. Then compare them with the containers you actually own in tagmanager.google.com. Any ID that is not in your account list is not yours.

To find where a rogue snippet is stored, search both files and database for the ID:

grep -rn "GTM-" wp-content/ --include=*.php --include=*.js
wp db search "GTM-" --all-tables

On Magento, check cms_block, cms_page and core_config_data (the design head and footer settings are common hiding places). Remove the snippet from every place it appears, then treat it like any other site compromise: the attacker had write access to your database, so there is a way in that still needs closing. My guide to checking a strange domain found in your site’s code covers the full search pattern.

Step 2: audit your own container

Open your container in GTM and work through it in this order:

1. Versions. The Versions tab lists every published version with the date and the account that published it. A version published by an address you don’t recognise, or at a time nobody was working on the site, is your starting point.
2. Tags. Filter by type and read every Custom HTML tag in full. Legitimate ones are usually short and name the vendor they belong to. Malicious ones tend to contain atob(, eval(, long encoded strings, or a <script src> on an unfamiliar domain. Also check Custom JavaScript variables — code can hide there and be called from an innocent-looking tag.
3. Triggers. A tag set to fire only on URLs containing checkout or onepage deserves a hard look.
4. Custom templates. These can carry code too, and are easy to overlook.
5. Users. Under Admin, review user management at both the account and container level. Remove anyone who no longer needs access, and anyone you can’t identify.

Rolling back is quick: publish the last version you trust, or delete the malicious tag and publish. Unpublished workspace changes do nothing to visitors, so make sure the clean version is actually live.

Step 3: lock down the Google side

If your container was modified, someone had a working Google login with publish rights. Change the password on that account, turn on 2-Step Verification, review the account’s security activity, and sign out other sessions. Do the same for every other user with Publish permission. Then move through the rest of your credentials — my guide on rotating credentials after a hack gives the order that avoids locking yourself out.

Going forward, give agencies and freelancers the lowest GTM permission they need, remove them when the job ends, and use GTM’s approval workflow if more than one person edits the container. A tag manager is effectively a way to run any code you like on every page of your site; it deserves the same care as your hosting login.

If you take payments

A GTM-delivered skimmer on a checkout page means card data may have been captured, even if the code was only live for a few days. Don’t just remove it and move on. Establish when the malicious version was published (the Versions tab gives you a timestamp), preserve that evidence, and read the guides on Magento credit card skimmers or WooCommerce skimmers for the site side, and PCI obligations after a skimmer for what you may owe your payment processor and customers.

This is also the kind of case where I’d suggest you don’t work alone. A skimmer investigation needs a clear timeline and a clear record of what was removed, and I include both in the written report that comes with every cleanup I do.

Why most scanners miss it

Server-side scanners read files and database rows. In case 1 there is nothing on your server to find, and in case 2 the only local evidence is a GTM snippet that looks exactly like the one on millions of legitimate sites. The payload is fetched at runtime from Google’s domain, which no reputation list is going to block. The dependable check is behavioural: load the pages in a real browser, record the network requests, and account for every script that runs. That is also how I work out injected JavaScript in the header cases, and why free scanners miss so much.

Common questions

Can malware be delivered through Google Tag Manager?

Yes. Anyone who can publish to a GTM container can make it load any JavaScript on every page that includes the container, and attackers can also inject their own container ID into a compromised site. In 2025 Sucuri documented a Magento credit card skimmer delivered this way from a snippet hidden in the cms_block table.

How do I know if my GTM container has been hacked?

Check the Versions tab for versions published by unfamiliar accounts or at unexpected times, read every Custom HTML tag and Custom JavaScript variable in full, look for tags that fire only on checkout pages, and review the user list at account and container level. Compare the container IDs in your page source with the containers you own.

I found a GTM ID on my site that isn't mine. What does it mean?

It means someone with write access to your site added their own container, which lets them change the malicious code at any time without touching your server again. Remove every copy from files and database, then treat it as a full site compromise and find how they got in, because that access is still open.

Will reinstalling WordPress remove Tag Manager malware?

No. If the malicious tag is in your own container, nothing on your server is infected, so a reinstall changes nothing. If a rogue snippet is stored in the database, a file reinstall misses it too. You need to clean the container and search the database for GTM IDs as separate steps.

How do I stop it happening again?

Protect every Google account with publish rights using a strong unique password and 2-Step Verification, remove old agency and contractor users, grant the lowest permission each person needs, and use GTM's approval workflow if several people edit. On the site side, keep plugins updated and review header and footer script settings regularly.