For about 25 minutes on the afternoon of June 12, 2026, three of the most-installed marketing plugins on WordPress were serving malicious JavaScript to live websites. The window opened around 22:17 UTC for OptinMonster and TrustPulse, closed by 22:42 UTC, and reopened on PushEngage's CDN for several hours afterward with some edge servers still serving the tampered script into June 14. By the time security firm Sansec disclosed the campaign on June 13 and Patchstack published its analysis on June 15, Patchstack's firewall had already blocked 271 exploitation attempts in 36 hours across customer sites. The three plugins are run by a single company called Awesome Motive, and Sansec estimates the combined reach at more than 1.2 million WordPress sites. If you run OptinMonster, TrustPulse, or PushEngage, the rest of this post is the part of the news you actually need to read.
What actually happened
This was not a normal plugin vulnerability. The attacker did not exploit a bug in the plugins themselves. Instead, they broke into Awesome Motive's marketing website through an UpdraftPlus flaw on that site, pulled a CDN API key, and used that key to push a modified copy of the plugins' normal JavaScript SDKs out to customer websites. The tampered files were the legitimate front-end scripts you would expect to load: a.omappapi.com/app/js/api.min.js for OptinMonster, a.trstplse.com/app/js/api.min.js for TrustPulse, and clientcdn.pushengage.com/sdks/pushengage-web-sdk.js for PushEngage. To the browser and to most security tools, the files kept doing their normal job of showing popups and push prompts. They just did one more thing on the side.
The side job was ugly. When a logged-in WordPress administrator loaded a page that included the tampered script, the code used that administrator's own browser session to silently create a brand-new admin account under the attacker's control and install a hidden plugin that opened a permanent backdoor into the site. The whole thing looked like a normal "add user" request, because the attack was running in the admin's own browser with the admin's own valid nonce. That is the part that makes this attack different from the older wave of plugin CVEs: it weaponized trust at the network layer instead of breaking into a plugin's PHP. Patchstack's writeup puts it plainly: every malicious request looked, at the network layer, almost exactly like a real administrator adding a user.
The blast radius, by the numbers
OptinMonster is the giant in this group, with more than a million active installs, and it carried the shortest attack window. TrustPulse had a similar 25-minute window. PushEngage, which has a much smaller install base of around 9,000 sites, had the longest exposure, with some of its CDN edge servers still serving the tampered script into June 14. The total reach is roughly 1.2 million sites, but reach is not damage. Most of those sites loaded a clean version of the script either before or after the window, or had no logged-in admin browsing the front end during those minutes. The actual count of compromised sites is going to be a small fraction of the reach, but it is going to be a non-zero fraction, and the backdoor is built to stay quiet, so we will not know the real number for a while.
PushEngage was the first of the three vendors to publish an incident notice and confirm that an attacker had served tampered copies of its script. OptinMonster and TrustPulse were quiet for several days before finally publishing their own disclosure. As of the time of writing, all three plugins are run by Awesome Motive, which is a useful fact to keep in your head if you ever have to make a vendor trust decision on one of their other products like WPForms or MonsterInsights.
How to tell if your site is one of them
This is the part that matters today, because the backdoor is designed to stay out of your WordPress dashboard. The malicious code is built to hide new admin accounts from the users list and to keep the backdoor plugin invisible in the plugins screen, so a normal login-and-look check will not catch it. You need to do this from the server, not from wp-admin.
Start with the user database. Connect to your site over SFTP or use your host's database tool and run a direct query on the wp_users table looking for any admin-level accounts you did not create yourself. Sort by user_registered and pay attention to anything that appeared between June 12 and June 14, 2026. If you find a user with a random-looking email address, a generic display name, and an administrator role, that is the attacker, and you should assume the site is fully compromised rather than just one bad account.
Next, look for the backdoor plugin. The malicious plugin typically lives outside the normal plugins directory and uses a name designed to look like core, like something starting with "wp-" or "akismet-". From the server, list the contents of wp-content/plugins/ and look for any folder that does not match an installed plugin. The same goes for mu-plugins. Both Sansec and Patchstack have published indicators of compromise including file hashes and the exact CDN paths that served the bad scripts, so it is worth searching your server for those filenames and hashes directly.
Finally, audit your theme and your wp-content/uploads folder. Supply chain backdoors of this style often leave a fallback file in case the plugin gets removed, usually a PHP file with a misleading name. If you find anything in uploads that ends in .php and you did not put it there, treat the site as fully owned and plan a rebuild rather than a cleanup. Cleaning a backdoored WordPress site by deleting files almost always misses something.
What to do this week
If you run any of the three plugins, the order of operations is fix first, investigate second. Rotate every WordPress admin password on the affected site, and rotate any API keys, hosting panel logins, and database passwords that the site or its admins have touched. Force-logout every active session, because the attacker may have issued a session token that survives a password change until the cookie expires. Disable and remove the three plugins if you can, since OptinMonster in particular has alternatives that do not load third-party JavaScript on every page. If you need OptinMonster's features, run their snippet through a server-side template that does not call the vendor CDN at all, or switch to a tool that ships its code with the theme instead of from a third-party domain.
If you were using a shared password or you have other WordPress sites on the same server, change the passwords and rotate the SSH keys on those sites too. Once an attacker owns one site on a shared host, the path to the others is usually a known CVE in cPanel, Plesk, or an aging PHP version. Treat the whole server as a possible target until you have proven otherwise.
The bigger lesson is the one that keeps recurring in 2026: the attack surface of a WordPress site is no longer just the plugins you install. It is also every third-party JavaScript file that your plugins decide to load. A plugin that loads its SDK from a vendor-controlled CDN is a CDN breach away from owning your admin. The fix is not to stop using these plugins. The fix is to know which of your plugins do it, know which CDN domains are in your page source right now, and have a server-side plan for what to do when one of those CDNs gets popped. The June 12 incident was small in time and small in confirmed victims, but the technique generalizes, and the next one will not be 25 minutes. It might be a week.