A trusted marketing script turned into a delivery route for malware.
On 14 September 2026, attackers used a stolen, long-lived Cloudflare API key hidden in Brevo’s internal source code to take control of parts of the company’s edge infrastructure. They then modified legitimate Brevo JavaScript assets, reaching more than 100,000 websites. Many of them running WordPress.
The malicious code was active for only around four hours, from approximately 16:05 to 20:12 UTC. That was long enough to target site administrators, trick ordinary visitors into running malware and potentially leave persistent backdoors behind.
Brevo is a widely used marketing and customer relationship platform. Its customers include major organisations such as eBay, Louis Vuitton, Michelin and Amnesty International. The incident is a useful, and uncomfortable, reminder that your website’s security depends not only on your own code, but also on every third-party service you load.
A supply-chain attack does not need to break through your front door if a trusted supplier already has a key to the building.
What happened before the supply-chain attack?
Four days earlier, on 10 September, Brevo disclosed a flaw in its SAML single sign-on system. The initial disclosure suggested that only six accounts were affected.
Subsequent reporting indicated a much wider issue: attackers accessed 138 customer accounts, exported contacts from dozens of them and used six accounts to send phishing messages.
That first incident and the later Cloudflare compromise were separate events. However, their close timing made the second incident especially concerning. On 14 September, attackers used access to Brevo’s infrastructure, rather than simply targeting individual customer accounts, to affect websites at scale.
The detailed technical investigation was published by Sansec.
How one Cloudflare key became a mass-distribution system
The key problem was a hardcoded, long-lived Cloudflare API key with broad permissions. Instead of being stored in a secure secrets vault, the key was present in Brevo’s source code.
Once attackers obtained it, they could operate parts of Brevo’s Cloudflare environment. They created new subdomains under sendibt1.com, including:
cdn2.sendibt1.comcdn9.sendibt1.comcdn10.sendibt1.com
They also used Cloudflare Workers and Snippets to modify JavaScript at the edge. This meant the attackers did not necessarily need to change the original files on Brevo’s servers. They could alter what visitors received as the content passed through Cloudflare.
The affected assets included legitimate Brevo files such as:
sdk-loader.jsbrevo-conversations.js
The attackers appended a malicious loader called f.js.
In a particularly clever evasion technique, the original Last-Modified headers were preserved. Basic scanners that rely on file timestamps therefore saw nothing unusual. The file appeared not to have changed, even though the browser was receiving extra code.
Two payloads, two groups of victims
The malicious loader behaved differently depending on who visited the website.
Payload A: WordPress administrators
If a visitor was already logged into WordPress, the script attempted to use their trusted administrator session.
This is a form of session-riding and cross-site request forgery. The attacker did not need to steal the administrator’s password. Instead, the browser already had an active WordPress session, so WordPress treated the requests as legitimate actions by that administrator.
The script silently:
- Downloaded a malicious plugin archive called
wm.zipfromcdn10.sendibt1.com. - Posted it to the normal WordPress plugin upload endpoint.
- Activated it through the WordPress administration area.
- Planted a persistent PHP backdoor.
From WordPress’s point of view, the actions looked like a normal administrator installing and activating a plugin. That is why traditional warnings may not have appeared.
The plugin could also hide itself from the WordPress dashboard. This is why simply checking the list of visible plugins is not enough.
If your business used Brevo JavaScript or widgets during the incident window, review:
- Plugin directories on disk
- Plugin installation and activation dates
- WordPress administrator activity
- Web server access logs
- Unexpected PHP files or scheduled tasks
Sansec recommends looking for requests around 14 September to:
/wp-admin/update.php?action=upload-plugin
/wp-admin/plugins.php?action=activate
These requests do not prove compromise by themselves, but they are important indicators when they appear together.
Payload B: ordinary website visitors
Visitors who were not logged into WordPress saw a ClickFix-style overlay. It imitated a Cloudflare browser verification or CAPTCHA prompt.
The fake prompt told users to copy an obfuscated PowerShell command to their clipboard and run it. This is not a browser exploit. It is social engineering: the victim is persuaded to bypass the browser’s security boundary themselves.
Running the command could deliver infostealers such as Lumma or Vidar. These malware families are designed to steal browser passwords, cookies, cryptocurrency wallets and other sensitive information.
The lesson for staff is simple:
A browser verification screen should never ask you to paste commands into PowerShell, Command Prompt, Run or Terminal.
No genuine CAPTCHA requires that.
Why this incident matters to smaller businesses
It is easy to assume that supply-chain attacks are only a concern for large technology companies. They are not.
A growing business may use:
- Marketing forms
- Live-chat widgets
- Analytics scripts
- Payment integrations
- Booking tools
- Customer support platforms
- Content delivery networks
Each one creates another relationship of trust. A compromise at one supplier can affect your website without your own server being hacked directly.
This is a central concern for cybersecurity for small business, particularly where there is no dedicated security team watching third-party activity around the clock.
Practical steps businesses should take
1. Reduce trust in third-party scripts
Only load the scripts your website genuinely needs. Review old integrations and remove unused widgets.
Where possible, use Subresource Integrity. SRI allows your site to pin a script to a known cryptographic hash. If the script changes unexpectedly, the browser refuses to run it.
SRI is not suitable for every dynamic asset, but it is a valuable control for stable JavaScript files.
2. Protect keys and tokens properly
Secrets should never be hardcoded into application source code.
Use a secure secrets vault, strict least-privilege permissions and short-lived tokens. Separate critical Cloudflare zones and accounts so one compromised credential cannot control every important domain.
Brevo confirmed that it removed the hardcoded key, replaced it with scoped short-lived tokens and recognised the risk of running multiple critical domains under one Cloudflare account.
3. Audit WordPress on disk, not just in the dashboard
Compare the plugin directories in wp-content/plugins with the list of active and installed plugins shown in WordPress.
Look for:
- Unknown plugin folders
- Plugins installed or activated on 14 September
- Recently modified PHP files
- Plugins that exist on disk but do not appear in the dashboard
- Obfuscated code or unexpected remote connections
If you find suspicious files, do not simply delete them and move on. Preserve evidence where possible, review logs and rotate credentials.
4. Monitor server logs
Look for unauthorised plugin uploads and activation requests. Also investigate unexpected administrator logins, new user accounts and changes to core files.
This is where managed security services can make a major difference. A managed security services provider can monitor activity continuously and escalate unusual behaviour before it becomes a bigger incident.
5. Patch WordPress promptly
The incident also arrived during a busy period for WordPress security.
WordPress 7.1.1 was released on 17 September 2026, but WordPress 7.1.2, released on 22 September, patched the critical CVE-2026-87902 vulnerability associated with “Click2Shell” attacks.
You can review the technical details through the NVD entry for CVE-2026-87902 and the WordPress 7.1.2 release announcement.
Keep WordPress core, themes and plugins patched. Updates should be tested, but they should not be postponed indefinitely.
Key Insights
- Third-party scripts and widgets are part of your attack surface.
- A long-lived, over-permissioned API key can become a mass-distribution tool.
- Preserved timestamps and edge-level changes can bypass simple file monitoring.
- A logged-in WordPress administrator can be targeted without their password being stolen.
- Plugins hidden from the WordPress dashboard still need to be found on disk.
- Staff should never paste commands from browser prompts into Run, PowerShell, Command Prompt or Terminal.
- WordPress patching, endpoint protection, email protection and tested incident response must work together.
For many businesses, this is too much to manage informally. A strong security plan should combine 24/7 monitoring, endpoint security for business, email protection, vulnerability management and a tested incident response plan. It should also cover cloud security for SMEs, because your cloud accounts, SaaS platforms and supplier connections are now part of the same business environment.
That is the role of managed IT services: creating a reliable, monitored and secure foundation so your team can focus on running the business.
Has your website been exposed?
If you use Brevo forms, chat tools or embedded marketing scripts, review your WordPress plugins and server logs for activity on 14 September 2026. If you find an unfamiliar plugin, suspicious PHP file or unexpected administrator action, treat it as a potential compromise.
Do not wait for a visible outage. Supply-chain attacks can be brief, quiet and difficult to spot after the event.
Contact Picnic IT for a free security review. We can help you assess your website, WordPress installation, endpoints, cloud services and wider security controls, with clear advice and no unnecessary jargon.