When Brevo's compromised Cloudflare API key went undetected from late August until it was weaponized on September 14, the company joined a growing list of organizations that discovered their third-party integrations had become attack vectors. The malicious worker ran for five and a half hours, injecting scripts into over 100,000 websites. This wasn't just a Brevo problem; it revealed systemic gaps in how teams manage API security and third-party access.
These mistakes aren't rare. They're predictable, preventable, and still happening across enterprise TPRM programs.
Why These Mistakes Keep Happening
Most teams treat API keys like credentials: create them during implementation, store them somewhere, and move on. But API keys function as permanent access grants to critical infrastructure. Unlike user sessions that expire or SSO tokens that refresh, long-lived API keys persist indefinitely unless explicitly revoked. When your vendor gets breached, those keys become the attacker's keys.
The Brevo incident started with a SAML SSO vulnerability on September 10. Attackers gained initial access, were locked out, then returned four days later using a Cloudflare API key that had been active, and compromised, since late August. That's a 16-day window where the key was already in attacker hands before anyone weaponized it.
Your monitoring probably wouldn't have caught it either.
Mistake 1: Treating API Keys as Set-and-Forget Credentials
Why it happens: Implementation teams generate API keys during vendor onboarding, embed them in configuration files or CI/CD pipelines, and never revisit them. There's no expiration forcing a refresh, no quarterly review, no owner assigned to track usage.
Real consequence: When Brevo's Cloudflare API key was compromised in late August, it sat dormant for weeks. The attackers had time to map the environment, identify high-value targets, and plan their injection strategy. By the time the key was used to deploy a malicious worker on September 14, the damage was already scoped.
The fix: Implement a 90-day rotation policy for all long-lived API keys tied to third-party services. Assign each key an owner in your CMDB or vendor inventory. If rotation isn't technically feasible (some legacy integrations can't handle it), flag those keys as high-risk and add them to your continuous monitoring scope. Use your vendor's audit logs, most platforms now offer API activity tracking, to establish baseline behavior and alert on anomalies.
Mistake 2: No Scope Limits on Third-Party API Access
Why it happens: Vendors request broad API permissions during implementation ("we need admin access to make this work"), and procurement or IT approves without challenging the scope. It's faster to say yes than to negotiate least-privilege access with a vendor's support team.
Real consequence: The compromised Cloudflare API key had sufficient permissions to deploy a worker that modified JavaScript files embedded across 100,000+ websites. If that key had been scoped to read-only DNS management or limited to specific zones, the attack surface would've been contained. Instead, full worker deployment rights turned a single key into a supply chain weapon.
The fix: During pre-contractual assessment, document the minimum API scope required for each integration. If the vendor requests admin or write access, require written justification tied to specific features. For critical integrations, negotiate separate keys for different functions, one for read-only monitoring, another for configuration changes. Review permissions quarterly and revoke unused grants. This is especially important for infrastructure-layer vendors like CDNs, where broad access can affect downstream customers.
Mistake 3: Ignoring the Initial Breach as "Contained"
Why it happens: When you detect and remediate an incident, there's pressure to close the ticket and move on. If the initial vector (in Brevo's case, the SAML SSO vulnerability) is patched and unauthorized access is terminated, teams assume the threat is neutralized.
Real consequence: Brevo closed the September 10 unauthorized access but didn't audit what the attackers had touched during that window. Four days later, the same threat actor returned using a credential that had been compromised before the initial breach. The "contained" incident wasn't contained, it was paused.
The fix: After any vendor breach notification, require a full credential and access audit. Ask your vendor: What credentials were accessible to the compromised accounts? What API keys, service accounts, or tokens existed in the environment during the breach window? If your vendor can't or won't provide this, escalate it as a contractual issue under your Right to Right to Audit. For your own environment, treat any vendor breach as a potential fourth-party exposure event. Rotate all API keys and tokens tied to that vendor, even if the vendor claims they weren't accessed.
Mistake 4: No Detection for Malicious Code in Embedded Third-Party Scripts
Why it happens: Your team monitors your own application code through CI/CD pipelines and security scans, but third-party JavaScript files load directly from the vendor's domain. You don't control the source, and most monitoring tools don't fingerprint external scripts for unexpected changes.
Real consequence: Brevo's attackers modified three JavaScript files that customers embedded into their websites. For roughly four hours, every site loading those files served malicious code to visitors. Site owners had no visibility into the change, the files were hosted on brevo.com and sibforms.com, domains they trusted. Sansec estimates over 100,000 sites were impacted, many of which still don't know if they were compromised.
The fix: Implement Subresource Integrity (SRI) hashes for all third-party JavaScript files you embed. SRI ensures the browser only executes the script if its hash matches the expected value, if the vendor's file is modified (maliciously or otherwise), the browser blocks it. For vendors who update their scripts frequently, use a Content Security Policy (CSP) with strict source whitelisting and monitor for CSP violations. If you're embedding vendor widgets on customer-facing pages, add those vendors to your Criticality Classification as Tier 1 (critical) and require them to notify you of any code changes before deployment.
Mistake 5: No Incident Escalation Playbook for Vendor Breaches
Why it happens: Your incident response plan covers breaches of your own systems, but it doesn't define who owns response when a vendor is breached and your environment is exposed. Procurement thinks IT owns it, IT thinks security owns it, and security is waiting for the vendor to provide details.
Real consequence: Brevo's customers had five and a half hours to detect and block the malicious worker, but most didn't know it was happening. Even after Brevo disclosed the incident, site owners needed specific guidance: check for unauthorized WordPress plugins, scan visitor machines for malware, review admin login activity. Without a pre-defined escalation path, each customer had to figure out their own response.
The fix: Build a vendor breach escalation matrix that defines roles, notification timelines, and response actions for different breach scenarios. If a vendor notifies you of a breach involving API keys or embedded code, your playbook should trigger: immediate key rotation, script integrity checks, downstream customer notification (if you're a platform), and forensic review of access logs during the exposure window. Require your Tier 1 vendors to provide a notification timeline in their contracts, Brevo's post-mortem transparency is good, but contractual SLAs ensure you're not waiting days for details.
Prevention Checklist
Use this during vendor intake and quarterly reviews:
- All API keys tied to third-party services have assigned owners and 90-day rotation schedules
- API permissions are scoped to least-privilege; admin access requires written justification
- Vendor contracts include notification timelines for breaches involving credentials or code
- Third-party JavaScript files use SRI hashes or CSP monitoring
- Incident response playbook defines vendor breach escalation paths and response actions
- Post-breach audits include full credential review, not just the initial attack vector
- Tier 1 vendors (those with embedded code or infrastructure access) undergo quarterly access reviews
- Your team has a documented process to notify downstream customers if you're a platform provider
The Brevo attack succeeded because multiple controls failed in sequence: long-lived keys, broad permissions, incomplete post-breach audits, and no runtime integrity checks. Your supply chain is only as secure as the weakest link in that chain. Start with the API keys.
