A single Cloudflare API key, left hard-coded and never rotated, turned into one of the broadest software supply-chain incidents disclosed this month. On September 14, 2026, an attacker used a stolen key belonging to Brevo, the French email marketing and customer-communication platform formerly known as Sendinblue, to deploy a malicious Cloudflare Worker across the company’s infrastructure. For roughly five and a half hours, that Worker quietly rewrote pages and scripts that tens of thousands of unrelated websites load every day.
Brevo’s own incident write-up, published on its status page, put the number in stark terms: more than 100,000 websites may have loaded the tampered code, according to research from Sansec cited by SecurityWeek and BleepingComputer. The payload wasn’t a conventional exploit. It was a fake Cloudflare verification page that tricked visitors into copying and pasting a command into their own computers, a technique security researchers call ClickFix. No server was hacked in the traditional sense. A credential was, and that credential had the keys to a platform embedded across the open web.
What Brevo Confirmed About the Breach
Brevo’s account of the incident, published on its official status page, is unusually specific for a vendor security disclosure. The company stated: “On 14 September 2026, an attacker used a compromised Brevo Cloudflare API key to deploy a Cloudflare Worker on our account.” A Cloudflare Worker is a small piece of code that runs at the network edge, intercepting and modifying traffic before it reaches a website’s origin server. That is precisely what makes the attack hard to catch through normal means.
Brevo said the Worker “injected a malicious script into pages of brevo.com and sibforms.com and into three JavaScript files that customers embed on their own websites.” Those three files matter more than the headline numbers. Brevo’s forms script, its Conversations chat widget, and an SDK loader are the kind of small, trusted snippets that thousands of marketing teams paste into their site templates and then forget about. When the provider serving that snippet gets compromised, every site pulling it in real time gets compromised too, without anyone touching those sites directly.
Perhaps the most revealing line in Brevo’s write-up explains why the attack went undetected for hours: “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.” That’s a critical detail for any engineering team that assumes a clean file hash or an unmodified origin server means a service is safe. In this case, both were true, and visitors were still served malicious code.
Inside the ClickFix Attack: How a Fake CAPTCHA Tricks Users
ClickFix has become one of the more effective social engineering techniques of 2026 precisely because it doesn’t rely on a software flaw at all. It relies on habit. Visitors to an affected page were shown what looked like a routine “Cloudflare, verify you are human” prompt, according to Brevo’s own description of the lure. Instead of a checkbox, the fake prompt walked users through a short sequence: open the Windows Run dialog or a terminal, paste a provided string, and press enter. People do this instinctively when a page tells them it’s needed to prove they’re not a bot.
The mechanics work because the user, not an exploit, executes the first malicious step. There’s no browser vulnerability to patch and no antivirus signature to trip in that initial moment, because the “attack” is a person following instructions on their own keyboard. Security teams have watched ClickFix spread across phishing campaigns, fake software update pages, and now supply-chain incidents like this one throughout 2026, largely because it sidesteps the browser sandboxing and exploit mitigations that have made classic drive-by malware much harder to pull off.
What sets the Brevo case apart from a typical ClickFix phishing email is distribution. Attackers didn’t need to send a single message. They needed one API key, and Brevo’s own trusted infrastructure did the delivery work across every site embedding the affected scripts.
Timeline: From a Stolen Key to a Five-Hour Attack Window
Piecing together Brevo’s status page with reporting from BleepingComputer and Check Point Research gives a reasonably clear sequence of events, though several details, including exactly how the key was first obtained, remain unconfirmed.
| Date / Time (UTC) | Event | Source |
|---|---|---|
| Late August 2026 | Brevo says the Cloudflare API key may have been compromised around this time, though no earlier malicious activity has been found | BleepingComputer |
| Sept 14, 2026, ~15:01 UTC | Malicious Cloudflare Worker deployed, Brevo’s stated impact window begins | Brevo status page |
| Sept 14, 2026, 16:05–20:12 UTC | Sansec records the malicious script actively being served to site visitors | Sansec research, via reporting |
| Sept 14, 2026, ~20:30 UTC | Brevo’s disclosed impact window closes, roughly 5 hours 29 minutes after it began | Brevo status page |
| Sept 17, 2026 | Sansec publishes research estimating 100,000-plus sites may have loaded the tampered scripts | Sansec / trade press |
| Sept 20–21, 2026 | BleepingComputer, SecurityWeek, and Check Point Research publish coverage naming the ClickFix technique | Named outlets |
| Sept 28, 2026 | Brevo’s status page lists the incident as resolved, with the malicious Worker and injected content removed | Brevo status page |
The gap between a possible late-August compromise and a September 14 attack is worth sitting with. If Brevo’s own account holds up, the key sat exposed for roughly two weeks before anyone used it maliciously, and the company says it found no evidence of earlier misuse. That’s either good luck or a sign the attacker was doing reconnaissance before pulling the trigger. Neither Brevo nor the outlets covering the story have said which.
Why a Single Cloudflare API Key Could Do So Much Damage
The root cause here isn’t exotic. It’s a problem nearly every engineering team has somewhere in its stack: a credential with more power than it needs, stored somewhere it shouldn’t be, for longer than anyone intended. Brevo’s write-up described the compromised key as long-lived, holding full account permissions, and hard-coded directly in application source code. Any one of those three conditions raises risk. Together, they turned a single leaked string into the ability to rewrite live traffic across a major platform’s entire footprint.
The difference between a scoped token and a master key
Cloudflare, like most cloud providers, supports narrowly scoped API tokens as an alternative to broad legacy keys. A token limited to deploying a specific Worker script, with a short expiration date and no access to DNS, zone settings, or account billing, would have capped what an attacker could do with it even after theft. Brevo’s incident is a reminder that this distinction isn’t academic. It’s the difference between an attacker touching one component and an attacker rewriting responses served to visitors of brevo.com, sibforms.com, and every site embedding the company’s forms and chat scripts.
# Narrowly scoped Cloudflare API token instead of a hard-coded global key
POST /client/v4/user/tokens
{
"name": "ci-deploy-workers-only",
"policies": [
{
"effect": "allow",
"resources": { "com.cloudflare.api.account.zone.*": "*" },
"permission_groups": [ { "id": "workers_scripts_edit" } ]
}
],
"expires_on": "2026-12-31T00:00:00Z"
}Scoping alone would not have made the underlying credential leak impossible. It would have shrunk the blast radius from “every customer-facing script Brevo serves” down to a single deployable component, and a short expiration date would have closed the two-week window Brevo says the key may have sat exposed before use.
The Scale: Why “100,000 Websites” Doesn’t Mean 100,000 Victims
The 100,000 figure driving most headlines this week deserves a more careful read than it’s getting. Sansec’s estimate, cited by both SecurityWeek and Check Point Research, counts websites that embed the affected Brevo components and therefore could have loaded the modified code during the roughly four-hour window Sansec observed active serving. It is not a confirmed count of visitors who saw the fake verification page, and it is certainly not a count of people who copied and ran the malicious command.
That distinction matters for anyone trying to gauge real-world impact. A site loading a compromised script during a five-hour window might have served zero visitors, a handful, or thousands, depending entirely on its traffic pattern that afternoon. None of the outlets covering this incident, including BleepingComputer, SecurityWeek, or Check Point Research, have published a confirmed number of successful infections. What’s confirmed is exposure at scale. What’s unconfirmed is outcome at scale, and treating those as the same thing overstates certainty the available reporting doesn’t support.
How This Compares to Other Supply-Chain Attacks
Third-party JavaScript compromise isn’t new, but the Brevo incident sits in an unusually well-documented lineage of similar events, each with a different root cause and a different lesson for defenders.
| Incident | Year | Attack Vector | Estimated Reach | Outcome |
|---|---|---|---|---|
| Brevo / ClickFix | 2026 | Stolen long-lived Cloudflare API key used to deploy a malicious edge Worker | 100,000+ sites (potential exposure, per Sansec) | Resolved same day, no CVE issued, since it was credential misuse, not a software flaw |
| Polyfill.io | 2024 | Ownership change of a widely embedded CDN-served JavaScript library, followed by malicious script injection | 100,000+ sites, per Sansec’s original research | Cloudflare and Fastly began auto-rewriting or blocking polyfill.io references |
| Cloudflare Containers isolation flaw | 2026 | Cross-tenant residual data exposure inside Workers Containers and Sandboxes | 18 hosts confirmed, per Cloudflare’s own disclosure | Patched by Cloudflare, no confirmed exploitation in the wild |
The Polyfill.io case, also researched by Sansec, is the closest historical parallel. Both incidents show the same underlying dynamic: a small piece of shared, trusted code becomes a distribution channel the moment its source is compromised, and the damage scales with how many sites embedded it rather than with how sophisticated the initial exploit was. Shattered.io covered a related dynamic just weeks earlier when a Cloudflare Containers isolation flaw let one tenant potentially read another’s residual data, a much smaller but structurally similar failure of trust boundaries inside shared cloud infrastructure.
The Broader ClickFix Trend in 2026
ClickFix’s growth this year tracks a wider shift in how attackers get initial access. Rather than chasing a browser zero-day or hoping a phishing attachment slips past an email filter, ClickFix campaigns ask the victim to do the dangerous part themselves. That shift shows up across ransomware precursor campaigns too. Shattered.io’s earlier reporting on how ransomware groups are adapting their exfiltration methods touches the same underlying pattern: attackers increasingly favor techniques that route around endpoint detection rather than through it.
What makes the Brevo case a notable escalation of the ClickFix playbook is the distribution mechanism. Most ClickFix campaigns still rely on malvertising or phishing to get a victim onto a single fake page. Here, the lure rode inside a legitimate, trusted platform’s own infrastructure, reaching visitors of sites that had no idea they were embedding a compromised component. That’s a meaningfully larger and less predictable attack surface than a single phishing domain, closer in shape to the extended, multi-day intrusions Shattered.io mapped out in its anatomy of the Hugging Face agent breach, where attacker dwell time, not a single exploit, did most of the damage.
What Security Teams Should Do Right Now
For teams embedding Brevo components
- Check server and CDN access logs for the September 14, 2026 window, roughly 15:01 to 20:30 UTC, for unusual outbound requests from site visitors.
- Ask end users who may have interacted with a “Cloudflare verify you are human” style prompt around that date whether they ran any pasted command, and treat affected machines as potentially compromised rather than assuming a false alarm.
- Review Subresource Integrity settings on any third-party script embed. SRI hashes would not have blocked this particular attack, since Brevo’s own files were untouched at the origin, but they remain a baseline defense against a large share of script-tampering incidents.
For any team holding Cloudflare or similar edge-platform credentials
- Replace long-lived global API keys with scoped, expiring tokens wherever the provider supports them.
- Move credentials out of application source code and into a secrets manager, then audit repositories and build artifacts for anything that may have been hard-coded historically.
- Add alerting for new or modified Worker, Function, or edge-script deployments, since this is exactly the kind of change that bypassed Brevo’s origin-server integrity checks.
None of these steps are new advice. What the Brevo incident adds is a concrete, dated example of what happens when they’re skipped, at a scale that’s hard to dismiss as a hypothetical risk from a security conference slide.
Market and Industry Reaction
Brevo has not disclosed a customer count, revenue figure, or valuation in connection with this incident, and none of the reporting from BleepingComputer, SecurityWeek, or Check Point Research includes those figures either, so they should not be assumed. What is measurable is coverage volume: within a week of Sansec’s initial research, the story had been picked up by security trade press, general technology outlets, and Check Point’s own weekly threat-intelligence report, an unusually fast spread for an incident involving a marketing platform rather than a headline cloud provider.
That attention reflects a broader nervousness among enterprise security teams this year about vendor concentration risk. The same week Brevo disclosed its incident, Check Point Research’s threat-intelligence roundup also tracked other credential-driven compromises, a pattern that increasingly worries chief information security officers who have to account not just for their own infrastructure but for every third-party script, plugin, and API integration running inside it. Shattered.io’s coverage of how one AI security vendor’s breach trail widened across multiple major AI labs earlier this year traces the same structural problem from a different angle: a single vendor compromise rippling outward to customers who had no direct role in the failure. A separate set of flaws in Salesforce’s Agentforce platform, detailed in Shattered.io’s SalesBleed coverage, shows the same theme playing out inside AI agent tooling rather than a marketing widget.
The stakes get clearer when set against broader breach statistics. UK government figures reported earlier this year found that cyber breach rates among British firms had climbed to 43 percent, and third-party or supply-chain exposure is a recurring driver in that trend. An incident like Brevo’s doesn’t need to compromise a company’s own network to land on that tally. It only needs one embedded script.
Historical Context: The Rise of Third-Party JavaScript Risk
The Open Web Application Security Project has flagged software and data integrity failures, the category covering exactly this kind of third-party code compromise, as one of its Top 10 web application security risks for several years running. The Brevo incident is a textbook case: a trusted third-party component was modified at its source, and every downstream site inherited that risk without any code review, pull request, or deployment on their own end.
The pattern predates 2026 by years, but the mechanism keeps evolving. Early supply-chain scares centered on compromised npm or PyPI packages pulled during a build process. The Polyfill.io incident in 2024 showed the same risk applied to CDN-served runtime scripts loaded directly by browsers. Brevo’s case adds a third variant: an edge compute layer, in this instance a Cloudflare Worker, that can rewrite traffic after it leaves the origin server entirely, which is precisely why standard file-integrity checks missed it. Each generation of this attack class has gotten harder to catch with the previous generation’s defenses.
What the Named Sources Are Saying
Brevo’s own incident write-up remains the most detailed public account of what happened, and it’s worth quoting directly rather than paraphrasing, since the company’s precise wording shapes how the rest of the industry is interpreting the failure. On the initial compromise: “On 14 September 2026, an attacker used a compromised Brevo Cloudflare API key to deploy a Cloudflare Worker on our account,” the company wrote on its status page.
On the scope of what was affected, Brevo said: “For about five and a half hours, the Worker injected a malicious script into pages of brevo.com and sibforms.com and into three JavaScript files that customers embed on their own websites,” in the same write-up.
Perhaps the most technically important admission came in Brevo’s explanation of why the attack evaded detection. The company said: “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,” a statement reported by BleepingComputer.
On the timeline uncertainty, BleepingComputer’s reporting summarized Brevo’s position this way: “The company says the key may have been compromised as early as late August, but there’s no evidence of prior malicious activity,” a detail that leaves open exactly how long the exposure window really was before the attacker acted.
What Comes Next
A few predictions follow reasonably from how this incident unfolded and how similar ones have played out before.
- Expect Brevo to publish a more detailed post-mortem in the coming weeks covering how the key was stored and why rotation policies didn’t catch it, following the pattern set by other vendors after high-profile credential leaks.
- Expect other marketing and customer-communication platforms with embeddable widgets to face pointed questions from enterprise security teams about API key scoping and Worker deployment controls, given how directly this incident maps onto their own architecture.
- Expect ClickFix-style lures to keep spreading into new distribution channels beyond phishing email and malvertising, since the Brevo case demonstrates the technique works just as well riding inside a compromised trusted platform.
- Expect Cloudflare and competing edge-compute providers to face pressure to make scoped, short-lived tokens the default rather than an opt-in choice, since the Brevo incident is a clean illustration of what a long-lived, over-permissioned key can do.
- Expect the final confirmed impact, including any second-stage malware family and a real infection count, to stay murky for some time, since none of the outlets covering the story so far have published that level of forensic detail.
Frequently Asked Questions
What is Brevo, and why does its breach matter beyond its own customers?
Brevo, formerly known as Sendinblue, is a French customer-communication and email marketing platform whose forms, chat widget, and SDK scripts are embedded directly on thousands of other companies’ websites. When Brevo’s infrastructure was compromised, that embedded code became a distribution channel reaching visitors of sites that never had a direct relationship with the attacker.
What is a ClickFix attack?
ClickFix is a social engineering technique where a fake error message, CAPTCHA, or verification prompt instructs a visitor to copy and paste a command into their Run dialog, terminal, or Command Prompt. The victim, not a software exploit, executes the first malicious step, which lets the technique bypass many traditional browser-based defenses.
Did 100,000 websites actually get infected with malware?
Not necessarily. The 100,000 figure, from Sansec’s research, counts sites that embed the affected Brevo scripts and therefore could have loaded the tampered code during the roughly five-hour attack window. It is not a confirmed count of visitors who saw the fake prompt or ran the malicious command, and no outlet covering the story has published a verified infection total.
Was a CVE issued for this incident?
No. The available reporting and Brevo’s own write-up describe this as credential compromise and cloud-account abuse rather than a software vulnerability, so no CVE identifier has been assigned.
How is this different from the Polyfill.io supply-chain attack in 2024?
Both incidents involved a widely embedded third-party script reaching over 100,000 sites, based on Sansec’s research into each case. Polyfill.io stemmed from a change in domain ownership that let new operators alter a CDN-hosted JavaScript library. Brevo’s incident stemmed from a stolen cloud API key used to deploy a malicious edge Worker, a different point of failure that produced a similar downstream reach.
What should website operators using Brevo do now?
Brevo’s status page marks the incident as resolved, with the malicious Worker and injected content removed. Operators should still review logs from the September 14, 2026 impact window, check whether any site visitors reported unusual prompts or ran unexpected commands, and consider adding Subresource Integrity checks on embedded third-party scripts as a longer-term precaution.
How long was the Cloudflare API key exposed before it was used?
Brevo has said the key may have been compromised as early as late August 2026, roughly two weeks before the September 14 attack, though the company says it found no evidence of malicious activity during that earlier window. The exact date and method of the initial key theft have not been publicly confirmed.
What can other companies learn from how Brevo’s key was stored?
Brevo described the compromised credential as long-lived, holding full account permissions, and hard-coded in application source code. Security teams reviewing their own Cloudflare or similar cloud provider usage should prioritize replacing broad, permanent keys with scoped tokens that expire and carry only the permissions a given deployment process actually needs, as outlined in Cloudflare’s own token documentation.
