SURIQ
The malware that hit as many as 100,000 websites this month never touched a single file those sites control. It was injected into scripts served from a trusted vendor's own delivery network, and the bytes on the origin server never changed. That one detail is why the standard integrity controls stayed quiet, and it is the part of this story worth your attention.
According to Security Affairs and the security firm Sansec, which discovered the injection, attackers abused Brevo, the French email and marketing platform that rebranded from Sendinblue, to alter the JavaScript it delivers to customer sites. Brevo embeds tracking and chat widgets across a large customer base, so a change at its edge reached every site carrying that code. It is the same shape as when attackers swapped a third-party ad script and when a reported backdoor rode a WordPress content network: the site owner did everything right and still shipped hostile code.
What happened, in two stages
The incident had two distinct parts, and reporting does not yet confirm they are connected. On September 10, according to Security Affairs, attackers exploited a flaw in Brevo's single sign-on (SSO) system and compromised 138 accounts, sending phishing from six of them and exporting contact data from dozens more.
The damaging stage came on September 14. Security Affairs reports that attackers got hold of a Cloudflare API key that had no expiry and full rights over the account, left sitting in Brevo's source code, and used it to push a malicious Cloudflare Worker. Sansec, which found the tampering, described it as response rewriting at Brevo's content delivery network (CDN), the layer that sits between the origin server and the visitor. Both framings land in the same place: the attacker controlled what the edge served without changing anything at the origin.
Sansec observed the malicious payload live for roughly four hours, from about 16:05 to 20:13 UTC on September 14, and estimated more than 100,000 exposed sites by querying PublicWWW for Brevo's embedded code. The rogue scripts loaded from sendibt1.com, a domain whose TLS certificate was created on August 25, so the infrastructure was staged weeks ahead. Both companies reported the injection cleaned up by September 15.
Why your integrity checks stayed silent
Two controls operators reach for against tampered third-party scripts did nothing here, and it is worth being precise about why. Subresource Integrity (SRI), where you pin a hash of a remote script so the browser refuses a modified copy, assumes the file changes. It did not. File-integrity monitoring on the origin assumes the bytes at rest change. They did not either: Sansec noted the affected files on cdn.brevo.com reported an unchanged Last-Modified timestamp throughout, the value after the attack matching the value before it.
The tamper happened inside the delivery layer the vendor controls, between a clean origin and the browser. That is the blind spot. Any control that verifies the origin, or a hash of what the origin published, is looking in the wrong place.
The table is the whole lesson. The controls that would have caught this watch the browser's behavior, not the file: a strict Content Security Policy (CSP) that only permits scripts from hosts you named, and monitoring for pages that suddenly reach an origin nobody approved.
The signal was network-side, not on disk
Because the file stayed still, the observable moved to the network. A site that normally loads scripts from its own domain and cdn.brevo.com suddenly fetching from sendibt1.com is the tell. That shows up in browser CSP violation reports, in egress logs, and in DNS resolution for the rogue host, none of which depend on a file changing. This is the recurring theme in front-end compromises, and we saw the same detection gap in the Polymarket front-end theft: the payload lives in the browser session, so on-host file scanning never sees it.
Two payloads rode the injection, per Sansec. Visitors saw a fake "prove you're human" overlay, the ClickFix pattern that tries to trick a user into running a command. Logged-in WordPress administrators got worse: the script quietly installed an attacker-supplied plugin named "Web Media Optimizer" through their active session, using the admin's own credentials, with no password prompt. Here is what to hunt on a site that carried Brevo code during the window.
Rogue script host (alert / block): sendibt1.com (TLS cert created 2026-08-25) Brevo files that served tampered code: https://cdn.brevo.com/js/sdk-loader.js https://cdn.brevo.com/js/brevo-conversations.js Dropped WordPress plugin: Web Media Optimizer WordPress admin-session hunt (access logs, 2026-09-14 ~16:00-20:30 UTC): POST /wp-admin/update.php?action=upload-plugin
The root cause was a token, not a bug
Strip away the CDN mechanics and the enabling failure is mundane: a long-lived credential with full permissions, living in source code. Security Affairs reports the Cloudflare key had exactly that shape. A key like that turns any source-code leak, and any account compromise that reaches the repository, into control of everything the key can touch. We have written before about a leaked key that carried full admin rights; the pattern repeats because convenience beats scoping until it does not.
The fix is old and unglamorous: short-lived, scoped tokens for automation, no static secrets in code, and a separate credential per function so one leak is not total. Had the Cloudflare token been scoped to a narrow task and rotated on a short clock, stage two would have been far harder to pull off even after the earlier account compromise.
Rotate CDN tokens and pin your script sources
If your site embeds Brevo or Sendinblue code, treat the September 14 window as a possible exposure and work through this list:
- Review the third-party scripts your pages load, and confirm none reference
sendibt1.comor another host you did not approve. - Check WordPress access logs and the plugin list for an unexpected install ("Web Media Optimizer") during the window, and remove it if present.
- Rotate site and administrator credentials if an admin was logged in while the tampered code was live.
- Set a strict Content Security Policy that names your allowed script hosts, and turn on CSP violation reporting so a future rogue host surfaces on its own.
- For any CDN or automation tokens you hold, scope them narrowly, rotate them on a short clock, and keep them out of source code.
Brevo pulled the leaked key, took the hardcoded secret out of its codebase, stripped the attacker's hostnames, and cleared its edge caches, according to Security Affairs. The remediation was fast. The lesson for everyone downstream is that a vendor's edge is inside your trust boundary, and the only controls that see a compromise there are the ones watching the browser and the network, not the file on disk.
| Control | Caught it? | Why |
|---|---|---|
| Subresource Integrity hashes | No | The remote file's bytes never changed, so the pinned hash still matched |
| Origin file-integrity monitoring | No | The Last-Modified timestamp on cdn.brevo.com never moved during the swap |
| Content Security Policy allowlist | Would block | The injected loader pulled from sendibt1.com, outside any named script source |
| Egress and DNS monitoring | Would flag | A page reaching an unapproved script host is visible without any file change |