When Trust Backfires: The Salesforce Chatbot Breach Explained

Monday 8th September 2025

Several well-known companies have experienced a data breach through their Salesforce systems. The breach happened via a trusted chatbot integration called Drift (owned by Salesloft) that many companies use with Salesforce. By undermining this tool, attackers were able to peek into those companies’ Salesforce customer databases and extract information. This occurred over about a 10-day period in August before being stopped. Investigations have since revealed the attackers first breached Salesloft’s GitHub environment months earlier, allowing them to prepare the attack that played out in August.

Who was affected?

Thus far, the companies that have confirmed being impacted include: 

• Cloudflare (a web security and performance provider),

• Zscaler (a cloud security company),

• Palo Alto Networks (a cybersecurity firm),

• PagerDuty (an IT alerting/monitoring service),

• TransUnion (a consumer credit bureau).

All these organisations are high-profile, and the incident has been described as widespread (potentially over 700 organisations globally) might have had some data accessed. It’s not a targeted attack on one company, but rather a broad attack on many via a common service they used.

What information was stolen?

Only Salesforce CRM data. In plainer language, that means:

• Business contact info – names, work email addresses, phone numbers, company names, job titles.
• Records of interactions – such as support case logs, support ticket details, possibly sales opportunity notes.

No sensitive personal financial information (like credit card numbers) was reported in these specific breaches (TransUnion did lose some personal data like Social Security numbers in the US, but not credit histories, and they are offering two years of free credit monitoring to those individuals).

More importantly for most of our UK clients: none of the products or services you use from those vendors were directly hacked. For example, Cloudflare’s network didn’t get penetrated, and Palo Alto’s firewall software wasn’t altered – the incident was limited to their customer databases.

How could this affect you? The main worry is follow-on fraud or phishing:

• The attackers now have contact details and context. If you’re a customer of any of those companies, the hackers might know your name, job title, company, and what issues or products you’ve discussed with them.
• Using that, they could craft very convincing emails or calls. For instance, an attacker could send an email posing as Palo Alto Networks Support, referencing the exact title of a support ticket your team raised, saying “We need to verify something, please click this link.” Because they can mention something specific that only Palo Alto and you would know, it may not raise suspicion. This is a classic spear-phishing setup.
• They might also target individuals whose personal data was in the TransUnion breach with scams related to identity theft. (TransUnion has not reported UK-specific numbers, and it appears mostly U.S. data was involved, but if your UK organisation uses TransUnion services, there could be some overlap.)

What should you do?

Here are some initial recommendations to stay safe:

1. Be on high alert for phishing attempts – If you get an email or phone call that seems to be from one of those vendors and it’s asking for unusual info or actions, pause and verify. Don’t click links or give out information unless you’re sure. For example, if someone calls claiming to be Cloudflare and asks for your account password, that’s a red flag – hang up and call Cloudflare through their official support number. Similarly, scrutinise emails for correct sender addresses (e.g., an email really from Palo Alto would likely come from @paloaltonetworks.com, not a lookalike domain).

2. Change any shared credentials – Think back: have you ever sent a password, API token, or any secret key to these vendors’ support teams (perhaps to help them troubleshoot)? If yes, assume that could be seen by the bad guys now. It would be wise to change those passwords or revoke those keys. For instance, Cloudflare explicitly encouraged all customers to reset any API keys that were ever shared in tickets, just in case.

3. Less is more (data) – As a longer-term practice, avoid sharing sensitive data in support tickets or chats unless absolutely necessary. Reputable companies usually provide a secure way to share credentials if needed (like an upload portal that masks your input). This incident is a reminder that even support channels can be compromised.

4. Stay informed – Keep an eye on official communications from these vendors. They are actively investigating and will inform you if they discover your data was definitely part of the breach. For instance, Zscaler and Cloudflare have already reached out to the customers they identified in the stolen data. If you’re unsure, you can contact your vendor rep and ask, “Was my account information part of the recent Salesforce-related breach?” They should be able to check and tell you.

5. Don’t panic – It’s important to note what didn’t happen: your infrastructure wasn’t hacked, and it’s not like ransomware where systems go down. The sky isn’t falling. The biggest risk is the indirect one of social engineering. As long as you and your team stay cautious and follow good security hygiene, you can prevent the hackers from capitalising on this stolen data.

6. Review third-party access – As a longer-term safeguard, security teams should regularly review and revoke unused OAuth tokens, scrutinise third-party integrations, and monitor for unusual access through APIs and chatbots. This incident underlines how much trust we place in external services and why regular checks are essential.

How are the vendors handling it?

Quite proactively, in fact:

• Salesforce itself (the platform) has shut down the integration that was exploited. They did this as soon as the issue came to light. So that exact weakness can’t be used further.
• Each company affected has disabled the Drift chatbot and revoked its access to their systems. They’ve also been working with investigators (and likely law enforcement).
• They’re communicating: Cloudflare and Zscaler published detailed blogs, which is how we know what was accessed. Palo Alto and PagerDuty issued statements too. Transparency is a good sign – it means they’re on top of it.
• Preventive steps: Some are tightening their security around third-party access. For example, after this, companies are reviewing all their connected apps to make sure there aren’t other potential weak links. (As an aside, one company, Okta, mentioned that they had security in place that actually blocked this attack attempt from doing any damage, thanks to IP restrictions. Others will likely adopt similar measures.)

Understanding the Cause (FYI): You might wonder how a chatbot caused all this. Essentially, the Drift chatbot had been granted privileges to talk to Salesforce (so it could log chats as leads, etc.). Hackers broke into the chatbot vendor’s systems and stole those privileges (in tech terms, OAuth tokens). It’s as if a building’s security guard’s keys were stolen – not to break into the guard’s room, but to use the guard’s keys to open many offices in the building after hours. In this analogy:

· The “guard” is the Drift app.

· The “keys” are the authentication tokens.

· The “offices” are the Salesforce accounts of each company.

Using those keys, the hackers quietly let themselves into Salesforce data that the chatbot had access to. This type of attack is called a supply-chain attack or third-party integration attack, and it’s a stark reminder that security isn’t just about your systems, but also your vendors’ systems. Google’s Threat Analysis Group tracks this activity as UNC6395, while the cybercrime group ShinyHunters has claimed responsibility. Attribution is not yet fully confirmed

While it’s unpleasant to hear your data might have been caught up in this, the incident is being handled and can ultimately lead to improved security practices industry-wide.

We at Bytes are monitoring the situation closely. Incidents like this highlight that security isn’t only about protecting your own systems but also about keeping a watchful eye on the services and integrations you rely on. If you’d like support reviewing your third-party access, checking OAuth tokens, or strengthening your defences against phishing and social engineering, please get in touch with our team at [email protected]. We’re here to help you stay ahead of risks like this. 

---

Want to keep informed? Sign up to our Newsletter