Third-party scripts and CDNs: your website can be compromised without your server being hacked

A chat widget, form, analytics tool or SDK loaded from a third-party domain extends a website’s trust boundary. If that dependency is compromised at a CDN or edge layer, browsers can receive malicious code even when no file on the origin server has changed.

What happened at Brevo

On September 14, 2026, Brevo suffered a supply-chain incident separate from its earlier SSO incident. According to the company post-mortem and subsequent analyses, a long-lived, over-privileged Cloudflare API key present in application source code was stolen. The attacker was then able to create a Worker and modify responses at the Cloudflare edge.

For roughly five and a half hours, malicious content could be injected into Brevo pages and into some Brevo scripts embedded on customer websites, including form and conversation components. Visitors could receive a fake ClickFix verification, and observed scenarios also targeted logged-in WordPress administrators.

Why the origin server could remain clean

An integrity check performed only on server files answers a useful question: “did my files change?” It does not necessarily answer the more important user-facing question: “what is the browser actually receiving?”

A CDN, reverse proxy, edge Worker or third-party service can transform a response after it leaves the origin server. In that situation, comparing local files or the Git repository may reveal nothing. Those checks need to be complemented by external observations of the delivered response.

A third-party script extends your trust boundary

JavaScript running in a page often has broad access to that page context. Depending on its placement and the protections in place, it may read or modify the DOM, trigger requests, load other resources or present a deceptive interface to the user.

This does not mean every third-party service must be removed. It means they should be inventoried, unnecessary ones reduced and meaningful changes monitored.

Controls that become useful

• Inventory third-party scripts and domains actually loaded by important pages.
• Detect new scripts or domains, as well as removals or unusual changes.
• Observe the site externally to check the response actually delivered to the browser, not only the origin.
• Deploy a Content Security Policy progressively, ideally starting in report-only mode, to restrict allowed script sources.
• Use Subresource Integrity when a resource is static and compatible with it; this control does not fit every dynamic script.
• Restrict API keys and tokens to the minimum required, avoid secrets in source code and prefer short-lived or easily revocable credentials.
• Keep a history of dependencies and changes so expected evolution can be distinguished from anomalies.

What this changes for monitoring such as InfraCheck

For TechAtelier, this incident reinforces a product direction that already fits asset discovery: progressively add an inventory of web dependencies visible from the outside. The goal is not to analyze every line of JavaScript, but to identify third-party scripts and domains, keep a baseline and flag changes that deserve review.

This can then be correlated with other signals: CSP, new domains, content changes, service exposure and incident history. It reduces blind spots without turning every legitimate change into a critical alert.

Quick website checklist

• list external scripts present on sensitive pages;
• remove integrations that are no longer needed;
• review your CSP and allowed domains;
• check changes from an external point of view;
• protect CDN accounts and APIs with least privilege;
• treat every unexpected new dependency as an event to review.

Sources

• Brevo — ClickFix incident post-mortem
• Sansec — Brevo supply chain attack
• BleepingComputer — Brevo supply-chain attack

Published September 18, 2026. The facts described reflect public information available on that date.