An attacker successfully tampered with trusted JavaScript files used by WordPress sites running **PushEngage**, **OptinMonster**, and **TrustPulse**, transforming these files into a vector for site compromise. When a site administrator was logged in and the malicious file loaded, the injected code created an admin account controlled by the attacker. It then installed a hidden plugin, establishing a persistent backdoor. Crucially, ordinary visitors did not trigger this payload. Any site affected by this incident should be considered fully compromised. All three plugins are managed by **Awesome Motive**. As of June 15, **Awesome Motive** had not publicly commented on the compromise affecting **OptinMonster** and **TrustPulse**. Security firm **Sansec** first disclosed the broader campaign on June 13, identifying identical malicious code within JavaScript served across all three plugins. **PushEngage** followed a day later with its own incident notice, confirming that an attacker had served tampered copies of its script and that sites loading them could be taken over. **PushEngage**, acquired by **Awesome Motive** years ago, is currently the only one of the three to issue official guidance. Users of **OptinMonster** and **TrustPulse** have yet to receive official communications. The exposure window varied for each plugin. **Sansec** observed the malicious code in **OptinMonster** and **TrustPulse** for approximately 25 minutes on June 12, appearing around 22:17 UTC and disappearing by 22:42. **PushEngage**'s exposure was more extensive, lasting several hours on June 12, with its script still being served from some CDN servers into June 14. This means the two plugins with the largest user bases experienced a shorter window of vulnerability, while **PushEngage** had a more prolonged exposure. **Sansec** estimates that the three plugins collectively reach over 1.2 million sites. The majority of this reach comes from **OptinMonster**, which alone boasts over a million active installs. **PushEngage**'s WordPress plugin has more than 9,000 installs. These figures represent potential reach, not necessarily the number of breached sites. ## How the Attack Worked The poisoned script remained dormant during normal page views. It activated only when a logged-in WordPress administrator loaded it, subsequently leveraging that admin's session to take control of the site. This design explains why the WordPress dashboard cannot reliably indicate compromise: the backdoor is engineered to remain hidden from administrative screens. The only dependable method for detection is a direct server-side check. In **PushEngage**'s case, the tampered files were its standard embeds, `pushengage-web-sdk.js` and `pushengage-subscription.js`, served from `clientcdn.pushengage.com`—the content delivery network (CDN) distributing **PushEngage**'s script to customer sites. **OptinMonster** and **TrustPulse** were affected through separate **Awesome Motive** CDN endpoints.  **PushEngage** has stated that the rest of its systems remained unaffected, with no evidence that its main application or customer data servers were accessed. According to **PushEngage**'s account, once the script executed with an administrator logged in, it: 1. Used the administrator's session to act with full permissions. 2. Created a new administrator account under the attacker's control. 3. Installed a plugin that does not appear in the WordPress dashboard. 4. Sent the new login details and site information to `tidio[.]cc`, a fake domain designed to mimic the legitimate `tidio.com`. **Sansec** identified the same sequence of actions across all three plugins. The `tidio[.]cc` domain was registered on April 28, weeks before the attack, suggesting a premeditated operation rather than an opportunistic strike. The hidden plugin is the primary objective, opening what is known as a web shell—a remote command channel. Anyone with knowledge of the correct URL can execute code on the server without logging in. From this point, attackers can read or modify files, exfiltrate databases, plant additional backdoors, inject card-skimming code, redirect visitors, or steal sensitive data. The extra admin account serves as a simple fallback if the hidden plugin is removed but the account is missed. Given the attacker's ability to execute arbitrary code, simply deleting the named plugin and account may be insufficient; both **Sansec** and **PushEngage** advise assuming other backdoors could persist. ## How the Attacker Gained Entry The accounts of the initial entry point diverge. **PushEngage** claims the attacker first breached the server hosting its marketing website, exploiting a known vulnerability in **UpdraftPlus**, a WordPress backup plugin. This server is distinct from the systems running the product and storing customer data. Critically, this compromised server held a CDN API key. With this key, the attacker did not need to breach **PushEngage**'s core systems but could directly modify the files the CDN was delivering to customer sites. **Sansec** is not convinced the entry point has been definitively established. It states that the breached system remains unknown, with **Awesome Motive**'s own servers being the most likely candidate, the CDN account a possibility, and the CDN provider, **BunnyNet**, deemed unlikely. **Sansec**'s public analysis does not examine or endorse the **UpdraftPlus** theory; that account originates solely from **PushEngage** concerning its own environment. **UpdraftPlus** does have a separate authentication-bypass vulnerability, **CVE-2026-10795**, which **Wordfence** rates 8.1 (high severity). This flaw has since been patched, and **Wordfence** has reported active attacks exploiting it, emphasizing the importance for all **UpdraftPlus** users to update their plugin regardless. Whether this specific bug was involved in the current break-in remains unconfirmed. The exact entry point should still be considered unsettled. ## What to Check and Do According to **Sansec**'s timeline, the **OptinMonster** and **TrustPulse** files were cleaned by June 13, while **PushEngage**'s script lingered on some CDN servers into June 14. **PushEngage** states it is still determining the precise window of compromise and has since replaced the malicious files, cleared the CDN cache, rotated the CDN key and all associated credentials, and migrated its marketing site to new infrastructure. However, these actions do not remediate sites that were already compromised.  Because the backdoor evades the dashboard, you cannot rule out compromise by inspecting WordPress alone. If your site ran any of the three plugins during the identified threat window, a server-side scan is the only reliable method for detection. Do not attempt to determine compromise based on whether you believe you were logged in during the window, as most owners cannot definitively confirm this. Treat the following steps as essential actions: 1. **Run a server-side scan.** Any site that had **PushEngage**, **OptinMonster**, or **TrustPulse** active during the threat window should undergo a direct server scan. Browser-based or dashboard checks will miss the payload that only executed for logged-in administrators. (**Sansec** observed the same payload across all three plugins, but has not confirmed that **OptinMonster** and **TrustPulse** were delivered in the same manner or within the exact same window as **PushEngage**.) 2. **Check the filesystem, not the dashboard.** Look for folders named `content-delivery-helper` ("Content Delivery Helper") or `database-optimizer` ("Database Optimizer") within `wp-content/plugins`. Trust the contents of your disk. Delete any administrator accounts you did not create, especially `developer_api1` or anything matching `dev_xxxxxx`. 3. **Review your logs.** Examine web server access logs from June 12 to 14 UTC for outbound traffic to `tidio.cc`, including its `/cdn-cgi/` paths, and to the attacker's server at `84.201.6.54`. 4. **If compromise is found, assume the worst.** Rotate all critical credentials: administrator passwords, API keys, database credentials, and the secret keys (salts) in `wp-config.php`. With code execution on the server, additional persistence mechanisms may remain.