Third-Party Script Got Your Site Blacklisted? Here's What to Do

unflagdomain Team·UPDATED September 19, 2026

When a third-party script on your site is compromised, your domain gets blacklisted for code you never wrote. Security vendors flag the domain that served the malicious JavaScript, not the company that shipped it. The way out is the same as any hack: remove what the attacker left behind, confirm the site is genuinely clean, then ask every flagging vendor to re-check it — in that order.

TL;DR: On 14 September 2026, attackers used a hardcoded Cloudflare API key to rewrite Brevo's JavaScript at the CDN edge, serving a ClickFix scam and a hidden WordPress backdoor from more than 100,000 customer sites for roughly four hours (Sansec, 2026). If you embed a Brevo script: check that day's access log for a plugin upload, remove the Web Media Optimizer plugin and any copy in mu-plugins, rotate every admin credential — and only then chase the blocklist flags. A site with a live backdoor gets re-flagged the moment a vendor reviews it.

This guide is for site owners who did nothing wrong and got flagged anyway. It uses the Brevo incident as the worked example because it is recent and well-documented, but the shape of the problem is older than that and it will happen again. We'll cover how to tell whether you were hit, what to remove, why the flags land on you rather than the vendor, and how to get them lifted.

What happened in the Brevo supply-chain attack?

Attackers stole a long-lived Cloudflare API key that Brevo had hardcoded in its application source code, then used it to modify content at the CDN edge. Brevo described the key as "a long-lived Cloudflare API key with full account permissions that had been hardcoded in application source code" (BleepingComputer, 2026). Full account permissions meant the attacker could create Cloudflare Workers, routes, and DNS records at will.

They used that access to inject a loader into Brevo's own legitimate assets — sdk-loader.js and brevo-conversations.js — the files Brevo customers embed on their own websites. The injected snippet pulled a second-stage script from an attacker-controlled subdomain. Sansec logged the tampered code being served between 16:05:18 and 20:12:53 UTC on 14 September 2026 (Sansec, 2026), across more than 100,000 sites including eBay, Louis Vuitton, Michelin, and Amnesty International.

The payload did two different things depending on who was looking:

  • Ordinary visitors got a full-page fake Cloudflare "human verification" prompt. It copied a command to the clipboard and instructed the visitor to paste it into the Windows Run box or a terminal — the social-engineering pattern known as ClickFix. Anyone who followed the instructions ran malware on their own machine.
  • Logged-in WordPress administrators got something worse. The script used the admin's live session to upload and activate a plugin, fetched as wm.zip from cdn10.sendibt1[.]com, presenting itself in the admin UI as Web Media Optimizer (Sansec, 2026).

Brevo has since revoked the key, removed the malicious Worker and its routes, deleted the hardcoded credential from its source, removed attacker-controlled hostnames, and purged its edge caches (SecurityWeek, 2026). That closes the injection path. It does nothing about a backdoor already sitting on your server.

Was my site affected?

You were exposed if you embedded a Brevo script and served traffic during that four-hour window on 14 September 2026. You were likely compromised — as opposed to merely exposed — if a WordPress administrator loaded one of your pages while signed in during that window.

Check these, in order:

  • Your access log for that day. Sansec's indicator is a POST /wp-admin/update.php?action=upload-plugin followed shortly by a GET /wp-admin/plugins.php?action=activate. If you find that pair on 14 September and you didn't install a plugin that day, assume compromise.
  • Your plugin list, then your files. The backdoor hides itself from the WordPress plugins screen, so the admin UI alone will not show it. Compare the directories actually present in wp-content/plugins against what the dashboard lists.
  • The must-use plugin directory. It copies itself into wp-content/mu-plugins, which loads automatically and cannot be deactivated from the admin UI. This is the part people miss.
  • Anything installed or activated on 14 September that you don't recognize, whatever it calls itself.
  • Outbound requests to the cdn2 through cdn11 subdomains of sendibt1[.]com. Note Sansec's caveat: do not block the apex sendibt1.com itself, which Brevo uses for legitimate email tracking. Only the subdomains were attacker-controlled.

Two things make this harder than a normal hack to spot. There is no defacement, no spam injection, no redirect on your homepage — the site looks completely normal to you. And the compromise window was short enough that many owners never saw a symptom at all. The first sign is frequently external: a browser warning, or a customer telling you something looked wrong. Our walkthrough of the signs your website has been hacked covers the wider symptom set.

How do I remove the backdoor it left behind?

Treat it as a full compromise, not a plugin uninstall. The plugin carried a hardcoded authentication key that lets an attacker mint a valid WordPress administrator session without knowing any password (BleepingComputer, 2026). Deleting the visible plugin and stopping there leaves that capability intact if any copy survives.

Work through it in this order:

  • Take a backup first, even an infected one. You will want it if a cleanup step goes wrong.
  • Delete the plugin directory from disk, not from the dashboard — the dashboard cannot see it.
  • Delete every copy in wp-content/mu-plugins. Files there run on every request with no way to disable them from the admin UI.
  • Force every session to log out, then reset all WordPress admin passwords, plus hosting, FTP, and database credentials.
  • Rotate your own API keys and tokens while you're there. The lesson of this incident is that a long-lived key with broad permissions is a liability.
  • Re-scan with a reputable security plugin and confirm it reports clean. Our guide to WordPress malware removal covers the scan-and-verify loop in detail.
  • Check for admin users you don't recognize, the classic leftover from any backdoor.

If anyone on your team pasted the fake-captcha command into a Run box or terminal, that machine is a separate incident. Sansec's advice is to run an antivirus scan on it urgently, and you should treat any credential typed on that computer as compromised too.

For the broader sequence — what to check, in what order, when a site has been hacked at all — see our step-by-step guide to cleaning a hacked website.

Why is my site blacklisted when the breach wasn't mine?

Because blocklists are built from observed behavior, not attributed blame. A crawler, an antivirus engine, or a browser safe-browsing service records that yourdomain.com served a script that led to malware. That is the verdict. Nothing in that pipeline asks whose CDN the file came from or whether you had any way to prevent it.

This is the part owners find genuinely unfair, and they're right — it is unfair. It is also how every reputation system on the web works, and arguing the point with a vendor does not move it. Google Safe Browsing alone protects billions of devices (Google Safe Browsing, 2025), and it flags at domain level. The compromised vendor gets a news cycle; your domain gets the warning screen.

Worse, the flag usually doesn't arrive alone. Security vendors trade reputation data, so one source flagging you tends to ripple. In our experience running unflagdomain.com, a domain that trips one list has typically tripped several by the time the owner notices — antivirus engines, web blocklists, and search-engine safe-browsing filters, each with its own separate review channel. We scan across 75+ security vendors precisely because the same verdict so rarely lives in only one place. If you want to see where you actually stand before doing anything else, start with how to check if your domain is blacklisted.

One piece of good news specific to supply-chain incidents: the malicious code is usually gone from the source within hours, because the vendor pulls it. That makes your site easier to verify as clean than a typical injected-malware case — as long as nothing was left behind on your server. Which is exactly why the backdoor hunt above comes first.

How do I get the flags removed once the site is clean?

You ask each flagging vendor to re-check the domain. Flags do not expire on their own, and there is no central registry you can file with once.

For Google, the process is manual and cannot be automated: open Google Search Console, find the Security Issues report, confirm the problem is fixed, and submit a review request. Google publishes no API for review submission, so anyone claiming to automate that step is describing something that doesn't exist. Other vendors each run their own false-positive form or security inbox, with their own timelines — some respond in hours, some take weeks, some never reply. Our guide on how long blacklist removal takes sets realistic expectations.

Do not start this before the site is clean. Vendors re-scan when they review a request. A site with a live backdoor fails the re-scan, keeps the flag, and burns the goodwill of a reviewer who now has a reason to look harder next time. This matters more than usual after a supply-chain incident, because "the vendor already fixed their script" is not the same as "my server is clean" — and the plugin in this case was specifically designed to survive that assumption.

Once you're genuinely clean, the remaining work is administrative and tedious: identify every vendor flagging you, find each one's correct contact, and write a request that explains what happened and what you fixed. That is the gap unflagdomain.com fills. After a free scan shows who is flagging you, we dispatch a removal request to each flagging vendor for a one-time €39 — plain text, written separately for each vendor so they don't read as bulk mail, with your own address as Reply-To so replies go straight to you. Our catalog covers 132 active vendors, and Google Safe Browsing stays a guided manual step through Search Console, because it has to be.

To be explicit about the limits: we do not scan for or clean malware — the cleanup above is your job or your security provider's. And we guarantee the dispatch, never the delisting. Every vendor decides independently. If the re-scan after payment comes back with zero flags, the payment is refunded automatically.

How do I stop the next third-party script doing this?

You can't audit a vendor's source code, but you can reduce what a compromised script is able to do.

  • Inventory your third-party scripts. Most sites carry more than their owner remembers — analytics, chat widgets, email tools, ad pixels, heatmaps. Each one is code you execute with full page privileges. Remove what you no longer use.
  • Tighten your Content-Security-Policy to exact hostnames. In this incident the loader was injected into a Brevo-owned host, but the second stage came from a different subdomain. A script-src allowlisting the specific hostname you actually need, rather than a wildcard over the whole domain, would have blocked that second-stage load.
  • Use Subresource Integrity where the file is genuinely static. SRI pins a hash and refuses a modified file. Be honest about the trade-off, though: it breaks by design on a loader the vendor updates on its own schedule, which is why it doesn't fit every tag. Apply it where the file is versioned and stable.
  • Don't browse your own site as a logged-in admin. The WordPress half of this attack only worked against an active administrator session. Use a separate browser profile, or log out, for normal browsing.
  • Keep your own secrets short-lived and narrowly scoped. The root cause here was a long-lived key with full account permissions sitting in source code. That is a mistake any of us can make, and the fix is the same at every scale.
  • Watch your domain's reputation, not just your uptime. A blocklist flag from an incident you never saw can sit for weeks before a customer mentions it. Our guide on stopping your website getting blacklisted again covers the monitoring side.

None of this makes you immune. Brevo is not the first — Sansec documented the same shape of attack in June 2024, when the widely-embedded Polyfill.io CDN library began serving malicious code to a comparable number of sites. A week after that disclosure, Censys was still detecting 384,773 hosts referencing the malicious domain (Censys, 2024). It will happen again to some other widely-embedded script. The goal is to shrink the blast radius and to recognize it quickly when it does.

Someone else's mistake, your domain's reputation

A supply-chain compromise is the most frustrating way to get blacklisted, because there is no bad decision of yours to point at. You embedded a script from a legitimate company that thousands of other businesses also trust. That is not negligence; it is how the modern web is assembled.

What it doesn't change is the recovery. Find out whether anything was left on your server, remove it completely — including the copies designed to hide from your dashboard — rotate every credential, then confirm you're clean. Only after that is it worth asking vendors to look again. Do it in that order and the flags lift on the vendors' normal schedule. Do it out of order and you spend weeks re-earning a verdict you could have cleared once.

// FAQ

  • You were exposed if you embed a Brevo script and served traffic between 16:05 and 20:13 UTC on 14 September 2026. You were likely compromised if a WordPress administrator loaded one of your pages while signed in during that window. Check that day's access log for a POST to /wp-admin/update.php?action=upload-plugin followed by a GET to /wp-admin/plugins.php?action=activate.

  • Delete it from disk, not from the dashboard — it hides itself from the WordPress plugins screen. Then delete any copy in wp-content/mu-plugins, which loads on every request and cannot be deactivated from the admin UI. Afterwards force all sessions to log out and reset every admin, hosting, FTP, and database password, because the plugin carried a hardcoded key that can generate an admin session without your password.

  • Blocklists record what a domain served, not who is to blame. A crawler saw your domain deliver a script that led to malware, and that becomes the verdict. Google Safe Browsing flags at domain level, so the compromised vendor gets a news cycle while your domain gets the warning screen. Appealing on fairness grounds does not work; clearing the flag means proving the site is clean and asking for a re-check.

  • Not reliably. Some vendors re-crawl and drop the listing eventually, but many only re-check when asked, and some hold an entry indefinitely. Google in particular requires a manual review request through the Security Issues report in Search Console — there is no API for it. Every flagged day costs traffic, ad approvals, and email deliverability, so waiting is rarely the cheapest option.

  • For a static, versioned file, yes — SRI pins a hash and the browser refuses a modified file. It doesn't fit a loader script the vendor updates on its own schedule, because legitimate updates would break the page. A tighter Content-Security-Policy helps more here: the second-stage payload came from a different subdomain, so a script-src allowlisting exact hostnames rather than a wildcard would have blocked that load.