The Brevo Breach Shows How One Edge Credential Can Turn a Trusted Web Widget Into a Supply-Chain Attack

The September 14, 2026 Brevo compromise shows that a trusted third-party web service can become a mass supply-chain delivery channel even when its origin files remain unchanged. Attackers used a compromised, long-lived Cloudflare API key to create a Cloudflare Worker that rewrote responses at the edge, injecting malicious JavaScript into Brevo pages and into scripts embedded by customer websites.

The result was a two-sided attack: visitors could receive ClickFix social-engineering prompts, while logged-in WordPress administrators on sites using affected Brevo widgets were targeted for malicious plugin installation.

What happened on September 14

Brevo disclosed a post-mortem after attackers used a compromised Cloudflare API key to deploy a malicious Worker in its account. Brevo's status history records the September 14 incident as "Security Incident - ClickFix" and says the issue was resolved and a post-mortem published.

According to Brevo's account as reported by independent security researchers and reporting, the key had full permissions and had been hardcoded in application source code. That level of access allowed the attacker to create Workers, routes and DNS records across Brevo's Cloudflare-managed zones.

The Worker rewrote HTTP responses at the edge rather than modifying Brevo's origin files.

That distinction is the central security lesson.

The attack crossed the SaaS boundary through shared JavaScript

Brevo operates web components that customers embed into their own sites, including forms, a conversation widget and SDK scripts.

The malicious Worker modified Brevo-hosted JavaScript that customer sites load directly. Sansec independently observed injected loader code in the Brevo SDK loader and conversation widget, along with injected content on Brevo-controlled pages and forms.

That created an amplification path:

Brevo Cloudflare credential
        ↓
malicious edge Worker
        ↓
Brevo-hosted JavaScript
        ↓
customer websites
        ↓
visitors + site administrators

The customer site did not need to be independently hacked for its visitors to encounter the injected payload.

The exposure window was measured in hours

Sansec observed malicious activity from approximately 16:05:18 to 20:12:53 UTC on September 14, 2026.

Brevo described its own exposure window as approximately 16:07 to 20:30 UTC.

Those windows differ slightly because the two investigations use different collection methods and definitions of the affected period.

Sansec also reported that the malicious hosts stopped resolving on September 15 and that the affected origin files were clean afterward.

The difference is worth preserving rather than collapsing into one apparently exact timestamp.

Why origin integrity checks did not catch the change

Brevo said the Worker rewrote responses at the Cloudflare edge and removed defensive headers including Content-Security-Policy.

Because the origin files themselves were not modified, conventional file-integrity checks could continue to report clean files while browsers received modified responses.

This is a different security boundary from a traditional server compromise.

A simplified model is:

origin file
    ↓
CDN / edge transformation
    ↓
HTTP response
    ↓
browser

If defenders verify only the first stage, they may miss a malicious transformation in the second.

The visitor-facing payload used ClickFix

Sansec found that the injected JavaScript could present a fake verification experience to visitors and encourage them to copy and execute a command.

That technique is commonly called ClickFix: the attacker disguises malicious command execution as a troubleshooting, verification or CAPTCHA step.

The important point is that the supply-chain compromise did not require the attacker to convince each victim that Brevo itself was malicious. The trusted site and its legitimate web components supplied the context.

WordPress administrators faced a different payload

On sites using affected Brevo widgets, the malware checked whether the visitor was logged in to WordPress as an administrator.

Sansec initially reported that the script attempted to install a malicious plugin. BleepingComputer later reported recovering and analyzing a sample named Web Media Optimizer, finding persistent backdoor behavior and a JavaScript loader.

That distinction matters because Sansec's first report explicitly said it had not recovered the plugin archive, while later independent analysis provided additional evidence.

The strongest version of the claim is therefore: the attack included a malicious WordPress plugin payload that was later recovered and analyzed independently, rather than claiming every exposed site received or successfully installed it.

How large was the incident?

Sansec estimated that more than 100,000 websites using affected Brevo components could have been exposed.

That is an exposure estimate, not a confirmed count of successful infections.

There is no public evidence establishing that all of those sites served the malicious payload to a visitor, nor is there a public count of successful WordPress backdoor installations across that population.

This is exactly the kind of distinction the Observatory's measurement methodology requires: reported reach is not the same as confirmed compromise.

The earlier Brevo incident is related context, not proof of one campaign

Brevo had disclosed another security incident on September 10 involving its SAML SSO organization mechanism. Independent reporting said attackers accessed customer accounts and used some of them for phishing and contact export.

The September 14 Cloudflare-key incident happened only days later.

That timing is notable, but it does not prove that the same actor carried out both operations. Sansec explicitly leaves attribution unresolved, and Brevo's later post-mortem does not establish a common actor.

The correct interpretation is therefore two closely timed Brevo security incidents with no established public attribution linking them.

What this changes for third-party JavaScript security

The incident illustrates why third-party JavaScript is a supply-chain dependency even when it is loaded from a reputable vendor.

A site owner can protect its own origin, CI pipeline and application repository while still depending on an external script whose content can change before it reaches the browser.

That makes several controls more important:

• inventory externally hosted JavaScript;
• minimize high-privilege scripts on sensitive pages;
• use Subresource Integrity where it is technically appropriate;
• monitor unexpected changes in third-party assets;
• monitor browser-side Content Security Policy violations;
• distinguish origin integrity from response integrity; and
• keep cloud-edge credentials short-lived and narrowly scoped.

These are defensive implications, not evidence that every control would have prevented the Brevo incident.

Why this is different from a normal web compromise

A conventional website compromise usually starts with the application, server or deployment pipeline.

Brevo demonstrates another path: compromise the infrastructure that sits between the clean origin and the browser, then exploit the trust relationship created by widely embedded JavaScript.

The same general class of problem has appeared in software supply chains, where one trusted dependency can amplify an attack across many downstream users. Here the dependency was a hosted web asset and the amplification mechanism was browser execution.

The Observatory's existing GitHub Actions security coverage looks at a different supply-chain boundary: CI execution triggered by repository events. Brevo shows the same trust problem from the web-delivery side.

What the evidence still cannot establish

Several details remain limited or uncertain:

• the exact initial theft path for the Cloudflare API key has not been publicly established;
• the identity of the attacker has not been established;
• the relationship, if any, between the September 10 SAML incident and September 14 edge compromise is unproven;
• the 100,000-plus figure is an estimated exposure population, not a confirmed infection count; and
• the percentage of visitors who received or acted on the ClickFix prompt is not publicly established.

Those limits do not weaken the core observation. The edge-control-plane compromise and downstream JavaScript injection are independently documented.

The deeper infrastructure signal

The Brevo incident is a useful example of how modern web systems create implicit transitive trust.

A customer embeds a vendor's script because the vendor is trusted. The browser then executes whatever that vendor's infrastructure serves. If the vendor's edge control plane is compromised, the customer's site can inherit the compromise without a malicious deployment in the customer's own repository.

That makes the security boundary larger than the application codebase.

The most defensible conclusion is therefore simple: the Brevo incident shows that protecting modern web applications requires monitoring not only source files and servers, but also the cloud edge and third-party browser-executed dependencies that sit between origin infrastructure and users.

Sources and further reading

• Brevo Status — Security Incident: ClickFix
• Sansec — Brevo supply chain attack
• BleepingComputer — Brevo supply-chain attack injected ClickFix scripts
• SecurityWeek — Brevo supply chain attack injects malware into 100,000 websites