Your Vendor's Breach Can Become Your Cybersecurity Incident

In August 2025, a stolen token belonging to a chat tool changed the week for hundreds of companies that had never been breached themselves. 

Attackers took OAuth and refresh tokens tied to the Drift AI chat agent, a third-party app in Salesloft's platform, and used them to pull data out of customers' Salesforce accounts. Google's threat intelligence group told The Hacker News it was aware of "over 700 potentially impacted organizations." 

Ten months later, in June 2026, it happened again with a different vendor, Klue. The affected customers had not been phished, had not missed a patch, and had not misconfigured anything. They still had an incident to investigate. That is third-party breach risk in practice, and it is now one of the most common ways a breach begins.

 

 

The Numbers

Verizon's 2026 Data Breach Investigations Report, as reported by Expert Insights, found that 48% of breaches involved a third party, up from 30% in the previous year's dataset, a rise of about 60%. The report's dataset covers more than 22,000 breaches across 145 countries. In India, IBM's 2026 Cost of a Data Breach findings list supply chain compromise as the initial attack vector in 15% of breaches, behind phishing at 19% and drive-by compromise at 16%.

 

Verizon describes three forms of third-party exposure: a vendor in your software supply chain, a vendor hosting your data, and a vendor connected to your environment. Few organisations can name everything in the third.

 

 

Case One: Drift and Salesloft (August 2025)

According to Salesloft's account and Google's analysis, activity ran from as early as 8 August through at least 18 August 2025. The attacker used stolen OAuth and refresh tokens to reach customers' Salesforce instances and ran queries against objects including Cases, Accounts, Users, and Opportunities. Google reported that attackers exported large volumes of data, likely to harvest credentials such as AWS access keys, passwords, and Snowflake-related access tokens, and deleted query jobs to cover their tracks. Salesloft issued an advisory on 20 August and revoked the Drift-Salesforce connections.

 

Two things stand out. First, the scale was disputed. Google counted over 700 potentially impacted organisations, Salesloft said the exact scale was not known, and Salesforce described a "small number of customers." Even the parties involved could not agree on how far it reached. Second, the data stolen was a path to more. Support cases and CRM records contained secrets that attackers could use against other systems.

 

 

Case Two: Klue (June 2026)

BleepingComputer reported on 18 June 2026 that Klue, a market intelligence platform, suffered an OAuth breach. Per Huntress, attackers compromised Klue's backend, pushed a malicious code update that stole customer OAuth tokens used for its Salesforce integration, and used a dormant prototype-integration credential to get in. ReliaQuest observed automated scripts querying Salesforce's REST API for nearly 24 hours, including almost a thousand queries in one 15-minute window. A group calling itself Icarus sent extortion emails. Salesforce disabled the connection and Klue disabled several integrations while investigating.

 

The shape matches Drift: a vendor compromise, tokens instead of passwords, and customers learning from someone else. Note the dormant credential: an unused integration is still a way in.

 

 

What These Cases Show

* MFA on your own accounts does not help. The tokens belonged to an integration. The attackers never needed a user's password or second factor.

 

* Your logs may be the only evidence. Both Google and Huntress advised customers to review Salesforce logs for unusual API activity, revoke and rotate OAuth tokens, and end active sessions. If your SaaS audit logs are off or short-lived, you cannot answer whether you were affected.

 

* A vendor's breach lands on your notification duties. This is where India's rules matter.

 

 

What Indian Law Says About Vendor Responsibility

Section 8(1) of the DPDP Act states that a Data Fiduciary remains responsible for complying with the Act whether it processes data itself or through a Data Processor, "irrespective of any agreement to the contrary." Section 8(5) requires reasonable security safeguards for personal data in its possession or under its control, including data processed by a processor on its behalf. Under Section 8(6), after a personal data breach the fiduciary must notify the Data Protection Board and each affected Data Principal. Section 8(2) permits processors only under a valid contract.

 

In practice, you cannot hand the duty to your vendor along with the data. The main DPDP duties are due to apply from about mid-May 2027. CERT-In's six-hour reporting rule for serious incidents applies today. Check with counsel how your vendor contracts line up with both.

 

 

Managing Third-Party Breach Risk: Eight Measures

1. Build the inventory, including integrations. List not just vendors you pay, but every OAuth app, API key, and plug-in connected to core systems. Include dormant ones.

 

2. Tier by data and access. A vendor that holds customer records or has write access to production deserves more scrutiny than a design tool.

 

3. Limit what each integration can reach. Grant the narrowest scopes, restrict by IP address where possible, and set token lifetimes you can live with.

 

4. Write breach duties into contracts. Specify how quickly the vendor must tell you, what they must tell you, how they will cooperate, and what evidence you can request. Align timelines with your own six-hour and 72-hour obligations.

 

5. Ask for evidence, not assurances. Certifications such as ISO 27001 or SOC 2 are useful, but check scope and dates, and ask for test summaries and remediation status.

 

6. Keep logs long enough to investigate. Enable audit logging on key SaaS platforms and retain it. Without it, you cannot scope a vendor incident.

 

7. Pre-write the vendor-incident playbook. Based on the guidance after Drift and Klue: identify the connected app, revoke and rotate tokens and keys, end sessions, review logs for the exposure window, check what secrets sat in exposed records, and decide who files which notification.

 

8. Offboard and review. Remove integrations that are unused, and re-tier vendors each year.

 

 

Test the Playbook Once

Run a tabletop on this exact scenario: a SaaS vendor emails you at 7 p.m. saying its integration tokens were stolen. Who revokes them? Who reviews logs? Who decides whether notification is required? An hour of this teaches more than a quarter of questionnaires.

 

 

Where ILLUME Intelligence Can Help

ILLUME Intelligence helps organisations assess the security of critical vendor integrations, structure vendor requirements and evidence reviews, and prepare for incidents that originate outside their walls. Our Incident Response service supports investigation and notification when a vendor event touches you, our DPDP compliance and DPO Services help align processor contracts and breach workflows, and our vCISO service can own the third-party risk programme. A review of your top ten integrations is a practical first step.

 

 

The Bottom Line

You cannot prevent your vendors from being breached, but you can decide how much a vendor's breach can reach, how soon you would know, and how prepared you are to act. Inventory the connections, narrow their access, keep the logs, write the contract terms, and rehearse. The next vendor incident is a matter of when.

---

Comments

---

No Comments Found.