When the Third Party Becomes the Attack Path: What Recent Incidents Tell Us About Third-Party Risk
%201.avif)
- Between September 9 and September 17, 2026, three third-party incidents at two providers reached customers through a sign-in flaw, website code, and an application key.
- In two of the three incidents, a public warning came before the provider’s own timeline shows it knew. Trezor warned its users on the evening of September 9 (UTC), about 10 hours before Brevo says it identified the problem.
- Brevo confirmed that 347,149 Trezor marketing contacts were exported through its API. The phishing email came from Trezor’s own sending account and passed the usual authentication checks.
- A retailer hit through the Ribon app key says it heard from BigCommerce about 29 hours after the app’s developer knew the key had been misused.
- Verizon puts third-party involvement at 48 percent of breaches, up 60 percent in a year. An assessment describes a provider’s controls. Current threat intelligence shows when that provider is under attack.
In little more than a week, incidents involving Brevo, Trezor, and connected commerce applications showed how quickly third-party risk can change. These incidents exposed different paths through trusted business relationships: customer communications, embedded website code, and application access.
For security teams, the challenge is determining which developments matter to their organization and what to do next. Periodic assessments provide valuable information about a provider’s controls. Current threat intelligence, connected to the organization’s actual dependencies, helps teams recognize when that provider has become an active attack path.
What happened in the Brevo and Ribon incidents?
Four disclosures between September 9 and September 18, 2026, trace back to two providers, the email marketing platform Brevo and the developer of Ribon, a BigCommerce app:
- Brevo sign-in flaw, September 9 to 10: a flaw in how Brevo handles Security Assertion Markup Language (SAML) single sign-on (SSO) let an attacker reach 138 customer accounts.
- Trezor phishing, September 9, revised September 17: one of those accounts, held by hardware crypto wallet maker Trezor, sent its subscribers a phishing email, and Trezor’s marketing contacts were exported.
- Brevo script injection, September 14: an attacker used a stolen Cloudflare API key to inject code into three JavaScript files that customers embed on their websites.
- Ribon app key, September 13 to 17: a stolen BigCommerce application key held by the Ribon apps exposed shopper records at BigCommerce merchants.
The four disclosures describe three incidents. In each one, the path into the customer ran through a provider and used a different part of the trust a customer extends to that provider.
1. Brevo’s SSO flaw and the phishing email to Trezor’s customers
On September 10, Brevo disclosed that an attacker exploited a flaw in the way Brevo handles SAML SSO and gained access to 138 customer accounts. Six accounts were used to send phishing emails, and contacts were exported from 43 accounts.
The attacker created a Brevo account, enabled single sign-on on it, and invited legitimate Brevo users into that configuration. A login through the attacker’s own identity provider should have reached only the attacker’s account. Brevo says it reached every organization those invited users could access.
Brevo identified the issue at 06:30 UTC on September 10. It closed the route by 08:30 UTC and signed out every user on the platform.
One of the 138 affected customers was Trezor.
Trezor reported that attackers used the legitimate Brevo environment to send its newsletter subscribers an email titled “Critical Security Alert: STM32 Entropy Vulnerability.” The link led to an app that asked for the wallet backup. Trezor took the phishing domain down within 20 minutes, after about 2,500 people had clicked.
On September 17, Trezor updated its disclosure after Brevo confirmed that 347,149 marketing email contacts had been exported through the API. Trezor said its wallet and account systems were not compromised. A month earlier, a breach at another provider, the shipping company ShipMonk, had exposed Trezor customer data.
Why the Brevo SSO incident matters
The phishing email passed the usual email authentication checks, according to Brevo’s post-mortem. It came from Trezor’s real sending account on Brevo’s real infrastructure. Email authentication confirms which system sent a message. It cannot confirm who controlled that system at the time.
Brevo’s write-up describes no step that relied on how customers had configured their own sign-in. The boundary that failed sat inside Brevo, where it separates one customer’s SSO setup from another’s. A vendor questionnaire asks whether a provider supports SSO. The question that mattered here was how the provider keeps one tenant’s logins out of another tenant’s accounts.
Once Brevo confirmed the export, Trezor warned that customer email addresses “could now be used in more targeted email phishing attempts.”
2. Brevo’s stolen key and the injected website scripts
A separate incident followed on September 14, when an attacker used a compromised Brevo Cloudflare API key to deploy a malicious Cloudflare Worker, according to Brevo’s second post-mortem. A Worker is code that runs on Cloudflare’s network and can rewrite a site’s pages before visitors receive them. From 15:01 UTC, it injected a script into pages on brevo.com.
From 16:07 UTC, the Worker also reached sibforms.com, the domain behind Brevo’s signup forms, and added a loader, a line of code that fetches another script, to three JavaScript files that customers embed on their own websites. Brevo removed it at 20:30 UTC.
The script showed selected visitors a fake “verify you are human” page and told them to paste and run a command, a technique known as ClickFix. On WordPress sites that embed a Brevo widget, it also tried to install a plugin when a logged-in administrator visited. BleepingComputer identified that plugin as a persistent backdoor.
Brevo says the long-lived key had full account permissions, sat in application source code, and was first misused in late August 2026. Security firm Sansec estimated that more than 100,000 websites embed the affected Brevo scripts.
The distinction matters. The first incident involved access to customer accounts, contact data, and communications. The second involved trusted third-party code becoming a path to customer websites and their visitors.
14 September 2026 (All times UTC)
Source: Brevo post-mortem; 17:43 from the public X post of 14 September
Why the Brevo script injection matters
Code you load from a provider runs with your website’s trust. Around 90 to 92 percent of pages load third-party resources, according to HTTP Archive’s 2025 Web Almanac. Its security chapter finds Subresource Integrity (SRI) on only 25.9 percent of desktop pages and 23.6 percent of mobile pages. SRI is a hash check that blocks an altered file, and the median site that uses it protects only 2.82 percent of its scripts.
The attack stayed out of sight of Brevo’s own checks. According to Brevo, the Worker rewrote responses at the network edge and removed security headers such as Content Security Policy (CSP). Brevo’s servers and files stayed unmodified, and its standard integrity checks did not detect the change.
Check which of your pages load this provider’s scripts, and whether they were served between 16:07 and 20:30 UTC on September 14. A questionnaire answered months ago cannot tell you that.
3. The Ribon app key that reached shopper records
A stolen BigCommerce application key held by the Ribon apps gave an attacker access to merchant customer data between September 13 and September 17. Ribon and Ribon 1.5 are BigCommerce apps owned by Be A Part Of, a Fastr company.
BigCommerce told BleepingComputer that credentials belonging to the Ribon apps were used “to inject malicious scripts into a small number of merchant storefronts.” It uninstalled the apps from affected stores and notified those merchants.
UK spirits retailer Master of Malt published a detailed timeline of the breach. It shows customer records downloaded page by page on the evening of September 13. By the retailer’s account, the app’s developer knew the key had been misused by 20:45 BST on September 16, and the key was switched off at 22:12 BST on September 17.
BigCommerce emailed the retailer at 01:30 BST on September 18. The retailer says names, email addresses, phone numbers, and addresses were taken, and that passwords and card details were not. Its public notice also says Ribon was installed on hundreds of BigCommerce stores.
Why the Ribon app key matters
A connected app’s key is a standing credential to your customer data. It works around the clock, and its use goes unseen unless someone monitors it. Leaked keys often stay valid for years. Secrets-detection firm GitGuardian found that more than 64 percent of leaked secrets confirmed valid in 2022 still worked when retested in January 2026.
By the retailer’s timeline, the key stayed live for about 25 hours after the developer knew it had been misused. One app’s stolen credentials reached several merchants at once, the pattern that makes compromised API keys a supply-chain threat.
The retailer now alerts on any key that “attempts to download customer data in bulk, is used from a new network, or attempts to make changes to the website’s content or settings.”
What do these third-party breaches have in common?
All three incidents used the trust and access that make third-party services useful in the first place. The rapid succession is part of the lesson. Before a security team has finished evaluating one incident, another demands attention, and it often requires a different response.
Why “Is this vendor secure?” is only the first question
Traditional third-party risk management asks important questions about encryption, multi-factor authentication (MFA), penetration testing, certifications, and security controls. Those answers help organizations judge how well a provider is built. During an emerging threat, security teams need to go further:
- Is this provider being targeted or compromised?
- Does the activity affect a service or integration we use?
- What data, identities, applications, or infrastructure connect that provider to us?
- What evidence supports action, and what should we do first?
Controls are not conditions.
A provider with strong controls and a top security rating can still experience a compromise. A relationship considered low risk at onboarding can become urgent when an attacker finds a way through it. The assessment remains useful. The operating condition has changed.
What is the silent window in a third-party data breach?
The silent window in a third-party data breach is the gap between the moment a provider knows it has been compromised and the moment its customers can act on that knowledge. In two of the three September incidents, a public warning from outside came before the provider’s own timeline shows it knew.
Those public signals helped only the teams already watching for them. Where no public warning appeared, as with the Ribon key, the silent window was set entirely by the provider.
Where threat intelligence should become operational
Threat intelligence creates value when it helps a security team answer a specific question: What does this mean for us? For third-party risk, that means connecting activity to the providers and relationships your business depends on.
Without that connection, context must be assembled after an incident becomes public. Teams have to identify the vendor owner, locate the latest assessment, establish what systems the provider touches, investigate what data it holds, and coordinate a response across security, risk, procurement, legal, and the business.
When several incidents emerge within days, that process becomes harder to sustain. Intelligence needs to help teams establish relevance quickly enough to prioritize the exposures that require attention.
What should you do after a third-party data breach?
An intelligence-led response to a third-party data breach starts with the connection and follows the attack path. The first questions depend on what the provider can reach.
Across these scenarios, the work follows a consistent sequence: identify the connection, examine the evidence, determine the exposure, and route the response to the people who can act. Keep monitoring the provider, and watch for related indicators, until the exposure has been addressed.
A general alert about a provider is only the beginning. Security teams need enough context to make a decision. For teams rebuilding that capability, a practical 90-day plan covers where to start.
See which of your providers attackers are working on right now.
Why third-party risk management needs a time dimension
Third-party risk management needs a time dimension because questionnaires and assessments describe a provider at one moment. A questionnaire records what a provider reported. An assessment captures what was observed. Neither can establish, on its own, what an adversary is doing today.
The September incidents make that time dimension concrete. Brevo disclosed two separate incidents five days apart, each through a different weakness. A provider’s circumstances can change within hours.
Security teams need to know what changed, which relationships are affected, and which developments require action first. Their determination of risk needs to change as the evidence does.
Third-party risk management must be able to respond at that pace, and a program running on a clock that already ran out cannot. Third-party involvement now shows up in 48 percent of breaches, according to Verizon’s 2026 Data Breach Investigations Report.
The next evolution of third-party security is intelligence-led
Assessments, controls, and governance remain essential. Threat intelligence strengthens that foundation by helping teams identify changes in the threat environment and determine their relevance to the enterprise.
These capabilities work together. Assessments help establish the provider’s control environment; current intelligence helps teams understand whether emerging activity requires investigation or action.
No intelligence platform should claim it can prevent every third-party breach. The objective is to recognize relevant changes earlier, understand what they mean, and reduce the time between intelligence and action.
From third-party monitoring to third-party risk determination
This is the problem iCOUNTER built CTOS™, the Counter Threat Operating System, to address.
CTOS applies intelligence to an organization’s unique risk profile, supporting risk determination at the edge of collection, the point where intelligence is first gathered. For third-party risk, that means connecting emerging threat activity with the providers the organization relies on, the relationships that can create exposure, and the evidence needed to guide action.
The resulting determination needs to answer practical questions: What changed? How does it connect to us? What should we investigate, validate, or remediate?
Organizations need to know: this threat matters to this organization right now, because of this relationship, and this action should happen next. The measure of value is how quickly a team can reach a supported decision and get it to the people responsible for acting.
That is what CTOS is built for, helping teams move from broad threat awareness to an evidence-backed determination of what matters to them and what to do about it.
.avif)