Malicious JavaScript delivered through Google Tag Manager can make a clean WordPress installation behave as compromised without changing its files or database. Separate the website from the tag-management account: identify which container/version/tag emitted the script and who could publish it.
Prove the script comes through GTM
Use browser source/network and the container preview/version history to map the unexpected request or DOM change to a specific tag rather than assuming WordPress injected it.
Preserve the published container version
Record container ID, published version, tag/trigger configuration and audit history before rolling back. This preserves evidence of when behavior entered production.
Contain the tag without destroying measurement
Pause or roll back the confirmed malicious tag/version while keeping known-good analytics tags where safe. Avoid deleting the entire container before evidence and legitimate configuration are captured.
Review account access and publishing rights
Inspect users, workspaces, service accounts and recent changes. Rotate or revoke compromised access at the Google account/organization layer, not only inside WordPress.
Check for a second injection path
A compromised GTM account and infected WordPress can coexist. After container rollback, verify source files/database and confirm the unknown network request no longer appears.
Republish a known-good baseline
Promote a reviewed container version and test analytics plus security behavior. Keep change history and require controlled publishing permissions going forward.
Use the unknown-JavaScript guide to compare website injection and finish with cleanup verification.