Attackers injected malcious scripts in Brevo web pages using stolen API credentials
The Incident
On September 14 2026, Brevo published an incident report confirming the attackers stole their Cloudflare API key and injected malicious scripts into their web pages https://brevo.com, https://sibforms.com, and in the javascript files their customers use.
Attackers used the stolen API credentials to create workers in Cloudflare and injected the malicious code to display fake Cloudflare verification pages in their websites.
Visitors confirmed seeing the below fake Cloudflare verification page instructing them to copy and run the commands in their computers, where a successful attempt can leads to downloading malware in their systems.
Sansec says that Brevo's own web pages served the injected scripts and JavaScript assets that merchants uses to embed in their own sites (a tracker and a chat widget).
https://cdn.brevo.com/js/sdk-loader.js
https://cdn.brevo.com/js/sdk-loader.js
Attackers used ClickFix, a social-engineering technique used by the threat actors to trick users into manually copying and executing malicious shell commands on their own computers.
Visitors confirmed a full-screen Cloudflare-branded page was appeared to them asking to press Win+R, then Ctrl+V, then Enter. Where a successful attempt can tricks the visitors to run the command that is copied to the clipboard.
Fixes Applied
After identifying the issue on 14 September 2026, Brevo took multiple actions that includes, deleting the malicious worker and its routes, revoking the compromised API key and credentials created with it, cleared script caches and removed the hardcoded API key in source code.
They noticed the key was first misused in late August 2026 but didn't found any injection of malicious content before September 14.
Analysis
Here's what I noticed that opened the doors for attackers
1. Long-lived or Static API keys
Problem: Long-lived API keys introduce severe risk to the organisations, compounding vulnerabilities to digital infrastructure and allowing opportunity for extending the exploitation windows while staying anonymous.
Solution: API keys should be rotated regularly depending on the scope and exposure they bring.
2. Tokens with full permissions
Problem: While the API key exposure is a potential risk for organisations, having them with full-level (administrator or unrestricted) permissions creates a massive security vulnerability that drastically increases the system's "blast radius" if compromised. An API key is a static bearer credential. Whoever holds the key gets full access with no native user binding or expiration.
Solution: Teams should be aware while provisioning an API key / Access Tokens making sure they provide the permissions that are only necessary.
Here is the Google's guide for managing the API keys https://docs.cloud.google.com/docs/authentication/api-keys-best-practices
3. Hardcoded API keys in source-code and poor SAST practices
Problem: Hardcoding the API keys in source code and having Static Application Security Testing (SAST) practices create severe security blind spots and operational friction that can weaken an organisation's overall defence posture, giving more scope to the threat attacks for penetrating into the network.
Solution: Organisation's should mandate practices like static code analysis, repository scanning, secret push protection, etc., to restrict the user from hard coding the API keys or Tokens in their source code.
Check OWASP source code analysis guide here https://community.owasp.org/Source_Code_Analysis_Tools
While a human error is one of the most common attack vector threat actors look for, strengthening the attack surface can reduce the exposure and eliminates the risk of getting targeted.