Brevo Breach Turns CDN Edge Into Attack Path

A long-lived Cloudflare API key, hardcoded in application source and forgotten, gave attackers the ability to rewrite web content at the network edge rather than on Brevo's own servers. For roughly five and a half hours, visitors to Brevo's pages and to customer sites embedding Brevo components saw a fake Cloudflare verification screen, then instructions to run a command on Windows. The incident is a reminder that the edge layer is part of the attack surface, not just the delivery mechanism.

Brevo, a customer relationship management and digital marketing company, has now published its own account of what happened. Security firm Sansec first reported the activity. The two accounts agree on the shape of the intrusion but differ on scale: Brevo describes a contained edge compromise; Sansec said it may have touched up to 100,000 websites that embed the affected Brevo components.

A key that opened every door

The root cause, per Brevo's write-up, was a Cloudflare API key with full account permissions that had been embedded directly in application source code. Because it carried full rights, it allowed the attackers to create Cloudflare Workers, routes, and DNS records across Brevo's zones without tripping an alert.

That key may have been compromised as early as late August, Brevo said, though the company added there is no evidence of malicious activity before the September event. The exposure window Brevo defines is narrow: 16:07 to 20:30 UTC on September 14. Sansec's own timeline puts the start slightly earlier, between 16:05 and 20:13 UTC on September 14, 2026.

The pages Brevo lists as affected include brevo.com, sendinblue.com, login/account/my/onboarding.brevo.com, and sibforms.com. More consequentially for third parties, the malicious Worker also modified the Brevo forms script, the Brevo Conversations widget, and the Brevo SDK loader scripts that customers embed on their own websites.

Why origin checks stayed quiet

The technique's advantage was that it never touched Brevo's origin infrastructure. A Cloudflare Worker intercepts and rewrites responses as they pass through the CDN, so the files sitting on Brevo's servers stayed exactly as they were.

Because the Worker rewrote responses at the edge and removed security headers such as Content-Security-Policy, our origin servers and files remained unmodified and standard integrity checks did not detect the change.

— Brevo

That explanation matters beyond this one incident. Integrity monitoring, file-hash comparisons, and server-side change detection all assume the malicious content exists somewhere you can inspect. When the rewrite happens in transit, those controls look at clean files and report clean results. Brevo also noted that the Worker stripped security headers including Content-Security-Policy, removing a browser-side control that might otherwise have limited what the injected scripts could do.

The ClickFix chain and the fake plugin

What visitors encountered was a two-stage lure. First came a fake Cloudflare verification page; then ClickFix-style instructions pressing them to run a command on Windows. ClickFix social engineering depends on convincing a user to execute code themselves, which sidesteps the need to exploit a browser or server vulnerability.

On WordPress sites that embedded an affected Brevo widget, the injected script went further. According to the reporting, it checked whether the current visitor was logged in as a WordPress administrator and, if so, attempted to upload a malicious plugin from

Sansec reported it could not retrieve the archive. BleepingComputer later found it on VirusTotal and described it as masquerading as a WordPress plugin named Web Media Optimizer while behaving as a persistent backdoor and JavaScript loader. Other domains seen distributing the plugin and scripts include and

Once installed, the plugin hides itself from the WordPress plugin list, copies itself into the must-use plugins directory to survive removal, and periodically contacts an attacker-controlled server at That URL was reported to be returning a Base64-encoded address pointing to JavaScript the plugin injects into visitors' pages. At the time of reporting, that decoded to which fetches a ClickFix lure for display.

The plugin also keeps a backup copy of the last valid JavaScript URL, so it can keep loading malicious code if the remote server goes dark. And it contains a hardcoded authentication key that lets attackers mint a valid login session for a WordPress administrator account without knowing the password.

Brevo's containment steps

Brevo said it detected the compromise and removed the Worker and its routes, then moved through a sequence of cleanup actions: revoking the compromised key and any credentials created with it, stripping the hardcoded credential from its source code, deleting attacker-controlled hostnames, and purging its edge caches.

The company also drew a boundary around what it says was untouched. According to Brevo, app.brevo.com, its API, its email delivery infrastructure, and customer account data were not affected. Sansec separately confirmed that all malicious subdomains stopped resolving on September 15 and that Brevo files are now clean.

Brevo did not answer BleepingComputer's questions about whether this incident and a separate SSO-related event were connected.

An earlier, separate account hijack

The overlap in timing is difficult to ignore even though the two events are distinct on the public record. On September 10, Brevo disclosed a different SSO-related incident in which attackers hijacked customer accounts and launched phishing attacks aimed at customers of companies using Brevo.

One high-profile victim was cryptocurrency wallet vendor Trezor, which reported on September 11 that phishing attacks reached 347,000 user email addresses and successfully compromised at least 2,500.

Whether the same actor or the same access path links the SSO hijacking to the Cloudflare key theft remains an open question. Brevo's decision not to answer that question leaves investigators and affected customers to assess the two independently.

What administrators should check

The practical fallout lands on WordPress administrators who happened to be logged in while visiting an affected site on September 14. The advice is specific rather than general: check for unusual plugins installed or activated that day and remove them if found. If anything suspicious turns up, rotate administrator passwords as well.

That recommendation follows directly from how the payload behaves. A plugin that hides from the plugin list, installs itself as a must-use plugin, and holds a hardcoded key for generating administrator sessions is not something a routine glance at the dashboard will reveal.

The timeline also gives affected parties a bounded window to work with. Brevo's stated exposure period runs from 16:07 to 20:30 UTC on September 14; Sansec's runs from 16:05 to 20:13 UTC the same day. Either way, the relevant question is what happened on customer systems during those hours, not what happened afterward.

The edge as an unmonitored layer

Several elements of this incident point at gaps that are common rather than exotic. A credential with full account permissions sat hardcoded in source code, which is exactly the kind of secret that outlives the developer who added it. The attack surface it opened was a CDN configuration layer that many organizations treat as infrastructure plumbing rather than a place where content can be altered.

Because the alteration happened at the edge, the standard detection story failed in a specific and understandable way: origin files were clean, so origin-based integrity checks passed. That is not a failure of any single tool so much as a blind spot created by trusting one layer's view of the truth.

For downstream customers, the more uncomfortable lesson concerns embedded third-party scripts. A marketing forms widget or SDK loader is code running on someone else's site with the site owner's implicit trust. When the vendor's delivery path is compromised, every site embedding that component inherits the exposure, whether or not the site itself did anything wrong.

Why it matters

The consequences for readers split by role. For WordPress administrators, the immediate actions are the ones laid out above: audit for plugins installed or activated on September 14 and rotate administrator credentials if anything looks off, because a planted plugin of this design may not surface in the admin interface at all. For businesses that embed third-party JavaScript, this incident suggests the trust boundary extends to every vendor in the chain, including those whose code never touches a server you control. For the industry, the reliance on origin-side integrity checks looks like an assumption worth re-examining, since an attacker who can rewrite responses in transit can leave every file you inspect completely untouched. None of that requires concluding anything about the connection between the two Brevo incidents; it follows from how this one worked.