What happened
On September 14, between 16:05 and 20:13 UTC, attackers compromised Brevo's infrastructure using a Cloudflare API key that had been hardcoded into the company's application source code with full account permissions and no expiration. That key let them create malicious Cloudflare Workers, code that runs at the CDN edge, allowing them to rewrite content served from Brevo's own domains and the widgets Brevo customers embed on their own websites without needing to touch origin servers at all.
The injected content included fake Cloudflare verification pages, ClickFix-style instructions that trick visitors into pasting and running malicious commands in the Windows command prompt, and a disguised WordPress plugin called Web Media Optimizer that installed a JavaScript loader for persistent backdoor access. Brevo's forms script, its Conversations widget, and its SDK loader scripts were all modified, affecting an estimated 100,000 websites that embed Brevo components before the malicious subdomains stopped resolving on September 15.
Why it lands now
The technical detail that matters most here is where the attack happened: at the CDN edge, not on Brevo's origin servers. Brevo's own post-mortem states plainly that the Worker rewrote responses at the edge and removed security headers such as Content-Security-Policy, while origin servers and files remained unmodified and standard integrity checks did not detect the change. That is a meaningful gap in how most organizations think about supply chain integrity monitoring, which tends to focus on source code and build pipelines rather than the CDN layer sitting between origin and end user.
It lands now because embedded third-party scripts, forms, chat widgets, marketing SDKs, are ubiquitous across enterprise websites and are almost never included in an organization's own security monitoring scope. A company running Brevo's forms widget had no visibility into this compromise and no ability to detect it independently, because the malicious behavior originated entirely within Brevo's infrastructure and was served through a domain the customer's own site was configured to trust.
The hardcoded credential problem, again
A long-lived API key with full account permissions, hardcoded directly into application source code, is one of the most well-documented anti-patterns in application security, and it keeps causing breaches of exactly this scale because the fix, secrets management with scoped, rotating credentials, requires refactoring work that rarely gets prioritized until it fails catastrophically. Full account permissions on a Cloudflare key meant the attacker could create Workers, the specific capability that let them rewrite content at the edge, rather than being limited to a narrower scope that might have contained the damage to a single service.
Organizations running their own CDN and edge compute infrastructure should treat this as a direct prompt to audit every API key with edge-modification permissions, confirm none are hardcoded in source, and move toward short-lived, narrowly scoped credentials issued through a proper secrets manager. The specific capability to watch for is any key broad enough to create or modify Workers, Lambda@Edge functions, or equivalent edge compute resources, because that is the exact capability this attacker used to bypass every downstream integrity control Brevo had. The pattern of full-permission keys sitting unrotated in source code is common enough across SaaS vendors that any enterprise relying on third-party embedded scripts should assume similar exposure exists somewhere in its own vendor stack rather than treating Brevo as an isolated outlier.
A pattern, not an isolated incident
This was Brevo's second security incident within a week. On September 10, the company disclosed a separate SSO-related breach that led to a wave of phishing attacks against customers of the cryptocurrency wallet maker Trezor, one of Brevo's clients, with reports of 347,000 users targeted and more than 2,500 confirmed compromises. Two distinct, serious incidents inside seven days at the same vendor is the kind of pattern that should trigger an immediate vendor risk re-review, not a wait-and-see approach.
For enterprises using Brevo or any comparable marketing automation and communication platform, this sequence is a concrete prompt to ask the vendor directly about credential management practices, edge infrastructure monitoring, and incident response timelines, rather than waiting for the next post-mortem to arrive. A vendor's willingness to publish a detailed technical post-mortem, as Brevo did here within three days, is a positive signal, but it does not substitute for independently verifying that root causes get fixed rather than just patched.
What this means for third-party script governance
Most enterprises maintain an inventory of the SaaS vendors they pay for, but far fewer maintain an inventory of every third-party script, widget, and SDK actually loading on their public-facing websites, which is a different and often longer list once free tiers, legacy integrations, and marketing team additions are included. This incident demonstrates why that gap matters: a compromise entirely inside a vendor's infrastructure, invisible to the customer's own security tooling, can still serve malware to the customer's own site visitors under the customer's own domain and brand.
Content-Security-Policy headers, subresource integrity checks where feasible, and regular audits of what third-party JavaScript actually executes on production pages are the concrete controls that reduce blast radius here, and Brevo's own post-mortem noted that the attacker specifically stripped CSP headers to make the injection work. Enterprises should verify their own CSP configuration cannot be silently overridden by a compromised third-party script and should treat any vendor serving executable JavaScript on their domains as a security dependency worth the same scrutiny as a directly integrated software component.
What this means for your roadmap
Build or update your third-party script inventory this quarter, and for each embedded vendor script, confirm what CSP protections are in place and whether that vendor has had a security incident in the past twelve months. Brevo's two incidents in one week is exactly the signal that should trigger a deeper look, especially for any customer using Brevo's Conversations widget or forms script on customer-facing pages, and the inventory exercise itself will likely surface several other embedded vendors nobody on the security team currently tracks.
More broadly, add CDN and edge infrastructure credential hygiene to your own vendor security questionnaire template, since this incident shows that source code security reviews alone miss an entire class of risk sitting in edge compute permissions. If your organization runs its own CDN or edge functions, use this incident as the prompt to audit your own API keys for the same hardcoded, over-permissioned pattern that turned one Brevo credential into malware served on 100,000 sites.
