Security Incident: Tampered Script Served via OptinMonster and TrustPulse

Summary

We are responding to a security incident affecting OptinMonster and TrustPulse. An attacker gained access to a credential for our content delivery network (CDN) and used it to serve a tampered version of the JavaScript file that these products deliver to customer sites. For a limited window, sites that embed our script loaded this modified file directly from our CDN.

The malicious code only activated for logged-in WordPress administrators. When it ran on an affected site, it attempted to create a hidden administrator account and install a concealed backdoor plugin, then sent data to an attacker-controlled server. Ordinary site visitors were not targeted, but because the code can hand an attacker control of a site, any affected site should be treated as compromised.

Scope – what was and wasn’t reached: 

Our application servers, our source code, and the systems that store your OptinMonster and TrustPulse account information are hosted separately and were not breached. We have no evidence that account data or personal details held by us were accessed. The compromise was limited to our marketing website server and, through a CDN API key stored on it, our CDN account. Importantly, this does not reduce the urgency for affected site owners: the file delivered to your site was tampered with, which is why the steps below still matter if you were in the exposure window.

Who needs to act now: If your site had OptinMonster or TrustPulse active and an administrator was logged in during the exposure window below, please treat your site as compromised and follow What to check and do right away. The most reliable checks happen on your server, not in the WordPress dashboard.

Exposure window

Based on our CDN provider’s logs, the unauthorized configuration with tampered files was in place for approximately a few hours on June 12, 2026 (UTC). We are continuing to confirm the precise period during which affected content was served, and will update this notice as additional details are verified.

Only sites that loaded the affected script with an administrator logged in during this window could have been compromised.

The affected files were the standard embed scripts served from:

a.omappapi.com/app/js/api.min.js     (OptinMonster)
a.opmnstr.com/app/js/api.min.js      (OptinMonster)
a.optnmstr.com/app/js/api.min.js     (OptinMonster)
a.trstplse.com/app/js/api.min.js     (TrustPulse)

What happened

An attacker exploited a known vulnerability in a third-party WordPress plugin (UpdraftPlus) to gain access to the server hosting our marketing website. This server is entirely separate: different host, different infrastructure from the application servers that run OptinMonster and TrustPulse and that store customer data.

On the marketing server, the attacker located an API key for our CDN account. Using that key, they did not need to touch our application origin at all. They modified the files our CDN was serving, so the tampered script was delivered to sites embedding it for a limited period before we detected and reverted the change.

We have since remediated the marketing site, migrated it to a new server, and rotated all credentials, including the CDN API key.

What the malicious code did

On an affected site, when a logged-in administrator loaded a page, the code attempted to:

1. Confirm it was running in a WordPress admin context, then collect the security tokens needed to act as that administrator.
2. Create a hidden administrator account. Known accounts include developer_api1 ([email protected]) and randomized accounts of the form dev_xxxxxx.
3. Install a self-hiding backdoor plugin that conceals itself from the dashboard and exposes an unauthenticated web shell and code-execution endpoint — effectively granting full control of the site.
4. Send the new credentials and site details to an attacker-controlled server.

Because the backdoor hides from the WordPress admin screens, the dashboard alone will not tell you whether you’re affected. The reliable checks are on the server filesystem and via a server-side scan.

What to check and do

If you had OptinMonster or TrustPulse running on your website AND an administrator logged in to your WordPress site during the exposure window, do the following as soon as possible. If you’re unsure whether an admin was logged in, it’s safer to check.

1. Remove rogue administrator accounts. Look for developer_api1 / [email protected] and any unexpected dev_xxxxxx accounts, and delete them.

2. Check the filesystem – not just the dashboard — for the backdoor plugin. Under wp-content/plugins, look for content-delivery-helper (“Content Delivery Helper”) or database-optimizer (“Database Optimizer”). The disguise rotates, so trust what’s on disk over what the dashboard shows. Remove any you find.

3. Run a server-side malware scan. Because the payload only ran for logged-in admins, dashboard and client-side checks are unreliable; a server-side scan is the most dependable way to find the backdoor or any further changes.

4. If you find any indicator above, assume full compromise and rotate everything: administrator passwords, application/API keys, database credentials, and your WordPress security keys/salts in wp-config.php. The backdoor allowed arbitrary code execution, so additional persistence may exist.

If you find none of these indicators and had no administrator logged in during the window, your site is very likely unaffected and no action is required beyond standard hygiene (enable two-factor authentication, keeping software updated).

What we’ve done so far

• Detected the tampering and quickly reverted the affected CDN files; purged the CDN cache so clean files are served.
• Revoked and rotated the CDN API key and all related credentials.
• Remediated the compromised marketing website and migrated it to a new server on separate infrastructure.
• Confirmed that our application servers, source code, and customer-data systems which are on a separate infrastructure show no evidence of unauthorized access.
• Engaged our security team and are working with our CDN provider to obtain detailed delivery logs.

Status and ongoing risk

Our CDN configuration has been corrected and the tampered files removed, the affected credentials have been rotated, and the entry point on our marketing server has been remediated.

Remediating our systems does not clean a site that was already compromised. If your site was affected during the exposure window, the rogue administrator account and hidden backdoor plugin remain in place until you remove them using the steps above. We recommend acting promptly. We will update this page if additional relevant information emerges.

Indicators of compromise

For site owners and security teams:

Rogue accounts:
  developer_api1 / [email protected]      (fixed operator account)
  dev_xxxxxx / [email protected]            (randomized accounts)

Backdoor plugin disguises (rotating; check the filesystem):
  content-delivery-helper   "Content Delivery Helper"   v2.7.1
  database-optimizer        "Database Optimizer"        v2.9.4

Attacker infrastructure:
  tidio.cc   (lookalike domain — NOT the legitimate tidio.com)

Unique strings:
  jX9kM2nP4qR6sT8v            (encryption key used by the malware)
  WPM File Manager & Shell    (backdoor shell interface)

Contact

If you have questions, need help checking your site, or notice anything unusual, contact us at [email protected]. We’re prioritizing incident-related inquiries and will keep this page updated.

Protecting our customers is a priority for us. We understand this incident may be concerning, and we regret any disruption it has caused. The information above reflects our investigation to date, and we will update this page as additional details are confirmed.