The Brevo supply-chain incident demonstrates how a single compromised credential at a trusted service provider can create security consequences far beyond the provider’s own infrastructure. Attackers obtained access to a long-lived Cloudflare API key associated with Brevo and used that access to manipulate content delivered through Cloudflare’s edge network. Instead of modifying Brevo’s origin servers directly, the attackers created malicious Cloudflare Workers and DNS records that injected additional JavaScript into Brevo websites and into scripts embedded by Brevo customers. This allowed malicious content to reach visitors of otherwise legitimate websites without requiring those individual websites to be compromised separately.

The attack is particularly significant because Brevo provides marketing, forms, tracking and conversational components that organisations routinely embed into their websites. Third-party JavaScript is generally loaded directly into the visitor’s browser and executes within the context of the customer website. As a result, when a trusted supplier’s JavaScript is modified, thousands of downstream websites may begin delivering malicious code even though their own servers remain completely untouched. This is the essence of a modern software supply-chain attack: compromise the component that many organisations trust rather than attacking those organisations one by one.

Brevo reported that the attacker obtained a Cloudflare API key with broad account privileges that had been hardcoded within application source code. This is an important security failure because long-lived credentials stored directly within source code can become exceptionally valuable to attackers. Once such a credential is exposed, it may provide access to production infrastructure without requiring the attacker to compromise an administrator interactively. In this case, the API key reportedly provided sufficient privileges to create Cloudflare Workers, modify routes and create DNS records across Brevo-managed domains.

The use of Cloudflare Workers made the attack particularly difficult to detect through traditional integrity monitoring. Brevo explained that the malicious Worker modified responses at the CDN edge while leaving origin servers and source files unchanged. This meant that an administrator checking the original JavaScript file on the server might see a legitimate version while visitors received a modified version from the CDN. The malicious Worker was also able to remove security headers such as Content-Security-Policy from responses, weakening browser-side controls that might otherwise have restricted execution of attacker-controlled scripts.

This difference between origin integrity and delivered content is an important lesson for organisations using modern CDN and edge-computing platforms. Security monitoring cannot stop at verifying files stored on web servers. If a CDN, reverse proxy, edge function or traffic-management platform has the ability to modify application responses, then compromise of that layer can effectively modify the application itself. Organisations therefore need visibility into configuration changes, Worker deployments, DNS modifications and API activity across their edge infrastructure.

Visitors reaching affected pages were reportedly presented with fake Cloudflare verification screens using the increasingly common ClickFix social-engineering technique. ClickFix attacks typically attempt to convince users that they need to complete a technical action to resolve a browser, verification or security problem. Instead of exploiting a browser vulnerability directly, the attacker relies on the user to copy or execute a malicious command, often through PowerShell or another command interpreter. This allows attackers to bypass some conventional web security controls because the final malicious action is initiated by the victim rather than automatically executed by the page.

The technique illustrates why modern malware delivery increasingly combines technical compromise with social engineering. The supply-chain intrusion provided access to trusted websites, but the attacker still needed a method of moving from malicious JavaScript in a browser to code execution on an endpoint. A fake security or verification message provides a convincing bridge between those two stages. Users are accustomed to CAPTCHA prompts, browser checks and Cloudflare verification screens, making such messages effective when they appear on a website the victim already trusts.

The WordPress component of the campaign adds another layer of concern. On affected websites using Brevo components, the malicious script reportedly checked whether the visitor was logged into WordPress as an administrator. If an administrator was detected, the script attempted to install a malicious WordPress plugin disguised as a legitimate component called “Web Media Optimizer.” The plugin acted as a persistent backdoor and JavaScript loader rather than performing any genuine optimisation function.

Once installed, the malicious plugin attempted to hide itself from the normal WordPress plugin interface and copy itself into the must-use plugin directory, providing persistence even after the original supply-chain injection had been removed. The plugin also contacted attacker-controlled infrastructure to obtain additional JavaScript, allowing the attackers to change the payload delivered to visitors without modifying the plugin itself. More concerningly, analysis found a hardcoded authentication mechanism capable of generating a valid WordPress administrator session, potentially giving the attacker continued administrative access without knowledge of the legitimate administrator’s password.

This persistence mechanism demonstrates why simply removing the malicious third-party script is not enough for organisations that were exposed. If a WordPress administrator visited an affected site while the malicious Brevo content was active and the backdoor plugin was successfully installed, the website may remain compromised even though Brevo’s infrastructure has since been cleaned. Administrators therefore need to investigate their own environments rather than assuming that the upstream remediation automatically eliminates every downstream consequence.

The attack also highlights the danger of excessive API permissions. An API credential used for routine operational tasks should rarely require unrestricted access across DNS, Workers and multiple production zones. When a single credential can create edge functions, modify DNS and alter traffic behaviour across numerous services, compromise of that credential creates an unnecessarily large blast radius. Cloud environments should use narrowly scoped credentials, separate credentials by service and environment, and enforce short lifetimes wherever possible.

Secrets management is equally important. Credentials should not be hardcoded into application source code or embedded within repositories where they can be exposed through developer workstations, CI/CD systems, backups or source-control history. Dedicated secrets-management systems can provide short-lived credentials, access auditing and automated rotation. Even when source repositories are private, storing powerful production credentials directly in code substantially increases the consequences of a repository or developer-environment compromise.

The incident also demonstrates why supply-chain risk extends beyond traditional software packages and libraries. Security discussions frequently focus on malicious open-source dependencies or compromised software updates, but third-party JavaScript, analytics tags, marketing widgets, chat components and CDN-hosted scripts create similar trust relationships. When a website loads remote JavaScript from an external provider, that provider effectively gains the ability to execute code in the visitor’s browser within the context of the customer site. From a security perspective, that external script should therefore be treated almost as seriously as locally developed application code.

Content Security Policy can help restrict what third-party scripts are permitted to load or execute, but the Brevo incident also demonstrates its limitations when the attacker controls infrastructure capable of modifying response headers. Subresource Integrity can provide protection for static external JavaScript by allowing browsers to verify that downloaded content matches an expected cryptographic hash. However, it is more difficult to use with scripts that legitimately change frequently, which is common with SaaS widgets and marketing platforms. Organisations should therefore combine browser protections with vendor-risk assessment, network monitoring and continuous inspection of externally hosted dependencies.

For defenders, outbound traffic monitoring may provide another useful detection opportunity. A trusted website suddenly loading JavaScript from unfamiliar domains, particularly newly registered or rarely observed domains, should be considered suspicious. DNS filtering, threat-intelligence feeds and secure web gateways can potentially identify or block access to attacker-controlled infrastructure even when the initial page is legitimate. This demonstrates why evaluating the complete resource chain loaded by a web page can be more valuable than judging the reputation of the top-level website alone.

Endpoint controls are equally important because ClickFix ultimately attempts to convince the victim to execute commands locally. Organisations should monitor suspicious PowerShell, command-shell and scripting activity originating from browsers or interactive user sessions. Application control technologies can restrict execution of unauthorised scripts and binaries, while endpoint detection systems can identify command sequences associated with common ClickFix campaigns. User-awareness training should also explicitly cover fake browser-verification and “copy this command to fix the problem” prompts because these techniques are becoming increasingly common.

WordPress administrators who may have visited an affected site during the exposure window should examine plugin installation and activation records, particularly around September 14, and look for unexpected or hidden plugins. They should also review the must-use plugin directory, administrative accounts, active sessions and server logs. If suspicious activity is identified, administrator credentials and relevant API keys should be rotated, and the site should be investigated for additional persistence rather than simply deleting the obvious malicious plugin.

Another important lesson is the distinction between this incident and Brevo’s earlier September 10 SAML SSO compromise. In that separate incident, an attacker exploited a tenant-isolation weakness in Brevo’s SSO implementation to access 138 customer accounts. Six accounts were used to send phishing messages and contacts were exported from 43 accounts. The September 14 Cloudflare incident involved a different attack path based on a stolen API credential and malicious edge modifications. At the time of reporting, Brevo had not established publicly whether the two incidents were connected, so they should not be treated as a confirmed single campaign.

This distinction matters because accurate incident analysis requires separating evidence from assumption. Multiple security incidents occurring within days of one another can suggest a relationship, but timing alone does not prove common attribution or a shared initial compromise. Security teams should resist the temptation to combine separate events into one narrative until technical evidence supports that conclusion.

The broader lesson from the Brevo incident is that organisations inherit risk from every trusted third-party component they allow to execute within their applications and websites. A business may patch its servers, protect its administrator accounts and deploy strong endpoint security while still becoming a malware-distribution channel because a trusted external script was compromised upstream. Supply-chain security therefore requires visibility beyond the organisation’s own code and infrastructure.

Ultimately, the Brevo attack demonstrates the extraordinary amplification available to attackers who compromise widely used cloud and SaaS services. A single stolen credential reportedly allowed malicious content to be injected into Brevo’s own websites and scripts used across customer sites, exposing visitors to ClickFix attacks and potentially enabling persistent compromise of WordPress installations. The core defensive lesson is simple but uncomfortable: trust relationships are part of the attack surface. Organisations must protect API credentials, minimise third-party script exposure, monitor CDN and DNS configuration changes, inspect externally loaded resources and maintain the ability to detect malicious behaviour even when it originates from infrastructure that was previously considered trusted.

Brevo confirmed that attackers stole a Cloudflare API key and used it to inject malicious ClickFix scripts into its websites and JavaScript files embedded on customer sites to distribute malware. [...]

Source: Brevo supply-chain attack injected ClickFix scripts on customer sites via Bleeping Computer — published 17 Sep 2026.