September 2026 Security Advisory

Brevo has disclosed two separate security incidents in September 2026 involving its customer platform and infrastructure.

The first involved unauthorized access to 138 Brevo customer accounts, with several accounts subsequently used to distribute phishing emails through legitimate Brevo infrastructure.

Days later, a separate compromise involving Brevo’s Cloudflare environment resulted in malicious JavaScript being delivered through Brevo-controlled websites and customer-embedded assets.

Independent security researchers estimate that the second incident had the potential to reach more than 100,000 websites using Brevo components.

Together, the incidents highlight an increasingly important reality for organizations relying on third-party email and marketing platforms:

Trusted infrastructure can still become an attack channel when the systems or accounts controlling it are compromised.

They also raise an important question for organizations whose domains remain configured with DMARC at p=none:

Is your domain actually enforcing protection against unauthorized use, or is it only monitoring it?

I. What Happened at Brevo?

Brevo disclosed two distinct security incidents in September 2026.

Incident 1: SAML SSO Account Compromise

On September 10, 2026, Brevo identified a security issue involving its implementation of SAML Single Sign-On.

According to Brevo’s official incident report, an attacker exploited an authorization-boundary issue to gain access to:

138 Brevo customer accounts

Brevo reported that:

• 6 accounts were used to send phishing emails.
• Contacts were exported from 43 accounts.
• 93 accounts showed no meaningful attacker activity.

Brevo identified the issue at approximately 06:30 UTC on September 10 and stated that the access route had been closed by approximately 08:30 UTC.

The company also signed out every active user across its platform.

According to Brevo, the attacker created a Brevo account, configured SSO and invited legitimate Brevo users into that environment.

The problem occurred because authentication through one organization’s SSO configuration was not properly restricted to that organization.

Instead, the attacker could gain access to other organizations that those invited users could access.

Brevo described the root cause as an authorization boundary that had not been correctly enforced.

II. Phishing Was Sent Through Legitimate Brevo Infrastructure

One of the most important aspects of Brevo’s disclosure is that the phishing messages were not simply spoofed messages sent from unrelated infrastructure.

They were sent through legitimate Brevo infrastructure.

Brevo explicitly stated that:

The messages passed normal email-authentication checks because they originated from legitimate infrastructure.

This distinction is critical.

SPF, DKIM and DMARC can determine whether an email is technically authenticated.

They answer questions such as:

• Was this server authorized to send?
• Was the message cryptographically signed?
• Does the authenticated sending domain align with the visible From domain?

But they cannot answer:

Was the authorized account itself being controlled by an attacker?

If an attacker compromises a legitimate account on an authorized platform and sends messages through correctly configured infrastructure, the resulting messages may successfully pass SPF, DKIM and DMARC.

This is why email authentication should be viewed as one layer of a broader email-security architecture.

A Second Brevo Incident Followed Four Days Later

On September 14, 2026, Brevo experienced a second and technically different security incident.

Brevo confirmed that an attacker obtained a long-lived Cloudflare API key with full account permissions.

According to Brevo, that credential had been stored in application source code.

The attacker used the compromised API key to deploy a malicious Cloudflare Worker within Brevo’s environment.

That Worker was capable of modifying traffic passing through Brevo’s CDN infrastructure.

For approximately five and a half hours, malicious JavaScript was injected into:

• brevo.com
• sendinblue.com
• Brevo login, account and onboarding pages
• sibforms.com
• Brevo Forms
• Brevo Conversations widgets
• Brevo SDK loaders
• JavaScript files embedded by Brevo customers on their own websites

Brevo reported that the primary impact window lasted from approximately:

15:01 UTC until 20:30 UTC on September 14.

The ClickFix Attack

Visitors affected by the malicious JavaScript could see a fake Cloudflare verification page.

The page instructed Windows users to perform actions including:

1. Pressing Win + R
2. Pasting a command
3. Executing that command

Following those steps caused malware to be downloaded onto the victim’s computer.

This technique is commonly referred to as ClickFix.

Brevo also reported that, on WordPress websites embedding affected Brevo components, the malicious script attempted to install and activate a plugin when a logged-in WordPress administrator visited the site.

Brevo removed the malicious Cloudflare Worker, revoked the compromised credentials, deleted attacker-controlled hostnames and purged affected edge caches.

The company stated that the compromised scripts are now safe to use.

More Than 100,000 Websites Potentially Exposed

Brevo has not published an exact number of customer websites that loaded the affected JavaScript.

However, independent security research from Sansec estimated that Brevo’s embedded components were present across more than 100,000 websites.

This does not mean that 100,000 websites were necessarily compromised or that every visitor received malware.

The malicious content was served selectively.

However, the potential distribution footprint demonstrates the amplification effect created when trusted third-party JavaScript infrastructure is compromised.

This is a classic supply-chain risk.

Instead of compromising individual organizations one at a time, an attacker can compromise infrastructure that thousands of organizations already trust.

Two Incidents, Two Different Security Problems

It is important not to combine the two incidents technically.

They involved different attack paths.

September 10

Attack vector: SAML SSO authorization flaw

Impact: Unauthorized access to 138 customer accounts

Result: Phishing emails sent through legitimate Brevo customer accounts and contact data exported from some accounts

September 14

Attack vector: Compromised Cloudflare API credential

Impact: Malicious JavaScript injected into Brevo websites and customer-embedded resources

Potential reach: More than 100,000 websites according to independent security research

Result: ClickFix malware delivery and attempted WordPress persistence

What Does This Have to Do With DMARC?

Neither incident was caused by DMARC.

And neither incident should be represented as something that DMARC alone could have prevented.

However, the incidents highlight why organizations should understand exactly how third-party services are authorized to use their domains.

Brevo’s current documentation provides customers with a DMARC configuration using:

v=DMARC1; p=none; rua=mailto:[email protected]

A p=none DMARC policy is valid.

But it is important to understand what it means.

p=none Means Monitoring

Under the current DMARC standard, a domain configured with:

p=none

is operating in Monitoring Mode.

Receiving mail systems can evaluate DMARC and generate reporting data, but the domain owner is not requesting restrictive treatment based specifically on a DMARC failure.

This makes p=none extremely useful during initial DMARC deployment.

Organizations can discover:

• Which systems are sending email using their domain
• Whether SPF is aligned
• Whether DKIM is aligned
• Which third-party platforms are authorized
• Which unknown infrastructure may be impersonating the domain

But p=none is not DMARC enforcement.

III. DMARC Monitoring vs Enforcement

There are three primary DMARC policy states.

p=none

Monitoring

Provides visibility into authentication and alignment.

No restrictive handling preference is requested based on DMARC failure.

p=quarantine

Enforcement

Requests that receivers treat messages failing DMARC more restrictively.

Depending on the receiving provider, this may involve spam placement, quarantine or other handling.

p=reject

Stronger Enforcement

Expresses the strongest DMARC policy preference for messages that fail DMARC validation.

Receiving providers ultimately retain control over the final disposition of a message.

The practical distinction is:

p=none monitors.

p=quarantine and p=reject enforce a policy.

Did p=none Cause the Brevo Incidents?

No.

This point is important.

In the September 10 incident, attackers gained access to legitimate Brevo accounts.

If a compromised Brevo account sends email through properly authenticated Brevo infrastructure, those messages may successfully pass DMARC.

Changing a domain from:

p=none

to:

p=reject

would not necessarily block an authenticated malicious message originating from a compromised authorized account.

DMARC does not analyze the intent or content of an email.

DMARC answers a different question:

Is this message authenticated and aligned with the domain it claims to represent?

That distinction is fundamental.

Then Why Does DMARC Enforcement Matter?

Consider a different attacker.

This attacker has not compromised Brevo.

They do not have access to Microsoft 365.

They do not have access to Google Workspace.

They do not control any platform legitimately authorized to send email on behalf of the organization.

Instead, the attacker simply tries to send:

From: [email protected]

using infrastructure controlled by the attacker.

If that infrastructure cannot provide SPF or DKIM authentication aligned with company.com, the message fails DMARC.

With:

p=none

the domain owner is primarily monitoring the failure.

With an enforcement policy such as:

p=quarantine

or:

p=reject

the organization expresses a restrictive handling policy for that failed message.

That is one of DMARC’s most important security functions.

It reduces an attacker’s ability to directly impersonate a protected domain using unauthorized infrastructure.

p=none Is Often the Correct Starting Point

Organizations should not simply move every domain immediately to p=reject.

Doing so without understanding the organization’s sending environment can disrupt legitimate email.

Modern organizations may send email through:

• Microsoft 365
• Google Workspace
• Salesforce
• HubSpot
• Brevo
• Zendesk
• Marketing platforms
• Billing systems
• CRM systems
• HR platforms
• Transactional email providers
• Ticketing systems
• Security platforms
• Internal applications

Before enforcement, these systems need to be discovered and correctly authenticated.

That is why p=none is often an appropriate deployment stage.

The question is whether it should remain the permanent security posture.

DMARC Deployed Does Not Always Mean DMARC Enforced

This distinction is frequently overlooked.

A domain can have a valid DMARC record while still operating entirely in Monitoring Mode.

For example:

v=DMARC1; p=none;

means DMARC is present.

But the domain has not moved into enforcement.

This is why organizations should distinguish between:

DMARC deployment

and:

DMARC enforcement

They are not synonymous.

Minimum Compliance Is Not Maximum Protection

Major mailbox providers increasingly require authentication from bulk senders.

These requirements have substantially improved email security across the ecosystem.

But many sender requirements accept:

p=none

as a minimum DMARC policy.

The important word is:

minimum

A company may therefore satisfy a bulk-sender requirement while still operating its domain in Monitoring Mode.

For enterprises, financial institutions, regulated companies and high-value brands, regulatory or platform compliance should not automatically be considered the same thing as maximum domain protection.

IV. Brevo Customers Should Review Their Current DMARC Configuration

Brevo currently provides customers with a DMARC policy using:

v=DMARC1; p=none; rua=mailto:[email protected]

Organizations using Brevo should verify whether this is also their organization’s broader DMARC security policy.

There should only be one valid DMARC record per domain.

Organizations should therefore avoid publishing competing DMARC records simply because multiple email platforms request authentication.

Third-party senders should instead be incorporated into the organization’s existing authentication architecture.

V. Should Organizations Remove Brevo?

Not simply because of these incidents.

If Brevo remains a legitimate business system actively used by the organization, abruptly removing authentication records can disrupt legitimate email.

Instead, organizations should reassess the trust relationship.

1. Confirm Brevo Is Still Required

Every external platform authorized to use a corporate domain should have a legitimate current business purpose.

Unused platforms should not remain indefinitely authorized.

2. Review Brevo Account Security

Organizations should review:

• Administrator accounts
• SSO configuration
• Privileged users
• API credentials
• SMTP credentials
• MFA configuration
• Account-access logs

3. Review Your DMARC Policy

Determine whether the organization’s domain currently operates at:

p=none

p=quarantine

or:

p=reject

Do not assume that the existence of a DMARC record means the domain is enforcing DMARC.

4. Identify Every Authorized Sender

Organizations should understand every platform currently sending email using their domains.

Unknown sending infrastructure should be investigated.

5. Validate SPF and DKIM Alignment

Legitimate sending services should satisfy DMARC through correctly aligned SPF and/or DKIM.

This allows legitimate mail to continue while unauthorized infrastructure is identified.

6. Move Toward Enforcement Where Appropriate

Once legitimate senders have been discovered and authenticated, organizations should evaluate whether continuing indefinitely in Monitoring Mode reflects their desired security posture.

7. Do Not Publish Multiple DMARC Records

A domain should have one coherent DMARC policy.

Adding additional independent DMARC records can create an invalid configuration.

VI. Additional Actions Following the September 14 Incident

Organizations using Brevo website components should also review Brevo’s remediation guidance.

Brevo specifically recommends action if a user interacted with the malicious content on September 14.

If the ClickFix command was executed

Treat the affected computer as potentially compromised.

Brevo recommends:

• Disconnecting the system
• Running a complete security scan
• Changing passwords used on the device
• Prioritizing Brevo account credentials

If a WordPress administrator visited an affected site

Organizations using Brevo scripts on WordPress should review plugins installed or activated on September 14.

Brevo recommends removing suspicious plugins and changing administrator credentials.

If a user logged into Brevo on September 14

Brevo recommends changing the account password and reviewing API credentials as a precaution.

VII. What Skysnag Customers Should Do

For Skysnag customers using Brevo, there is no automatic requirement to remove Brevo as an authorized sender.

Brevo can remain integrated as a legitimate sending platform while Skysnag continues to manage the broader domain-authentication and DMARC policy.

Your existing Skysnag-managed DMARC configuration should not be replaced by a generic p=none record simply because Brevo requests domain authentication.

The objective is not to block legitimate infrastructure.

The objective is to ensure that:

• Legitimate services remain authenticated
• Unauthorized sources cannot easily impersonate the domain
• DMARC alignment remains correct
• The domain’s enforcement policy remains controlled
• Changes to the sending environment remain visible

VIII. The Larger Security Lesson

The two Brevo incidents illustrate two different forms of third-party risk.

The first showed that:

A legitimate email account can become a phishing channel when account authorization fails.

The second showed that:

Trusted web infrastructure can become a malware distribution channel when infrastructure credentials are compromised.

Organizations increasingly depend on interconnected networks of:

• SaaS providers
• Email platforms
• Marketing systems
• CRMs
• CDN infrastructure
• JavaScript libraries
• Cloud providers
• Transactional email systems

Each trusted integration expands the organization’s operational capabilities.

It also expands its trust boundary.

That means modern domain security must be layered.

Account security protects access to authorized platforms.

SPF authenticates sending infrastructure.

DKIM authenticates messages.

DMARC validates domain alignment.

DMARC reporting provides visibility.

DMARC enforcement strengthens protection against unauthorized direct domain impersonation.

No single control solves every class of attack.

The objective is to make those controls work together.

IX. Monitoring Should Lead to a Security Decision

DMARC p=none has an important purpose.

It provides organizations with the intelligence required to understand their sending environment before introducing enforcement.

But monitoring is most valuable when it ultimately informs a security decision.

Once authorized senders have been identified and properly authenticated, organizations should determine whether remaining indefinitely at p=none reflects the protection level they actually require.

Because there is an important difference between:

Knowing that someone is impersonating your domain

and:

Publishing a policy intended to prevent unauthorized infrastructure from successfully impersonating it.

Monitoring provides visibility.

Enforcement turns that visibility into policy.

X. Check Your Domain

If your organization uses Brevo and you are unsure whether your domain currently operates at p=none, p=quarantine or p=reject, Skysnag can assess your current email-authentication posture, identify authorized sending infrastructure and determine an appropriate path toward enforcement without unnecessarily disrupting legitimate email.

Check your domain with Skysnag.