An attacker modified trusted JavaScript files utilized by WordPress websites operating PushEngage, OptinMonster, and TrustPulse, converting those files into a method for breaching the sites.
When a site administrator was authenticated and the file loaded, the code generated an administrative account under the attacker's control and deployed a concealed plugin that established a persistent access route. Regular visitors did not activate this mechanism.
Any site that was targeted should be considered compromised. All three plugins are managed by a single company, Awesome Motive, which had not provided remarks regarding the two larger plugins as of June 15.
Security firm Sansec revealed the broader campaign on June 13, identifying identical malicious code within JavaScript delivered for all three plugins.
PushEngage followed a day later with its own incident notification, confirming that an attacker had distributed altered copies of its script and that websites loading them could be compromised.
PushEngage, acquired by Awesome Motive several years ago, is currently the only one of the three to have issued guidance; users of OptinMonster and TrustPulse have received no official communication.
The exposure window was not identical for each plugin. Sansec observed the malicious code in OptinMonster and TrustPulse for only approximately 25 minutes on June 12, starting around 22:17 UTC and disappearing by 22:42. PushEngage's exposure period was longer: several hours on June 12, and its script continued to be delivered from some CDN servers into June 14.
Thus, the two plugins with the largest number of sites had the shortest window, while PushEngage had the longest.
Sansec estimates that the three plugins collectively reach more than 1.2 million sites, with the majority attributed to OptinMonster, which alone has over one million active installations. PushEngage's WordPress plugin has more than 9,000 installations. This figure represents reach, not damage: it counts sites operating the plugins, not sites that were breached.
How the attack functioned
The poisoned script performed no action during a normal page view. It only activated when a logged-in WordPress administrator loaded it, then leveraged that administrator's session to seize control.
This design is also why the WordPress dashboard cannot indicate whether you were impacted: the backdoor is constructed to remain hidden from admin screens, so the only trustworthy verification is on the server itself.
In PushEngage's case, the tampered files were its standard embeds, pushengage-web-sdk.js and pushengage-subscription.js, delivered from clientcdn.pushengage.com, the content delivery network that distributes PushEngage's script to customer sites. OptinMonster and TrustPulse were affected through separate Awesome Motive CDN endpoints.
PushEngage states that the remainder of its systems remained untouched: it found no evidence that its main application or the servers containing customer data were accessed.
According to PushEngage's own account, once the script executed with an administrator logged in, it:
utilized that administrator's session to operate with full permissions,
generated a new administrative account under the attacker's control,
installed a plugin that does not appear in the dashboard, and
transmitted the new login credentials and site information to tidio[.]cc, a fake domain designed to resemble the legitimate tidio.com.
Sansec discovered the same sequence across all three plugins. The tidio[.]cc domain was registered on April 28, weeks before the attack, indicating a planned operation rather than a rapid smash-and-grab.
The concealed plugin is the primary objective. It opens what is known as a web shell, a remote command channel: anyone aware of the correct URL can execute code on the server without logging in. From there, the attacker can read or modify any file, copy the database, plant additional backdoors, inject card-skimming code, redirect visitors, or steal data.
The extra administrative account provides a simple return path if you delete the plugin but overlook the account. And because the attacker can freely execute code, removing the named plugin and account may not be sufficient; both Sansec and PushEngage advise assuming that other backdoors could persist.
How the attacker gained access
This is the area where the two accounts disagree. PushEngage claims the attacker first breached the server hosting its marketing website, through a known vulnerability in UpdraftPlus, a WordPress backup plugin. That server is separate from the systems that operate the product and store customer data.
What mattered was not the server itself but a key stored on it: a CDN API key. With that key, the attacker did not need to break into PushEngage's main systems. It could simply modify the files the CDN was already delivering to customer sites.
Sansec is not convinced the entry point is resolved. It states that the breached system remains unknown, with Awesome Motive's own servers being the most likely location, the CDN account being possible, and the CDN provider, BunnyNet, being unlikely.
Sansec's public analysis does not examine or endorse the UpdraftPlus theory; that account comes solely from PushEngage, regarding its own environment. UpdraftPlus does have a separate authentication-bypass vulnerability, CVE-2026-10795, which Wordfence rates as 8.1 (high severity); it is now patched, and Wordfence has reported attacks against it, so anyone running UpdraftPlus should update regardless.
Whether that vulnerability had any connection to this breach is unconfirmed. Treat the entry point as unresolved.
What to check and do
According to Sansec's timeline, the OptinMonster and TrustPulse files were clean by June 13, while PushEngage's script lingered on some CDN servers into June 14. PushEngage states it is still determining the exact window and has since replaced the malicious files, cleared the CDN cache, changed the CDN key and all related credentials, and moved the marketing site to new infrastructure.
None of that cleans a site that was already compromised.
Because the backdoor hides from the dashboard, you cannot rule out compromise by examining WordPress. If your site operated any of the three plugins during the threat window, the only reliable answer is a server-side scan.
Do not attempt to determine it by guessing whether you were logged in; most owners cannot prove that either way. Treat the steps below as the baseline.
Run a server-side scan. Anyone who had PushEngage, OptinMonster, or TrustPulse active during the window should scan the server directly. A browser or dashboard check will miss a payload that only executed for logged-in administrators. (Sansec observed the same payload on all three plugins, but has not confirmed that OptinMonster and TrustPulse were delivered the same way or in the same window as PushEngage.)
Check the filesystem, not the dashboard. Under wp-content/plugins, look for folders named content-delivery-helper ("Content Delivery Helper") or database-optimizer ("Database Optimizer"). Trust what is on disk. Delete any administrative accounts you did not create, especially developer_api1 or anything matching dev_xxxxxx.
Check your logs. Review 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.
If you find anything, assume the worst. Rotate everything: administrative passwords, API keys, database credentials, and the secret keys (salts) in wp-config.php. With code execution on the server, additional persistence may remain.