Supply Chain · Vendor Access

Brevo Supply Chain Attack: How a Hardcoded API Key Put 100,000+ Sites at Risk

September 18, 2026 · 7 min read

When you embed a third-party marketing widget on your website, you are extending implicit trust to that vendor's entire infrastructure. The Brevo supply chain attack that played out on September 14, 2026 is a clean illustration of what that trust costs when a vendor leaves a high-privilege API key hardcoded in their application source code. A malicious Cloudflare Worker rewrote CDN-edge responses across Brevo's zones for roughly five and a half hours, pushing ClickFix social-engineering overlays and, on WordPress sites, attempting to silently install a backdoor plugin. Sansec estimates the exposure window touched more than 100,000 websites. If your site embedded any Brevo forms, chat widgets, or SDK loaders during that window, your visitors were the targets.

What actually happened

The mechanics of this attack are worth understanding in detail, because each step followed directly from a single upstream mistake. Brevo had a long-lived Cloudflare API key with full account permissions hardcoded in their application source code. Attackers extracted that key and used it to create a malicious Cloudflare Worker. Because Brevo's five apex domains (brevo.com, sibforms.com, sibautomation.com, sendinblue.com, and sendibt1.com) all resolve through the same Cloudflare account, one compromised key gave attackers DNS write access and edge-content rewrite capability across all of them.

The malicious Worker was active from approximately 16:05 UTC to 20:13 UTC on September 14, 2026, according to Sansec's CSP monitor. Brevo's own post-mortem puts the window at 16:07 to 20:30 UTC. During that time, the Worker modified the Brevo forms script, the Brevo Conversations widget, and the Brevo SDK loader scripts that thousands of customer sites embed. Visitors to those sites were shown a fake Cloudflare verification page followed by a ClickFix overlay urging them to run a command on Windows. Sansec also recorded the ClickFix overlay being triggered when users clicked unsubscribe links in Brevo-distributed campaign emails, extending the reach beyond site visitors to email recipients.

On WordPress sites where a logged-in administrator was detected, the script went further. It attempted to upload a malicious plugin from cdn10.sendibt1[.]com/p/wm.zip. The plugin posed as something called "Web Media Optimizer" but functioned as a persistent backdoor and JavaScript loader. It contained a hardcoded authentication key that would let an attacker generate a valid admin session without knowing the account password. The attacker-controlled infrastructure used subdomains under sendibt1.com, which is a legitimate Brevo email-tracking domain, making the traffic pattern harder to flag at a glance.

The malware included anti-analysis checks and stayed dormant against crawlers, developers, and automated scanners, which reduced the window for rapid detection. Sansec's CSP monitor recorded 2,549 violation reports across 12 sites during and after the attack. Remediation was confirmed by September 15, 2026: Brevo removed the Worker and its routes, revoked the compromised key, removed the hardcoded credential from source code, deleted the attacker-controlled DNS records, and purged edge caches. Brevo confirmed that app.brevo.com, its API, email delivery infrastructure, and customer account data were unaffected.

Sansec estimates the supply chain attack may have impacted up to 100,000 or more websites using affected Brevo components. PublicWWW identified 114,371 pages referencing Brevo, Sibforms, or Sibautomation resources at the time of reporting.

Worth noting alongside the September 14 incident: four days earlier, on September 10, 2026, Brevo closed a separate entry point at 8:30 AM UTC after an attacker exploited a flaw in SAML SSO handling that allowed cross-organization impersonation. That incident touched 138 Brevo customer accounts: 6 were used to send phishing emails, 43 had contacts exported, and 93 showed no meaningful activity. One affected customer was Trezor, and phishing emails reached approximately 347,000 user addresses, with roughly 2,500 users clicking the malicious link. Brevo has not confirmed or denied whether the September 10 SSO incident and the September 14 Cloudflare compromise are connected.

Why this should matter to you even if you don’t run Brevo

Brevo counts eBay, Louis Vuitton, Michelin, and Amnesty International among its clients. The organizations that embed Brevo widgets on their sites range from small e-commerce stores to large enterprises, and none of them had any visibility into the fact that a Cloudflare API key with full account permissions was sitting in Brevo's source code. That is the uncomfortable reality of the third-party script model: your attack surface now includes the operational security practices of every vendor whose JavaScript you load.

The ClickFix technique itself deserves attention. It is a social engineering pattern that presents a fake browser or system error, then instructs the user to open a Run dialog and paste in a command. The fake Cloudflare CAPTCHA page Brevo visitors saw is a well-established delivery vehicle for this technique. It works because the visual presentation is familiar and the instruction feels like a routine troubleshooting step. For end users who are not security-trained, the friction is low enough that a meaningful number will comply.

The WordPress-specific behavior adds another layer of concern. The script checked for an authenticated administrator session before attempting the plugin upload. That means a WordPress site owner who was logged into their admin panel and visited a page embedding the compromised Brevo widget during the attack window was specifically targeted for persistent compromise, with a backdoor that would survive the attacker's initial access window. Detecting that afterward requires active plugin auditing, not just restoring from backup.

If your organization uses any marketing automation, chat, or form-embedding services, this incident is a direct prompt to ask how those scripts are loaded, whether you have a Content Security Policy that would surface unauthorized script modifications, and what your vendor's credential management practices look like. CSP violation reports were what gave Sansec early visibility here. Most organizations do not have that monitoring in place for third-party widget domains.

The control that would have blunted it

The primary control that would have reduced the blast radius here is least-privilege access management for vendor-controlled credentials, combined with secrets scanning and rotation policy. The Cloudflare API key at the center of this attack had full account permissions and was hardcoded in source code. A key scoped only to the specific zones and operations Brevo's application actually needed would have limited what an attacker could do with it. A secrets scanning step in the CI/CD pipeline would have flagged the hardcoded credential before it ever reached a production environment. Neither of these is a novel idea, but they are controls that organizations consistently skip under delivery pressure.

From a vendor access governance standpoint, the broader question is how much you actually know about the permissions your SaaS vendors hold on infrastructure that serves your users. Most vendor relationship reviews focus on data handling and contractual terms. They rarely get into whether the vendor has a long-lived, over-privileged API key sitting in their codebase that, if extracted, gives an attacker the ability to rewrite content served to your visitors. Cyber insurers increasingly ask about third-party access controls in application questionnaires, and this incident illustrates exactly why.

On the detection side, a Content Security Policy with a reporting endpoint is one of the more practical controls for this class of attack. It does not prevent the script modification, but it creates a signal when a script on your page attempts to load resources from an unexpected origin. Sansec's CSP monitor caught this attack in progress. The tradeoff is real: implementing and maintaining a strict CSP on a site that loads multiple third-party scripts requires ongoing effort, and a permissive CSP that allows broad wildcard origins provides much weaker signal. The monitoring value comes from specificity, which means you need to actually audit what your site loads and keep that policy current.

For WordPress operators specifically, the control that directly addresses the plugin-upload vector is restricting plugin installation to administrator accounts that cannot be reached via the web interface during off-hours, and auditing installed plugins against a known-good baseline on a scheduled basis. A plugin that appears without a corresponding change record in your deployment process is an immediate investigation trigger. File integrity monitoring on the wp-content/plugins directory is a lower-cost way to get that signal without full-scale endpoint tooling. The malicious plugin in this case contained a hardcoded authentication key, meaning removal of the plugin is necessary but not sufficient: you also need to audit for any sessions or users it may have created.

Finally, if your organization manages vendor relationships at scale, the access review process should include a question about how vendors manage credentials that touch infrastructure serving your users. That conversation is uncomfortable to initiate, but it is the kind of due diligence that cyber insurers are starting to require evidence of, and that this incident demonstrates is genuinely consequential.

Strondex's Vendor Access product helps organizations inventory and review the access permissions held by third-party vendors, supporting the kind of ongoing due diligence that incidents like this one make necessary.