Your marketing widget just got hacked: How the Brevo supply chain attack proves every embedded script is a checkout security risk

The Brevo supply chain attack on September 14, 2026, used a stolen Cloudflare API key to rewrite the JavaScript served by Brevo’s embedded widgets, exposing an estimated 100,000+ websites to a fake “verify you are human” ClickFix prompt and, on WordPress, a backdoor plugin installed when an administrator visited. If your store embeds Brevo forms, chat, or tracking scripts, check for the affected files, audit plugins and admin accounts, and monitor what every third-party script actually delivers.

When attackers compromised Brevo’s infrastructure on September 14, 2026, they didn’t breach individual eCommerce stores one by one. They used a long-lived Cloudflare API key to deploy a malicious Cloudflare Worker and rewrote the JavaScript that Brevo’s embedded widgets served to an estimated 100,000+ websites. Depending on the visitor, the injected code showed a fake “verify you are human” ClickFix prompt or tried to install a WordPress backdoor. If your store runs a Brevo email signup form, chat widget, or tracking script, your customers may have been served malicious code through a script you explicitly chose to trust.

This is the attack surface most eCommerce merchants have never audited: the embedded SaaS marketing widgets that run on virtually every online store.

What happened in the Brevo supply chain attack

According to Sansec’s forensic analysis and Brevo’s own post-mortem, the incident unfolded in two stages. On September 10, attackers exploited a flaw in how Brevo handled SAML single sign-on to access 138 customer accounts. They returned on September 14 with a different credential: a long-lived Cloudflare API key that was hardcoded in Brevo’s source code and had first been misused in late August.

• They used the key to deploy a malicious Cloudflare Worker that modified Brevo’s own pages and three JavaScript files that Brevo customers embed on their sites, at the CDN edge, before the code reached any visitor.

• The modified scripts pulled in further code from Brevo-owned sendibt1.com domains, which delivered two payloads: a ClickFix social-engineering prompt (a fake “Cloudflare, verify you are human” page that tells the visitor to paste and run a command) shown to selected visitors, and a WordPress backdoor plugin that the script tried to install only when the visitor was logged in as a WordPress administrator.

• Sansec reports that the malware deliberately targeted logged-in WordPress administrators and avoided crawlers, developers, and security scanners, which is exactly why it was hard to spot from the outside.

• Brevo removed the Worker and revoked the key and credentials after roughly five and a half hours.

How long did it last? Sansec observed malicious code being served for roughly four hours, while Brevo’s post-mortem puts the Worker’s total active time at about five and a half hours. The two figures describe slightly different windows rather than a disagreement.

Any site that loaded the affected Brevo scripts during that window was exposed, though the payloads were selective. No individual store was breached. No plugin was exploited. No vulnerability in WooCommerce, Shopify, or any eCommerce platform was involved. The trusted script from a trusted vendor simply started delivering malicious code.

Which Brevo scripts and domains were affected

• Customer-embedded files: cdn.brevo.com/js/sdk-loader.js (SDK loader and tracking), cdn.brevo.com/js/brevo-conversations.js (the Conversations chat widget), and the script behind forms hosted on sibforms.com
• Second-stage domains: subdomains of sendibt1.com, a domain owned by Brevo, which hosted the additional scripts and the WordPress plugin package
• Attack window (14 September 2026): roughly 16:05–20:13 UTC for customer-embedded scripts according to Sansec; Brevo’s Worker was active on its own domains from about 15:01 UTC and was removed at around 20:30 UTC
• WordPress plugin: reported under the name “Web Media Optimizer”, installed only when a logged-in administrator visited a page carrying an affected Brevo script

Why embedded marketing widgets are a different kind of checkout risk

eCommerce security efforts typically focus on three areas: platform vulnerabilities (patched through security updates), extension and plugin exploits (mitigated by vetting and updating), and Magecart-style skimmers (detected through checkout monitoring). The Brevo attack exposes a fourth surface that most merchants have never audited: the embedded SaaS widgets they load from third-party domains.

These widgets are fundamentally different from plugins:

• Plugins run your code on your server. You control the version, you can audit the source, and you can update or remove them.
• Embedded widgets run someone else’s code on your customers’ browsers. The vendor controls what the script contains, and it can change at any time, deliberately during an update, or maliciously during a compromise.

Most eCommerce stores load multiple embedded widget scripts: email capture and popup forms, live chat, analytics and session recording, social proof and notification popups, A/B testing and personalisation tools, and customer review platforms. Each loads JavaScript from a domain you don’t control. If any vendor’s infrastructure is compromised, through a stolen API key, a CDN hack, or a DNS hijack, the malicious code runs in your customers’ browsers with full access to the page content.

PCI DSS 6.4.3 and 11.6.1: Why third-party widgets are in scope

PCI DSS 4.0.1 requirement 11.6.1 requires a mechanism that alerts personnel to unauthorised changes to the HTTP headers and contents of payment pages as received by the consumer’s browser, which means browser-side monitoring rather than server-side scanning alone. Requirement 6.4.3 complements it: every script loaded and executed on a payment page must be authorised, justified, and kept in an inventory. The PCI Security Standards Council’s information supplement, Payment Page Security and Preventing E-Skimming, gives guidance on meeting both requirements, including how to treat third-party scripts.

Here’s the compliance gap the Brevo attack exposed: many merchants inventory their own code and direct integrations, but embedded SaaS widget scripts are often excluded because they “come from a trusted vendor” or “aren’t on the payment page.” In reality:

• Widget scripts loaded in the header or footer execute on every page, including checkout
• A compromised widget script has access to the same DOM as payment fields
• The Brevo attack proved that “trusted vendor” is not a security control; the vendor’s own infrastructure was the attack vector.
• PCI DSS makes no exception for scripts from “trusted” third parties; if a script runs on a payment page, it must be inventoried and monitored

How to audit your embedded widget scripts right now

Step 1: Create a complete inventory

Open your store in an incognito browser and navigate to your checkout page. Open developer tools (F12) and go to the Network tab. Filter by “JS” to see every JavaScript file loaded. For each external script:

• Note the domain it loads from
• Identify the vendor and purpose
• Confirm whether it appears in your script inventory
• Document whether it needs to run on the checkout and payment pages or only on marketing pages

Step 2: Remove scripts that don’t belong on checkout

Many widget scripts are loaded site-wide via header/footer injection when they only need to run on specific pages. Common examples:

• Email popup scripts running on the checkout page (unnecessary and a security surface)
• Chat widgets loading on the payment page (often not needed during payment entry)
• Social proof notifications running in the cart and checkout flow (a distraction and a risk)

Remove or conditionally load any script that doesn’t have a justified business purpose on checkout and payment pages.

Step 3: Verify script integrity

For each remaining script, check:

• Does the script load over HTTPS? Any HTTP-loaded script can be modified in transit.
• Does the vendor support Subresource Integrity (SRI)? SRI hashes prevent the browser from executing modified scripts, but most widget vendors don’t support it because their scripts change frequently.
• Does your Content Security Policy allow only the exact hosts each vendor needs? Brevo’s modified scripts pulled their second stage from a different Brevo-owned domain. A script-src limited to exact vendor hosts, without that domain, would have refused it, and the resulting violation reports would have been an early warning.
• Does the vendor publish changelogs for their embedded scripts? Most don’t, which means you have no way to know when script content changes.

Step 4: Implement behaviour monitoring

Since most widget vendors don’t support SRI, you need an alternative integrity mechanism:

• Record the hash, size, and behaviour of each widget script at a known-good baseline
• Monitor for changes to the script content, new network requests the script makes, or new DOM elements the script creates
• Alert when any widget script’s behaviour deviates from its baseline

What to do if your store loaded the compromised Brevo scripts

If your store embedded Brevo scripts on September 14, 2026, work through these checks:

• Confirm you were exposed. Search your page source, theme files, and tag manager for cdn.brevo.com/js/sdk-loader.js, cdn.brevo.com/js/brevo-conversations.js, and sibforms.com forms. Server logs won’t show these loads because visitors’ browsers fetch the scripts directly from Brevo’s CDN. DNS, proxy, or endpoint logs showing requests to sendibt1.com subdomains are a better indicator.
• Check for the WordPress backdoor. The plugin install was only attempted if a logged-in administrator visited a page on your site during the attack window. Look for plugin uploads on September 14, any unfamiliar plugin, and plugin folders on disk that don’t appear in the WordPress admin list, since the plugin can hide itself.
• Audit administrator accounts. Check for admin users nobody remembers creating.
• Scan and rotate credentials. If you suspect a backdoor, run a thorough malware scan and change all admin passwords, API keys, and payment gateway credentials.
• Consider your visitors. Visitors who were shown the fake verification page may have run a malicious command on their own machines, so consider whether you need to notify customers.
• Notify your payment processor if needed. If a compromised script had access to your checkout page, your acquiring bank may need to be informed under PCI DSS incident reporting requirements.

How to reduce third-party script risk before the next vendor is compromised

The Brevo attack is not unique; it’s a predictable outcome of how modern eCommerce stores are built. Any SaaS vendor that embeds JavaScript on your site is a potential supply chain vector. Your prevention framework should include:

Minimise the attack surface:

• Remove every widget script that doesn’t serve a documented business purpose
• Conditionally load scripts so they only execute on pages where they’re needed
• Prefer server-side integrations (API calls from your server) over client-side widget scripts where possible

Monitor what scripts actually deliver:

• Track every network request each widget script makes
• Alert on new domains contacted by existing scripts
• Detect when a script accesses form fields or DOM elements it shouldn’t need

Prepare for the inevitable:

• Have a documented process to block any widget script within minutes
• Know how to add a Content Security Policy directive to block a specific domain in an emergency
• Maintain an incident response plan specifically for supply chain compromises of embedded scripts

How to detect a compromised third-party script before your customers do

The Brevo attack lasted a matter of hours. How long would it take you to notice if one of your embedded widget scripts started serving malicious code? For most merchants, the answer is: until a customer reports it, a security scanner catches it days later, or a PCI audit flags it months later. This kind of compromise is hard to catch from the outside, because the code was shown selectively and avoided scanners. The more reliable signal is what real visitors’ browsers report, and Sansec’s own CSP monitoring logged thousands of violation reports during and after the attack window.

AuditIQ gives you both sides of that picture:

• CSP Monitoring: logs every Content Security Policy violation in real time, with the blocked resource, the page, the directive violated, and a timestamp, across every subdomain and storefront. Built around PCI DSS v4.0’s expectation of continuous script monitoring on payment pages, it surfaces the unexpected domain a trusted script suddenly tries to load, and trend analysis helps separate a genuine attack from a harmless whitelist gap. It works best alongside a CSP limited to exact vendor hosts, as described above.
• Script Inventory: maintains a continuously updated ledger of every JavaScript file running on your store, with its URL, the page it was found on, and when it first and last appeared, and separates your own code from third-party scripts. When a new script or vendor domain appears that wasn’t in your inventory, you’re alerted straight away, and the ledger doubles as the authorised-script record that PCI DSS 6.4.3 expects.

Beyond third-party script security, AuditIQ is a 360° eCommerce monitoring platform purpose-built for Magento, Adobe Commerce, and Shopify stores. It continuously monitors every critical layer of a store — performance, infrastructure, SEO, security, user experience, configuration, and code quality — from a single, unified dashboard, so a compromised widget is one of many silent failures it is watching for around the clock.

Start monitoring your checkout scripts for free today to see what your storefront is actually serving before the next vendor is compromised.

Others also read

Third-party JavaScript on checkout: Security, performance & compliance risks The WebRTC Skimmer Threat: Why real-time eCommerce monitoring is no longer optional PCI-DSS v4.0.1 is now enforced: Is your storefront actually compliant?

Frequently asked questions

1. Was the Brevo attack limited to WordPress/WooCommerce sites?

The WordPress backdoor attempt only applied to WordPress sites, and only when a logged-in administrator visited the site. The ClickFix prompt, however, was delivered through the modified Brevo scripts regardless of platform, so Shopify, Magento, and other stores embedding the affected scripts were exposed to it too.

2. How do I know if my site loaded a compromised Brevo script?

First, check whether your pages embed the affected Brevo files (sdk-loader.js, brevo-conversations.js, or sibforms.com forms). If they do, your site was exposed during the attack window on September 14, 2026. Your own server logs won’t show it because browsers load these scripts directly from Brevo’s CDN, so look at DNS or proxy logs for sendibt1.com subdomains and review plugin and admin activity on your site instead.

3. Does Content Security Policy protect against this type of attack?

Partly. The modified scripts loaded from Brevo’s own cdn.brevo.com domain, which most CSPs already allow, so the first stage would not be blocked. But the injected code pulled further payloads from sendibt1.com, a separate domain, so a CSP that allows only the exact hosts you need would have refused them and logged violations. Think of CSP as a damage limiter and an early-warning signal rather than a complete defence, and pair it with monitoring of what your scripts actually do.

4. Is this the same as a Magecart attack?

The mechanism differs, but the outcome can be similar. Magecart attacks typically inject skimming code directly into the store’s checkout pages. Supply chain attacks compromise a trusted third-party script that the store intentionally loads. Both result in malicious code executing in your customers’ browsers.