WordPress: 1.2 Million Sites Exposed After OptinMonster Hack
A supply chain attack affected three WordPress plugins published by Awesome Motive: OptinMonster, TrustPulse and PushEngage. This major security incident exposed more than 1.2 million WordPress sites to compromise, underscoring just how popular these plugins are. Using this method, attackers were able to inject malicious JavaScript into files distributed through the plugins’ official CDN. Here is what we know.
A Compromised CDN API Key Sparked the Fire
This new supply chain attack was detected by Sansec, which reported on June 13, 2026 that malicious code was being served through JavaScript files hosted on the OptinMonster, TrustPulse and PushEngage CDN. By hijacking a trusted resource, the attackers were able to reach thousands of WordPress installations without having to target each one directly. Yet another clear example of the risks tied to the supply chain, even if these days we are more used to package compromises on NPM or GitHub.
Awesome Motive, the publisher of these plugins, confirmed the incident and says it all started with the compromise of an API key that provided access to its CDN. Awesome Motive also states that the attackers did not gain access to application servers, customer accounts, or even the source code.
The intrusion was limited to the CDN, but that was enough to alter the JavaScript files served to the WordPress sites of users of these three plugins, without ever accessing OptinMonster’s infrastructure. The exposure window is believed to have lasted only a few hours on June 12, 2026, although the investigation is still ongoing. Fortunately, that must have limited the damage.
If you are wondering how the attackers got their hands on this API key, they reportedly exploited a security flaw in another WordPress plugin: UpdraftPlus (a WordPress backup plugin). It was installed on a WordPress site used by Awesome Motive’s marketing team. This reminds me of a critical security flaw patched in UpdraftPlus in early June 2026. I do not know whether this is the vulnerability that was exploited, but it could fit.

Malicious Actions Performed on the WordPress Side
What happens on compromised WordPress sites? First, Sansec’s analysis highlights an important detail: the injected JavaScript only executed when an authenticated WordPress administrator visited an affected site. Once triggered, the code retrieved WordPress security tokens, attempted to create administrator accounts, and installed a hidden plugin acting as a backdoor for persistent remote access.
The researchers explain that this account is created through the WordPress API. In particular, there is an account named developer_api1, tied to the address customer1usx@gmail.com. But it is not the only one: secondary administrator accounts, with a more random name (in the format dev_xxxxxx), are also created.
Beyond checking the administrator accounts on your WordPress site, look at the plugins. However, they may not necessarily be visible through the WordPress admin interface, because they are hidden. You therefore need to check the WordPress file system: inspect the wp-content/plugins directory on your hosting environment.
The backdoor was designed to stay under the radar: it hid from plugin lists, user interfaces, update checks and API responses. Sansec identified two disguises used during the campaign:
"The operator changes the plugin name while preserving byte-for-byte identical logic during name changes. We observed it being distributed as ‘Content Delivery Helper’ (content-delivery-helper, v2.7.1) and, currently, as ‘Database Optimizer’ (database-optimizer, v2.9.4).", reads the SanSec report.


