OptinMonster Supply Chain Attack Hits 1.2 Million WordPress Sites

1.2 million WordPress sites were caught in a supply chain attack last week, where the admin’s own login quietly created a secret account and planted a hidden backdoor. It came in through plugins they trusted, OptinMonster, TrustPulse and PushEngage, and it only fired on the sites where an administrator was logged in.

Sansec found it on 13 June 2026. The poisoned script belonged to three popular WordPress plugins: OptinMonster, TrustPulse and PushEngage, all run by the same company, Awesome Motive. These plugins do the small marketing jobs many sites rely on, popups, social proof notifications and browser push messages. To do that, each one loads a little piece of JavaScript called an SDK from the vendor’s own content delivery network, the CDN. That SDK is the part the attacker tampered with.

The sites did not get a bad update, the plugins on them were untouched and fully up to date, and they kept working as normal. The swap happened at the CDN, on the vendor’s side, so a site that did everything right still pulled in the tampered script the moment a browser asked for it.

The poisoned code was added to the end of the real, minified SDK file. The genuine code kept working, so popups still appeared and notifications still showed, and the owner saw a site that behaved exactly as it should while the added code did its own work in the background.

Researchers at Patchstack took apart a captured copy of the payload. It moves in stages, and each stage is built to stay quiet.

First, it tries not to get caught. Before doing anything, the script checks whether it is running inside automated tooling or a researcher’s sandbox. It looks for signs like navigator.webdriver, headless browser markers such as window._phantom and window.__nightmare, and browser windows with no size. Then it checks that it is sitting in a real WordPress admin screen by looking for the admin bar, /wp-admin/ paths and the wordpress_logged_in_ cookie. If there is no logged in administrator in front of it, it stops and does nothing. It also drops a marker in the browser so it will not run again on the same machine for 24 hours.

Second, it needs permission to act as the admin. WordPress protects sensitive actions with a one time token called a nonce. The script harvests a valid nonce straight from the page, from wpApiSettings, from admin-ajax.php, or by reading the new user page. With that nonce and the administrator’s own login cookie, it can now send requests that WordPress treats as coming from the real admin.

Third, it creates a new administrator account, and it tries four ways in a row until one works:

• → the REST API, with a POST to /wp-json/wp/v2/users asking for the administrator role
• → the normal admin form at /wp-admin/user-new.php
• → an AJAX call to /wp-admin/admin-ajax.php
• → a hidden 1 by 1 pixel iframe that loads the new user page, fills it in and submits it

A representative request looked like this:

1
2
3
4
5
6
7

POST /wp-json/wp/v2/users
{
  "username": "dev_3m6nyp",
  "email": "dev_wvi65g@gmail.com",
  "password": "lSwI4oUwH%&uCZ@7NW2*",
  "roles": ["administrator"]
}

It planted a fixed account named developer_api1 with the email customer1usx@gmail.com, and a randomized version with names in the pattern dev_xxxxxx. It even carried a small dictionary of “user already exists” messages in around twenty languages, so it could tell on a WordPress install in another language whether the account was created or was already there.

Fourth, now holding admin rights, it installed a backdoor that hides itself. It downloaded a generated ZIP from the attacker’s server and uploaded it as a plugin through /wp-admin/update.php. The plugin disguised itself under harmless looking names like “Content Delivery Helper” or “Database Optimizer”, and then removed itself from the plugin list, the user list, the updates screen and the activity log. Sansec found that this plugin opens a web shell through the parameter ?developer_api1_fm that runs system commands, plus a second endpoint, developer_api1_eval, that runs attacker supplied code.

Fifth, it sent the results out. The data was scrambled with an XOR key, encoded, and shipped to a server at tidio.cc using several fallback methods so it got out even if one was blocked.

At the network level, WordPress sees its own administrator doing all of this. The rogue requests carry the real session and a valid nonce, because it is the administrator’s own browser sending them. A request that creates a new admin looks almost the same as a real admin adding a user. The administrator is the victim here, not the attacker.

The attacker left a few traces that show planning. The command server, tidio.cc, was registered on 28 April 2026 and given a TLS certificate, six weeks before the attack ran. The name is a near copy of tidio.com, a real live chat service many sites load, so traffic going to tidio.cc draws less attention. The paths it used for sending stolen data were named /cdn-cgi/..., which is the path Cloudflare uses for its own traffic, so the beacons sit among normal Cloudflare requests. The domain pointed to an IP at the hosting provider Ultahost.

One more detail stands out. In Patchstack’s own detection logs, the rogue admin attempts came from 81 different IP addresses across 13 sites, on a wide mix of consumer devices, around 60 percent mobile and the rest desktop. That is what shows up when the code runs inside the browsers of real administrators on home and mobile connections, rather than from one central attacker machine.

The timing had a twist. OptinMonster and TrustPulse, the two with the most sites, served the tampered script for only about 25 minutes on 12 June. PushEngage, with far fewer installs, kept serving it the longest, into 14 June.

No group has been publicly named for this one yet. In cybersecurity, attribution is one of the hardest problems. IP addresses can be spoofed, tools can be shared between groups, and clues in code can be planted to point at the wrong people. What we know for certain is how the malware works, not who wrote it.

This was not a one off. WordPress had two other supply chain hits in the months before. An attacker bought more than 30 plugins from a vendor called EssentialPlugin through the open marketplace Flippa, planted a dormant backdoor in their code in 2025, and switched it on eight months later, in April. That same week, the premium plugin Smart Slider 3 Pro received a poisoned update from its own developer’s update servers, and that backdoor created hidden admin accounts that stayed alive after the plugin was removed. That makes three different ways in within a few months, all abusing the trust sites place in an official update or delivery path. Sansec also pointed back to the 2024 Polyfill case, where a widely loaded script turned hostile after the domain behind it changed hands.

How the attacker first got in is still open. Awesome Motive says someone used a known bug in the UpdraftPlus plugin to reach the server hosting its marketing site, found a CDN API key stored there, and used that key to swap the SDK files at the CDN. Sansec has not confirmed the UpdraftPlus part, and that account only covers the vendor’s own environment. UpdraftPlus does have a separate, now patched authentication bypass bug, CVE-2026-10795, that has been attacked in the wild, so people running it should update regardless.

The same company runs bigger plugins too. WPForms sits on more than six million sites, All in One SEO on around three million, and MonsterInsights on around two million. Only the three marketing plugins were caught serving tampered code, but the attacker had reached the vendor that builds the rest, which is why people running another Awesome Motive plugin had reason to check their own sites.

A network firewall does not help much here. It cannot stop a browser from loading the CDN script, and it cannot read the encrypted beacon to tidio.cc, because that traffic goes to a different domain. The reliable signal is the attacker’s own markers, the specific account names and backdoor parameters, which is why the steps below hunt for those exact values.

If a site ran OptinMonster, TrustPulse or PushEngage and an administrator opened a page on it between roughly 12 and 14 June 2026, treat the site as compromised and check it by hand. Fixing the vendor’s CDN does not clean a site that was already hit.

• → Audit administrator accounts. Remove developer_api1 and anything matching dev_xxxxxx, then review the rest of the admin list for names you do not recognise.
• → Check the filesystem, not the dashboard. The backdoor hides from the admin screens, so look directly in wp-content/plugins/ for content-delivery-helper or database-optimizer, and search the codebase for developer_api1_fm, developer_api1_eval and the XOR key jX9kM2nP4qR6sT8v.
• → Run a server side malware scan to catch anything beyond the known names.
• → If you find a compromise, rotate everything: admin passwords, API keys, database credentials, and the security keys and salts in wp-config.php.
• → Block the command server tidio.cc at the DNS or network level.

The indicators to look for:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Rogue admin (fixed):    developer_api1 / customer1usx@gmail.com
Rogue admin (random):   dev_xxxxxx / dev_xxxxxx@gmail.com
Backdoor plugins:       content-delivery-helper , database-optimizer
Backdoor parameters:    ?developer_api1_fm , developer_api1_eval
Command server:         tidio.cc  (Ultahost)
XOR key:                jX9kM2nP4qR6sT8v

Tampered CDN files:
  a.omappapi.com/app/js/api.min.js
  a.opmnstr.com/app/js/api.min.js
  a.optnmstr.com/app/js/api.min.js
  a.trstplse.com/app/js/api.min.js
  clientcdn.pushengage.com/sdks/pushengage-web-sdk.js
  clientcdn.pushengage.com/sdks/pushengage-subscription.js

A site can be patched, locked down and well run, and still load a hostile file, because the weak point was a script it pulled in from somewhere else while it was running. The plugins you install are not the only thing to watch. The third party scripts those plugins load while an admin is logged in can do just as much damage, and they deserve the same suspicion as the code you installed yourself.

This attack came in through a trusted script, used an administrator’s own logged in session, grabbed the token that made its requests look legitimate, planted a hidden backdoor, and sent the results to a server the attacker controlled. Sessions and tokens, backdoors and persistence, and the way data leaves a system are part of what my ethical hacking course works through step by step, so you can spot an attack like this and test for it yourself:

• → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources: Sansec | Patchstack