News

Attackers modified widely used JavaScript assets delivered to WordPress sites running PushEngage, OptinMonster and TrustPulse so those files could be used to seize control of affected installations. The malicious code only activated when a logged-in WordPress administrator loaded the script: in that context it leveraged the administrator’s session to create an attacker-owned admin user and to install a stealthy plugin that provides persistent access. Anonymous visitors did not trigger the payload, but any site that loaded the tampered script during the exposure window should be treated as compromised.

All three plugins are managed by Awesome Motive. Security vendor Sansec publicly revealed the campaign on June 13 after finding identical malicious code in JavaScript delivered for each product. PushEngage published its own incident notice the next day, confirming an attacker had served altered copies of its embedded scripts and warning that sites loading them could be hijacked. As of June 15, Awesome Motive had not posted official statements for OptinMonster or TrustPulse; PushEngage – which Awesome Motive acquired some years ago – was the only one of the three to provide guidance at that time.

The timing of the compromise differed by product. Sansec observed the malicious payload in OptinMonster and TrustPulse for roughly 25 minutes on June 12, first appearing near 22:17 UTC and gone by about 22:42 UTC. PushEngage’s exposure was substantially longer: its script was served for several hours on June 12, and copies remained available from some CDN servers into June 14. In short, the two plugins with the largest installed base had the shortest exposure window, while PushEngage’s script had the longest-lived distribution.

Sansec estimates the combined distribution of the three plugins reaches more than 1.2 million sites, the lion’s share coming from OptinMonster (which alone reports over a million active installs). PushEngage’s WordPress plugin shows more than 9,000 installs. Note that these numbers indicate potential reach – they count installations that use the plugins, not confirmed intrusions.

How the malicious code behaved: the injected JavaScript was dormant for ordinary pageviews and only executed when an authenticated WordPress administrator loaded a page that included the script. When that happened the code used the administrator’s session to perform actions with full privileges: it created a new admin account controlled by the attacker, installed a plugin designed to be invisible in the WordPress dashboard, and exfiltrated the new credentials and site details to a domain controlled by the attacker (tidio[.]cc – a lookalike of the legitimate tidio.com).

PushEngage’s compromised assets included the normal embed files pushengage-web-sdk.js and pushengage-subscription.js, which were served from clientcdn.pushengage.com, PushEngage’s CDN endpoint. OptinMonster and TrustPulse were affected through different CDN endpoints associated with Awesome Motive. PushEngage says it found no indication the attacker reached its primary product systems or the servers holding customer data; the intrusion was limited to the CDN-delivered JavaScript. Sansec observed the same sequence of steps in the malicious payload across all three plugins.

The attacker’s hidden plugin is the main long-term threat. It provides a web shell – a remote command interface – so anyone who knows the correct URL can execute code on the server without authenticating. From that foothold an attacker can read or alter files, dump databases, install additional backdoors, inject card-skimming or other malicious scripts, redirect visitors, and steal data. The extra administrator account is a simple fallback if the hidden plugin is removed but the account is overlooked. Because the attacker can run arbitrary code, removing the visible artifacts (the named plugin or account) may not clear all persistence; both Sansec and PushEngage advise assuming additional backdoors could remain.

Where the attacker got the ability to modify CDN-delivered files is disputed. PushEngage says the actor first compromised the server that hosts its marketing website by exploiting a known vulnerability in the UpdraftPlus backup plugin; that server contained a CDN API key. With that key the attacker could change files the CDN was serving to customer sites without touching PushEngage’s main application or customer-data servers. Sansec, however, says the exact breached system has not been conclusively determined – Awesome Motive’s own infrastructure, a CDN account, or other components remain possible – and it does not endorse the UpdraftPlus explanation in its public analysis. The UpdraftPlus flaw in question is CVE-2026-10795, an authentication-bypass issue that Wordfence scored 8.1 (high); it has been patched and Wordfence reported active exploitation, so operators of UpdraftPlus should update regardless of whether it was involved here.

Additional forensic detail: Sansec notes the tidio[.]cc domain used by the attacker was registered on April 28, several weeks before the June 12 activity, suggesting the operation was premeditated rather than an opportunistic hit-and-run. The domain and the attacker-controlled IP address 84.201.6.54 were used in command-and-control and exfiltration behavior observed by Sansec.

Sansec’s timeline indicates OptinMonster and TrustPulse files were serving clean scripts by June 13, while some PushEngage CDN servers continued to serve the altered script through June 14. PushEngage says it has since replaced the compromised files, purged CDN caches, rotated the CDN key and related credentials, and moved its marketing site to new infrastructure. Those remediation steps are important, but they do not disinfect customer sites that already executed the malicious payload.

Practical detection and response guidance (treat these as a minimum): if your site used PushEngage, OptinMonster or TrustPulse within the exposure windows above, perform a server-side investigation – do not rely on viewing the WordPress dashboard. Because the backdoor hides from admin screens, filesystem and log-level inspection on the server is the only reliable approach.

Recommended steps

• Run a server-side malware scan and forensic review if any of the three plugins were active during June 12-14 UTC. A browser or dashboard check can miss payloads that only ran for logged-in admins.
• Inspect the filesystem under wp-content/plugins for suspicious folders. Sansec identified folders named content-delivery-helper (labelled “Content Delivery Helper”) and database-optimizer (“Database Optimizer”) as indicators of the dropped backdoor; trust what you find on disk, not only what the dashboard shows.
• Remove any administrator accounts you did not personally create – especially accounts with names like developer_api1 or any username matching dev_xxxxxx.
• Audit web server access logs for signs of outbound connections or callbacks from June 12-14 UTC to tidio.cc (including any /cdn-cgi/ paths) and to the attacker-controlled IP 84.201.6.54. Any such hits should be treated as evidence of compromise.
• Rotate all credentials and secrets: administrator passwords, API keys, database user credentials, and the authentication salts and keys in wp-config.php. If an attacker had remote code execution, additional persistence may exist, so assume credentials could be exposed.
• If you find evidence of compromise, conduct a full rebuild from known-good backups and restore to clean infrastructure; simply deleting the visible plugin or account may leave other backdoors intact.