For roughly four hours on the afternoon of September 14, a sign-up form asking visitors for their email address was also, on more than a hundred thousand websites, asking them to run a command on their own computer. The form looked normal. The site was legitimate. The site owner had done nothing wrong. And the malicious code was never on their server at all.

That last detail is what makes the Brevo incident worth more than a passing glance. The customer-engagement and email marketing platform, formerly Sendinblue, confirmed that attackers used a stolen Cloudflare API key to stand up a malicious Worker that rewrote its own JavaScript in transit. The files on Brevo’s origin servers stayed clean throughout. Every integrity check that assumes a bad script means a bad file came back green.

A bad week that got worse

It started earlier. On September 10, Brevo disclosed that an attacker had exploited a flaw in how it handled SAML single sign-on, reaching 138 customer accounts. Six were used to blast out phishing email. Forty-three had contact lists exported, the quieter and more durable damage: those addresses are now inventory for whoever wants them next.

The targets skewed toward cryptocurrency. Customers of hardware wallet makers and portfolio trackers got mail that appeared to come from vendors they trusted, including a fabricated security alert sent to roughly 347,000 subscribers of one wallet company’s newsletter. That is the whole value proposition of breaching an email provider. You do not need to spoof a sender when you can borrow one.

The credential that should never have been long-lived

Brevo says the second attack ran on a Cloudflare API key with full account permissions, hardcoded in application source code. Its own accounting places the first misuse of that key in late August, though it maintains no malicious content reached customer-facing pages before September 14.

Hardcoded, long-lived, fully privileged. Anyone who has spent time in a real codebase knows how ordinary that combination is. It gets committed during a migration, it works, nobody rotates it, and it sits in the repository accruing risk until someone with different intentions reads the same file.

With that key, the attackers never needed to touch Brevo’s servers. They deployed a Worker at the content delivery edge that modified responses on the way out, injecting a loader into the JavaScript that Brevo customers embed on their own sites: the form script, the Conversations chat widget, and an SDK loader. The Worker also stripped security response headers, including Content-Security-Policy, the exact control a defender would rely on to block an unexpected script origin.

Two payloads, two kinds of victim

What arrived next depended on who was looking.

If you were a visitor

Ordinary visitors got a full-page overlay impersonating a familiar “verify you are human” challenge. This is the ClickFix pattern, and it works for one reason: it does not exploit the browser. It exploits a user’s willingness to obey a page that looks like infrastructure. The overlay quietly placed a command on the clipboard and walked the visitor through running it. No vulnerability, no patch, no exploit chain to detect. Just a convincing rectangle and a trusting person.

If you were a logged-in WordPress administrator

Anyone browsing their own WordPress site while logged in as an administrator got the targeted version. The script used that live session to attempt a silent plugin upload and activation, under a name built to look like a routine performance tool. Researchers describe the payload as a persistent backdoor and script loader that hides from the plugin list, copies itself into WordPress’s must-use plugin directory so it loads on every request, and carries hardcoded credentials granting administrative access without a password.

Because it hides from the console, a clean-looking plugin screen means nothing. The files on disk are the only honest source.

Why the usual defenses were blind

Subresource integrity, the browser feature built for exactly this scenario, is rarely usable with a marketing tag, because those scripts are meant to change without notice. Content-Security-Policy would have helped, except the Worker was stripping the header before browsers saw it. File integrity monitoring on the site owner’s server had nothing to find, and neither did Brevo’s.

The signal that did show up came from sites running CSP violation reporting: a monitored sample of a dozen sites produced more than 2,500 reports during and after the window. Passive reporting caught what active blocking could not.

The attacker hostnames stopped resolving on September 15. Brevo revoked the key, removed the hardcoded credentials, deleted the attacker-created hostnames, purged edge caches, and forcibly signed out platform users. It says its application, API, email delivery pipeline, and stored account data were untouched, and it has declined to say whether the two September incidents share an author.

What site owners should do?

  • Establish whether any page on your site loaded a Brevo form, chat widget, or SDK script between roughly 16:00 and 21:00 UTC on September 14.
  • Pull web server logs for that day and hunt for WordPress plugin upload and activation requests, especially ones tied to an administrator session.
  • Compare the plugin directories on disk against what the WordPress admin screen displays. Disagreement between the two is your finding.
  • Inspect the must-use plugin directory specifically. Most administrators have never looked at it, which is why it was chosen.
  • Reset administrator passwords, invalidate sessions, rotate Brevo credentials and any API keys reachable from an admin account, then review the account for unfamiliar sending activity or contact exports.
  • Treat any machine where someone ran a command from a fake verification prompt as compromised, not merely suspect. Warn visitors who may have seen one.
  • Preserve September logs now, before retention deletes the evidence.
  • Turn on CSP reporting even where you cannot enforce a policy. Report-only mode costs nothing and produces a timestamped record.
  • Inventory every third-party script on your site and ask what each one could do if it turned hostile tomorrow.

What This Means

Every embedded tag on a website is a standing invitation, renewed on every page load, for someone else’s infrastructure to run code in your users’ browsers with your domain’s authority behind it. The industry has known this for a decade and decided to live with it, because the alternative is giving up the marketing stack entirely.

Fine. But living with it honestly means treating vendor script domains as part of your attack surface, not someone else’s problem, and it means vendors stop keeping permanent, unscoped credentials in their repositories. A key with full account permissions and no expiry is not a configuration detail. It is a single point of total failure, and here it was enough to turn a company’s entire customer base into a malware distribution network for an afternoon.

Brevo moved fast once it knew and published an unusually specific account of its own failure, more than many companies manage. That does not undo four hours of a hundred thousand sites serving attacker-controlled code. The uncomfortable part is how repeatable this is. The technique needed no exploit, no malware, no foothold on the victim’s infrastructure. It needed one credential and an understanding that modern web content is assembled at the edge, where almost nobody is watching.