Why a Long-Lived CDN API Key Is the Most Dangerous Secret in Your Codebase

Most secrets-management programmes rank credentials by what they unlock directly: a database password, a cloud root key, a domain admin account. The Brevo incident of 14 September 2026 argues for a category that usually sits lower on the list. A single Cloudflare API key with full account permissions, committed to Brevo's application source code, let an attacker deploy a Worker that rewrote the company's embedded JavaScript in flight and pushed malware to more than 100,000 customer sites. No server was compromised. The key alone was enough, and it had been in the attacker's hands since late August.

What the Key Actually Controls

A CDN or edge-platform account key is not a key to one system. On Cloudflare, an account-scoped token with edit permissions can create DNS records in any zone the account owns, create Workers, and attach them to routes. Cloudflare's documentation describes the effect of a route: when a request matches the pattern, "your Worker will execute on that route," running before the origin and able to modify requests and responses on the way through.

Translate that into blast radiusBlast Radius🛡️The full set of systems, data, and access an attacker can reach after compromising a given asset. Ranking assets by blast radius rather than by how exposed they are pushes high-reach systems like a firewall management console to the top of the priority list.. A compromised web server gives an attacker one origin. A compromised edge account gives them every hostname the company serves, the ability to create new hostnames under the company's legitimate domains, and a position in the response path that no origin-side control can see. Brevo's attacker used all three: new `cdn*` subdomains under Brevo's real email-tracking domain, a Worker routed to brevo.com and sibforms.com, and response rewriting that appended a loader to three embedded scripts and stripped the Content-Security-Policy header on the way out.

The multiplier is the customer base. Brevo's embedded assets are loaded by other people's websites, so the edge account's reach extended past Brevo's own properties to every page that trusted the script tag. The mechanics of that trust are laid out in "Why a Third-Party Script Tag Hands Its Vendor Control of Every Page It Loads On." From the key holder's perspective, the point is simpler: an edge credential at a SaaS vendor is a credential to the vendor's customers.

Why It Stays Invisible

Three properties of this credential class make misuse hard to notice, and Brevo's timeline shows each one.

**Nothing changes at the origin.** Brevo's write-up states that because the Worker rewrote responses at the edge, "our origin servers remained unmodified." File-integrity monitoring, deploy verification and code review all inspect the origin, and all of them passed. Sansec observed from outside that the modified files kept the same Last-Modified dates throughout. Any control that answers "has this file changed?" by asking the server that hosts it is blind to edge rewriting.

**The platform does not alert by default.** Cloudflare keeps an audit log of account-level actions and zone configuration changes for 18 months and can export it through the API or Logpush. But its notification catalogue contains no built-in alert for a Worker deployment, a route change, or the creation of an API token. The record exists; the alarm does not, unless you build it. Brevo's Worker went from first hostname to full production impact in 38 minutes and stayed there for four and a half hours before the company opened an incident.

**Long-lived keys have no natural expiry event.** The key was first misused in late August, which means it sat quietly usable for roughly three weeks before the attacker did anything visible. A short-lived token would have expired during that dormancy. A key with no TTL will wait as long as the attacker does.

The Planning Work

This is a programme problem, not a patch. The following are the decisions to make before the next incident, roughly in order of return on effort.

**Inventory every edge and DNS credential.** List each API key and token that can touch CDN configuration, DNS, Workers or equivalent edge compute, where it is stored, what permissions it holds, which zones it can reach, and when it was last rotated. If the answer to "where is it stored" is a repository, that is finding number one. Brevo's key was in application source code, the usual location for this class of secret because deployment tooling needs it.

**Replace account-wide keys with scoped tokens.** Cloudflare's token model lets you choose permission groups at the Account, User or Zone level, distinguish Edit from Read, restrict a token to named zones, filter by client IP addressIP Address🔐A unique numerical identifier assigned to every device connected to the internet., and set a TTL. A token that can only edit DNS in one zone from one CI runner's address for the next hour cannot deploy a Worker to production. New tokens carry a `cfut_` prefix so that secret-scanning tools can recognise them if they leak. Brevo's post-incident change was to remove hardcoded credentials and replace them with "narrowly scoped, short-lived tokens"; that is the target state.

**Move the secret out of the code path.** Brevo is adopting HashiCorp Vault with automatic rotation. The product matters less than the property: the deployment process fetches a fresh credential at run time and nothing durable lives in a file. The edge credentials belong in the same rotation inventory described in "How to Rotate Every Secret After a Server Compromise," not on a separate, forgotten list.

**Build the alert the platform does not ship.** Stream the audit log to your monitoring system and fire on any event that creates or modifies a Worker, a route, a DNS record in a production zone, an API token, or account membership. Brevo's hardening list includes exactly this: alerts on Cloudflare events modifying Workers, routes, DNS or account access, plus streaming Cloudflare logs into security monitoring. It is the control that would have turned a five-hour window into minutes.

**Monitor what you serve, from outside.** Because the origin cannot see edge rewriting, fetch your own public assets from the internet on a schedule and compare hashes against the build you deployed. Brevo's list calls this "regular external scanning of public pages and scripts" and "integrity protection for versioned embedded assets." If you ship a loader that customers embed, publish versioned URLs alongside the auto-updating one so that customers who want to pin with Subresource Integrity can.

**Review who and what is on the account.** After revoking the key, Brevo "reviewed every credential and member on the Cloudflare account." Do that review before an incident and on a schedule. Orphaned tokens from departed engineers and shared keys used by more than one pipeline are the usual findings.

Rehearse the Response

Write down, now, what the first hour looks like if an edge credential is confirmed stolen: who can revoke the key, who can delete Workers and routes, how you purge the edge cache, how you verify from outside that clean content is being served, and how you notify customers who embed your assets. Brevo's recovery sequence, removing the Worker and attacker hostnames, revoking the key and everything created with it, purging caches and then independently verifying, is a reasonable runbook skeleton. If any customer of yours runs WordPress, the incident notice should also point them at the checks in "How to Find a Hidden WordPress Plugin Backdoor After a Supply-Chain Injection," because the damage on their side outlasts the fix on yours.

The Ranking, Revisited

A domain admin credential compromises one organisation. A long-lived edge key at a vendor whose script tag sits on 100,000 sites compromises 100,000 of them, silently, without touching a server, and with no alert unless someone built one. Treat it as the highest-privilege secret in the codebase and plan accordingly.