WordPress CDN Supply Chain Attack 2026: What Happened and How to Check Your Site
The OptinMonster, TrustPulse, and PushEngage supply chain attack (June 2026) hit 1.2M sites. Here's exactly how it worked, how to check if you were compromised, and how to recover.
On this page
On June 12, 2026, attackers compromised a CDN signing key belonging to Awesome Motive, the company behind OptinMonster, TrustPulse, and PushEngage. Within minutes, malicious JavaScript was injected into the legitimate CDN-hosted scripts that 1.2 million WordPress sites load on every page view. No plugin vulnerability was exploited. No outdated software was involved. The plugins were fully up to date, and the attack still worked.
This is a structural supply chain problem: when you trust a third-party CDN to serve JavaScript on your pages, you trust the entire chain of custody behind that CDN. If any link in that chain breaks (a compromised key, a rogue employee, a misconfigured deployment pipeline), every site downstream is exposed. The same CDN trust problem appears in CI/CD pipelines, and it applies equally to npm dependencies you can audit with DepScan.
This article covers exactly what the attack did, how to check if your site was affected, and how to recover. It also explains three defenses that would have blocked this attack entirely.
How the Attack Worked
The attacker gained access to the CDN signing key used to deploy JavaScript assets for OptinMonster, TrustPulse, and PushEngage. They appended a malicious payload to the end of the legitimate, minified JS files served from the CDN. Because the files were served from the same trusted domain, browsers loaded them without complaint.
The payload was designed to be invisible to security tools and only activate on real admin sessions. Here's the full attack chain:
- CDN injection: Malicious code appended to legitimate OptinMonster, TrustPulse, and PushEngage JavaScript files on the CDN. The files kept their original functionality intact.
- Environment checks: The payload detected headless browsers and security scanners by checking
navigator.webdriver,window._phantom,window.__nightmare, and zero-dimension browser windows. If any check matched, the payload stayed dormant. - Admin detection: Checked for
/wp-admin/in the URL, the presence of the WordPress admin toolbar in the DOM, andwordpress_logged_in_cookies. Only activated when a logged-in admin was browsing. - Credential harvesting: Extracted authentication tokens and WordPress nonces directly from the page DOM and AJAX settings object (
wpApiSettings.nonce). - Hidden admin creation: Used the stolen nonce to create a new administrator account, either
developer_api1(email: customer1usx@gmail.com) or adev_prefixed username with a random suffix. - Backdoor plugin installation: Uploaded and activated a self-hiding plugin named
content-delivery-helperordatabase-optimizer. These plugins do not appear in the WordPress admin plugin list. - Exfiltration: Sent harvested credentials and site metadata to
tidio.cc, a domain designed to be confused with the legitimatetidio.comlive chat service.
Was Your Site Affected?
If your site uses OptinMonster, TrustPulse, or PushEngage, and any administrator visited the site between June 12 and June 14, 2026, you need to check for indicators of compromise. Run through these four checks in order.
- 1
Check for Rogue Admin Accounts
The attack creates administrator accounts that are easy to spot if you know what to look for. Use WP-CLI to list all admin accounts and their emails:
bash — Check admin accounts# List all administrator accounts with their emails wp user list --role=administrator --fields=ID,user_login,user_email # Specifically search for known attack indicators wp user list --role=administrator --field=user_email | grep -i "customer1usx" wp user list --role=administrator --field=user_login | grep -E "^dev_|^developer_api"Look for:
developer_api1with emailcustomer1usx@gmail.com, or any username starting withdev_followed by random characters that you don't recognize. - 3
Check Server Logs for Outbound Connections
The attack exfiltrates data to
tidio.cc. Check your server logs for any outbound connections to this domain:bash — Check for exfiltration indicators# Nginx access logs grep "tidio.cc" /var/log/nginx/access.log # Apache access logs grep "tidio.cc" /var/log/apache2/access.log # DNS query logs (if available) grep "tidio.cc" /var/log/syslogNote that the exfiltration happens client-side (from the admin's browser), so server-side logs may not capture it. The absence of server log entries does NOT mean your site wasn't compromised. Focus on the admin account and filesystem checks instead.
- 4
Verify Your Exposure Window
The attack only triggered when a logged-in WordPress admin visited a frontend page. If no admin visited the site during the compromised window, the payload never executed.
- OptinMonster / TrustPulse: June 12, 22:17 to 22:42 UTC (25 minutes)
- PushEngage: June 12, 22:17 UTC through June 14 (approximately 50 hours)
- Condition: An administrator must have loaded a frontend page (not just the dashboard) during this window
Check your WordPress activity logs (if you have a logging plugin like WP Activity Log) or your server access logs for admin sessions during these times. If an admin was active, proceed with the recovery steps below regardless of whether you found the other indicators.
How to Recover If You Were Compromised
If you found any indicators of compromise, follow all five recovery steps. Do not skip steps or reorder them. The backdoor plugin can re-create the admin account, so removing the plugin must happen first.
- 1
Remove the Backdoor Plugin from Disk
Remove the backdoor plugin directly from the filesystem. Do not use the WordPress admin dashboard for this, as the plugin's deactivation hook may execute additional malicious code.
bash — Remove backdoor plugins# Remove known backdoor plugins (run from WordPress root) rm -rf wp-content/plugins/content-delivery-helper rm -rf wp-content/plugins/database-optimizer # Verify they're gone ls wp-content/plugins/ | grep -E "content-delivery|database-optimizer" - 2
Delete Rogue Admin Accounts
Remove the attacker-created admin accounts using WP-CLI. Reassign their content to your legitimate admin account:
bash — Delete attacker accounts# Find the rogue account ID wp user list --role=administrator --fields=ID,user_login,user_email # Delete the account and reassign content to your real admin (replace IDs) wp user delete <ROGUE_USER_ID> --reassign=<YOUR_ADMIN_ID> # Verify it's gone wp user list --role=administrator - 3
Rotate All Credentials
The attacker harvested authentication tokens and nonces. Assume all credentials are compromised. Rotate everything:
- WordPress admin passwords: Force password reset for every administrator account
- WordPress security keys and salts: Regenerate all keys in
wp-config.php(use the WordPress salt generator) - Database password: Change in your hosting panel and update
wp-config.php - API keys: Any API keys stored in WordPress options or plugin settings
- Hosting credentials: cPanel, SSH keys, FTP passwords
bash — Force password resets# Force password reset for all admins wp user list --role=administrator --field=ID | xargs -I {} wp user reset-password {} # Regenerate security keys (updates wp-config.php) wp config shuffle-salts - 4
Restore from a Clean Backup (If Available)
If you have a backup from before June 12, 2026, restoring it is the most reliable way to ensure no other persistence mechanisms exist. After restoring, immediately apply the credential rotation from step 3 again.
- 5
Block Outbound Connections to tidio.cc
Block the exfiltration domain at the server level to prevent any remaining code from phoning home:
nginx — Nginx: block outbound (add to server block)# Block requests to the exfiltration domain if ($http_referer ~* "tidio\.cc") { return 403; }bash — Server-level DNS block# Add to /etc/hosts to block the domain at the OS level echo "127.0.0.1 tidio.cc" | sudo tee -a /etc/hosts # Or block with iptables (if you know the IP) sudo iptables -A OUTPUT -d tidio.cc -j DROPIf your hosting provider offers a Web Application Firewall (WAF), add
tidio.ccto the blocked domains list there as well. This gives you defense in depth across multiple layers.
Why Keeping Plugins Updated Isn't Enough
The standard WordPress security advice is: keep your plugins updated, use strong passwords, install a security plugin. This attack bypassed all three. The plugins were on their latest versions. Admin passwords were irrelevant because the attack created new accounts using stolen nonces. Security plugins didn't flag anything because the malicious code came from a trusted, allowlisted CDN domain.
This is a supply chain attack, not a plugin vulnerability. The distinction matters. A vulnerability means the plugin code itself has a bug. A supply chain attack means the delivery mechanism for otherwise-legitimate code was compromised. You can't patch your way out of a supply chain problem.
This is not a new pattern. The same structural problem appears across the entire software ecosystem:
- Polyfill.io (2024): New domain owner injected malicious redirects into polyfill.io scripts loaded by 110,000+ sites
- XZ Utils (2024): A multi-year social engineering campaign planted a backdoor in a critical Linux compression library
- tj-actions/changed-files (March 2025): Compromised GitHub Action exfiltrated CI secrets from thousands of repositories
- Awesome Motive CDN (June 2026): This attack, affecting 1.2M+ WordPress sites through three plugins from one company
The trust model that says "keep plugins updated and you'll be safe" is built on an assumption that no longer holds: that the upstream delivery infrastructure is trustworthy. When a CDN key, a package registry account, or a CI pipeline is compromised, the "update" IS the attack vector.
Three Defenses That Would Have Stopped This Attack
Subresource Integrity (SRI)
Subresource Integrity lets you pin a cryptographic hash to any external script. The browser calculates the hash of the downloaded file and refuses to execute it if the hash doesn't match. If SRI had been applied to the OptinMonster CDN scripts, the modified files would have failed the hash check and never executed.
<!-- Browser will only execute if the file matches the hash -->
<script
src="https://cdn.optinmonster.com/app/js/api.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
crossorigin="anonymous"
></script>The practical limitation: SRI requires you to know the exact hash of the file in advance. Every time the plugin vendor updates their CDN script (which happens frequently with SaaS tools), the hash changes and the script breaks until you update the hash. WordPress plugins that load CDN scripts dynamically can't easily implement SRI because the script URL and content change with every release.
Despite this limitation, SRI remains the strongest technical defense against CDN tampering. For scripts that change infrequently (analytics, fonts, stable libraries), it's worth implementing. For rapidly-updating SaaS widget scripts, the operational burden is high, but the security benefit is real.
Content Security Policy (CSP)
A Content Security Policy header tells the browser which domains your page is allowed to connect to. The attack exfiltrated data to tidio.cc. A properly configured connect-src directive would have blocked that outbound request entirely, preventing credential exfiltration even though the malicious script executed.
Content-Security-Policy:
default-src 'self';
script-src 'self' https://cdn.optinmonster.com https://cdn.trustarc.com;
connect-src 'self' https://api.optinmonster.com https://api.pushengage.com;
style-src 'self' 'unsafe-inline';The connect-src directive is the key line. It restricts where JavaScript can send data via fetch, XMLHttpRequest, or WebSocket. Because tidio.cc is not in the allowlist, the exfiltration request would fail. The malicious script would still execute (it came from an allowed script-src domain), but it couldn't send the stolen credentials anywhere.
CSP doesn't prevent the attack entirely (the hidden admin account could still be created via WordPress AJAX calls to your own domain), but it blocks exfiltration and significantly reduces the attacker's ability to maintain remote access.
Plugin Vendor Diversity
OptinMonster, TrustPulse, and PushEngage are all owned by Awesome Motive. All three share CDN infrastructure and deployment keys. When one key was compromised, all three plugins were compromised simultaneously. Sites running all three had triple the attack surface from what was effectively a single point of failure.
Vendor concentration is a supply chain risk. If you rely on three critical plugins from the same company, a single infrastructure breach affects all three. Diversifying vendors means a compromise at one company doesn't cascade across your entire stack.
This isn't always practical (some companies offer the best tools in their category), but it should be a conscious risk decision rather than an accident. At minimum, audit which of your plugins share a parent company and CDN infrastructure.
Hardening Checklist
Use this checklist to verify your site's security posture after the attack and reduce exposure to future supply chain compromises.
- Check for rogue admin accounts (search for
developer_api1ordev_prefixed usernames) - Check the filesystem directly for hidden plugins (
content-delivery-helper,database-optimizer) - Check server logs for outbound connections to
tidio.cc - Rotate all credentials if any indicators of compromise exist
- Implement a Content Security Policy (restrict
connect-srcto known domains) - Audit which plugins load external CDN scripts and from which domains
- Enable WordPress file change monitoring (Wordfence or similar)
- Require admin multi-factor authentication
- Review plugin vendor concentration (avoid 3+ critical plugins from one company)
- Subscribe to Patchstack or Wordfence alerts for future incidents
Frequently Asked Questions
Was my site affected by the OptinMonster attack?
Your site was potentially affected if all three conditions are true: (1) you use OptinMonster, TrustPulse, or PushEngage, (2) an administrator visited the site's frontend between June 12 and June 14, 2026, and (3) the plugin loaded its CDN script during the compromised window.
To confirm, check for the developer_api1 admin account or any dev_ prefixed usernames you don't recognize. Also check your wp-content/plugins/ directory for content-delivery-helper or database-optimizer folders.
wp user list --role=administrator --fields=ID,user_login,user_email
ls wp-content/plugins/ | grep -E "content-delivery|database-optimizer"How do I check for the WordPress developer_api1 backdoor account?
Use WP-CLI to list all administrator accounts. The attack creates either developer_api1 (with email customer1usx@gmail.com) or a username starting with dev_ followed by random characters.
# List all admins
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Check specifically for known attack patterns
wp user get developer_api1 2>/dev/null && echo "COMPROMISED" || echo "Not found"If you don't have WP-CLI access, check your database directly: SELECT * FROM wp_users JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id WHERE wp_usermeta.meta_key = 'wp_capabilities' AND wp_usermeta.meta_value LIKE '%administrator%';
What is a WordPress CDN supply chain attack?
A CDN supply chain attack compromises the delivery infrastructure (Content Delivery Network) rather than the plugin code itself. The plugin's source code is fine. The version in the WordPress repository is fine. But the JavaScript file served to browsers from the CDN has been tampered with after leaving the developer's hands.
This differs from a plugin vulnerability in a critical way: updating the plugin doesn't help (and may make things worse if the update pulls from the same compromised CDN). The attack targets the pipe, not the water source.
How does Subresource Integrity protect against CDN attacks?
Subresource Integrity (SRI) adds a cryptographic hash to your script tag. Before executing the file, the browser independently calculates the hash of the downloaded content. If the CDN serves a tampered file (even one extra byte), the hash won't match and the browser refuses to execute it.
<script
src="https://cdn.example.com/widget.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
crossorigin="anonymous"
></script>You can generate the hash for any file using OpenSSL: cat widget.js | openssl dgst -sha384 -binary | openssl base64 -A. The tradeoff is that you need to update the hash every time the vendor updates their script.
Should I remove OptinMonster after the attack?
Awesome Motive rotated their CDN keys and the compromised scripts have been cleaned. The plugins themselves are safe to use again as of June 14. Whether you should continue using them is a risk assessment, not a binary decision.
- Keep it if: you depend heavily on the tool, have implemented CSP headers, and monitor for admin account changes
- Remove it if: you're running multiple Awesome Motive plugins (vendor concentration risk), don't have monitoring in place, or the tool isn't critical to your business
- Either way: implement the defenses in this article (CSP, file monitoring, MFA for admins) before making the decision
No SaaS vendor is immune to supply chain attacks. The question isn't "is this vendor trustworthy" but "what happens to my site when any vendor gets compromised, and do I have defenses in place for that scenario?"
Related Articles
GitHub Actions Security: 7 Misconfigurations to Avoid
The 7 GitHub Actions misconfigurations behind real supply chain attacks: weak GITHUB_TOKEN scope, pull_request_target, unpinned actions, script injection.
How to Audit Your VS Code Extensions for Security
The GitHub breach happened through a VS Code extension. Here's how to check what you have installed and reduce your exposure in 10 minutes.