CVE-2022-1707

What it actually does

Google Tag Manager for WordPress (duracelltomi/gtm4wp) versions up to and including 1.15 insufficiently sanitize the WordPress site-search parameter, `s`, before placing it into the Google Tag Manager data layer in `public/frontend.php`. An unauthenticated attacker can cause attacker-controlled input to be reflected into a page response and interpreted by a victim browser as JavaScript. Because the script executes in the context of the affected site, it can read or modify page content, perform actions available to the victim’s session, abuse same-origin access, and potentially facilitate credential, token, or nonce theft depending on browser and WordPress hardening controls.

Why it matters to the business

Successful exploitation can undermine trust in a public website by allowing malicious scripts to run for visitors or administrators who click a crafted search link. Impacts may include account takeover attempts, fraudulent redirects, web skimming, defacement-like content injection, session or form-data exposure, and reputational damage. The CVSS score is moderate, but the EPSS score is very high, indicating broad expected exploitability or attacker interest; however, it is not currently listed in CISA KEV and is not flagged as ransomware-associated.

How an attack unfolds

An attacker does not need an account on the WordPress site. They identify a site using a vulnerable version of the Google Tag Manager for WordPress plugin, then create a URL that places script-capable content into the WordPress search parameter, `s`. When a victim follows the link, the plugin copies the search term into the GTM data layer without adequate output encoding. The victim’s browser processes the resulting page in the trusted origin of the site, allowing the attacker’s script to run with the victim’s browser permissions for that site. The attacker may then attempt to steal accessible tokens or form values, trigger authenticated WordPress actions via the victim’s session, inject phishing content, redirect the user, or chain the issue with social engineering against privileged users.

How to fix it

Upgrade Google Tag Manager for WordPress / gtm4wp to a version that includes the upstream fix. For source-based deployments, ensure the code includes commit `de15527c94af603cc6646b2ef9a36e2519401a37`; deployments running versions up to and including 1.15 should be treated as vulnerable. If immediate upgrade is not possible, temporarily disable the plugin, remove the vulnerable search-to-data-layer behavior, or apply a virtual patch/WAF rule that blocks script-like content in the `s` query parameter. Ensure output encoding is context-appropriate for JavaScript/data-layer insertion, not only HTML escaping. Maintain strong browser-side controls such as HttpOnly/Secure/SameSite cookies and a restrictive Content Security Policy, but do not treat those as substitutes for patching.

How to confirm the fix worked

Inventory WordPress installations for the Google Tag Manager for WordPress / gtm4wp plugin and verify that no deployment is running version 1.15 or earlier. Confirm that deployed source contains the fixed logic from commit `de15527c94af603cc6646b2ef9a36e2519401a37`. Perform a safe validation by submitting a harmless unique marker containing characters such as angle brackets and quotes in the `s` parameter, then inspect the rendered HTML and JavaScript context to verify the value is safely encoded and cannot break out of the data-layer string or object. Review plugin files under the WordPress plugins directory to ensure old copies are not retained or served by caches. Clear application, CDN, and page caches after patching and retest the public search endpoint.

Typical attack path

1. Find a WordPress site using Google Tag Manager for WordPress / gtm4wp version 1.15 or earlier.
2. Confirm that the site search parameter `s` is reflected into the page’s GTM data layer without safe encoding.
3. Craft a malicious search URL containing encoded script or HTML event-handler content in the `s` parameter.
4. Deliver the crafted link to a target through email, chat, ads, comments, social media, or another traffic source.
5. The victim opens the link, causing the vulnerable page to render the attacker-controlled value.
6. The browser executes attacker-controlled JavaScript in the affected site’s origin.
7. The attacker uses that execution to redirect the victim, inject phishing content, steal accessible data, or perform actions as the victim where browser/session protections allow.

How to detect it

To determine whether exploitation was attempted or successful, review HTTP access logs from the web server, CDN, load balancer, reverse proxy, and WAF for requests to WordPress search pages where the `s` query parameter contains encoded or raw script content. Focus on requests containing `<script`, encoded angle brackets, HTML event handlers such as `onerror` or `onload`, `javascript:` URLs, SVG/image tags, or attempts to break out of JavaScript strings. Correlate suspicious requests with user-agent, referrer, source IP, and whether the request was followed by authenticated WordPress admin activity from the same user session. Inspect WAF alerts for XSS rule hits against `/?s=` and WordPress search endpoints. Review browser-side telemetry, CSP violation reports, EDR web activity, and proxy logs for unexpected redirects or outbound calls immediately after suspicious search requests. If an administrator may have clicked a malicious link, review WordPress audit logs for unexpected profile changes, plugin/theme edits, new administrator accounts, content modification, or settings changes after the click time. Because this is reflected XSS, durable server-side artifacts may be absent unless the attacker chained it to make authenticated changes.

• /?s=%3Cscript
• /?s=<script
• &s=%3Cscript
• &s=<script
• s=%3C%2Fscript%3E
• s=</script>
• s=%3Cimg
• s=<img
• s=%3Csvg
• s=<svg
• s=javascript%3A
• s=javascript:
• s=%22%3E%3Cscript
• s='><script
• s=%27%3E%3Cscript
• s=onerror%3D
• s=onerror=
• s=onload%3D
• s=onload=
• s=alert%28
• s=confirm%28
• s=prompt%28
• wp-content/plugins/duracelltomi-google-tag-manager/public/frontend.php
• wp-content/plugins/gtm4wp/public/frontend.php
• de15527c94af603cc6646b2ef9a36e2519401a37

What your security team should do

• Prioritize patching or disabling affected gtm4wp installations because the EPSS score is very high even though the issue is not in CISA KEV.
• Search web access logs, CDN logs, WAF logs, and reverse-proxy logs for script-like payloads in the `s` query parameter, especially URL-encoded HTML tags, event handlers, and `javascript:` strings.
• Add or tune WAF rules to block active-content patterns in WordPress search parameters while patch rollout is completed.
• Review whether administrators or authenticated users clicked suspicious search URLs; correlate access logs with authentication logs and WordPress admin activity.
• Harden session cookies with HttpOnly, Secure, and SameSite attributes and deploy a restrictive Content Security Policy to reduce XSS blast radius.
• Purge cached pages after remediation to ensure vulnerable reflected responses are not retained by caches.
• If exploitation is suspected, rotate affected user sessions, review privileged WordPress account activity, and inspect for unauthorized plugin/theme changes or injected content.