Protect What Matters
Secure endpoints, email, and employees with the power of our 24/7 SOC. Try Huntress for free and deploy in minutes to start fighting threats.
Cloudflare Data Breach
A hiccup in a third-party vendor’s system sent ripples through Cloudflare, a major player in internet infrastructure. This wasn't your typical smash-and-grab; it was a subtle exploit of a vendor's security gap that led to a breach. While the direct impact on Cloudflare was contained, the incident highlights just how interconnected our digital supply chains are and how one weak link can expose even the most fortified systems.
Cloudflare Data Breach explained: What happened?
The Cloudflare data breach stemmed from security incidents at two of its third-party vendors, Salesloft and Drift. Attackers compromised these platforms, which Cloudflare's sales and support teams used for customer relationship management. This access allowed the threat actors to view certain customer data, specifically from individuals who had interacted with Cloudflare’s sales and support teams.
When did the Cloudflare Data Breach Happen?
The attack unfolded between August 9 and August 17, 2025. Cloudflare was notified by Salesforce and Salesloft on August 23, 2025. After completing their own forensic investigation, Cloudflare publicly disclosed the incident on September 2, 2025, via their security blog—directly notifying all affected customers by email and dashboard banner the same day.
Who Hacked Cloudflare?
The threat actor has been identified. Cloudflare's own threat intelligence team, Cloudforce One, named the group GRUB1. Google's Threat Intelligence Group tracked overlapping activity under the designation UNC6395, and Mandiant's investigation confirmed the same actor was behind the broader Salesloft Drift campaign targeting hundreds of organizations globally. The group's objective appears to have been credential harvesting at scale—using stolen Salesforce support case data to fuel follow-on attacks against the customers of every affected organization.
How Did the Cloudflare Breach Happen?
This is a B2B supply chain attack—business to vendor to vendor—and understanding the chain matters.
Salesloft is a sales engagement platform. Their Drift product is a chat tool that integrates with Salesforce via OAuth, allowing it to read and interact with CRM and support data on behalf of customers. Salesloft's GitHub account was compromised as early as March 2025, giving GRUB1 months of access to conduct reconnaissance before the active phase of the attack began in August.
By the time they turned their attention to Cloudflare, they already held valid OAuth tokens for the Drift-to-Salesforce integration. Those tokens didn't require breaking into Cloudflare's network—they gave the attacker authenticated access through a trusted integration channel that blended neatly into normal API traffic.
Attack timeline
- August 9, 2025: GRUB1 conducts initial reconnaissance, attempting to validate a Cloudflare API token using TruffleHog (an open-source secrets scanner) as their user agent. The token fails validation.
- August 12, 2025: GRUB1 logs into Cloudflare's Salesforce tenant using the stolen Drift OAuth credential from IP
44[.]215[.]108[.]109and begins enumerating available data objects. - August 13, 2025: GRUB1 returns to pull case schema information and begins broad queries against Cloudflare's case objects.
- August 14, 2025: Extensive reconnaissance day. GRUB1 counts accounts, contacts, and users; analyzes case workflows; confirms they're in a production environment; and queries API rate limits to understand how to exfiltrate data without triggering detection.
- August 16, 2025: GRUB1 returns after a 48-hour pause and runs a final record count (
SELECT COUNT() FROM Case) to confirm the exact size of the dataset they're about to steal. - August 17, 2025: GRUB1 switches to new infrastructure (
208[.]68[.]36[.]90) and uses Salesforce's Bulk API 2.0 to exfiltrate all case text data in just over three minutes. They attempt to delete the job to cover their tracks, but residual logs allow Cloudflare to fully reconstruct the attack. - August 20, 2025: Salesloft revokes Drift-to-Salesforce connections across their customer base. Cloudflare has not yet been notified at this point.
- August 23, 2025: Salesforce and Salesloft notify Cloudflare. Cloudflare immediately begins their incident response.
- August 25–29, 2025: Cloudflare disables the Drift integration, purges all Salesloft software from their environment, rotates credentials across all third-party services, and begins analyzing the exfiltrated data for exposed secrets.
- September 2, 2025: Cloudflare publicly discloses the incident and directly notifies all affected customers.
Technical Details
GRUB1 accessed Cloudflare's Salesforce environment entirely through the legitimate Drift OAuth integration—no malware, no endpoint compromise, no network intrusion on Cloudflare's side. The attack succeeded because the integration had been granted access to Salesforce case objects, and the attacker held valid credentials for that integration.
The exfiltration used Salesforce's native Bulk API 2.0, which is designed for large data exports. GRUB1 then attempted to delete the API job to hide their tracks. Cloudflare's forensic team was still able to reconstruct the full attack from residual log data.
Indicators of Compromise (IoCs)
No specific Indicators of Compromise (IoCs) such as IP addresses, file hashes, or domains were released publicly by Cloudflare. The investigation focused on the scope of access within the third-party applications rather than malware or network intrusions on Cloudflare’s own systems.
Forensic and Incident Investigation
Cloudflare’s internal security team conducted a thorough investigation immediately upon being notified. They worked to understand the full scope of the breach by analyzing logs and access records within the compromised vendor platforms. Their findings confirmed that no Cloudflare systems were directly breached and that the exposure was limited to data housed within Salesloft and Drift. They also took immediate steps to contain the threat by disabling the integrations and forcing password resets for affected employees.
What Data Was Compromised in the Cloudflare Breach?
The compromised data was limited to customer information used for sales and support interactions. This included:
Customer names
Email addresses
Phone numbers
Company names
The content of support and sales communications
Crucially, Cloudflare confirmed that no sensitive financial information, passwords, or core customer configuration data was exposed.
How Many People Were Affected by the Cloudflare Data Breach?
Cloudflare identified 104 of their own API tokens in the exfiltrated data and rotated all of them immediately—no suspicious activity was identified against those tokens. Beyond that, the number of individual customers whose contact information or case content was exposed has not been publicly quantified, but Cloudflare directly notified every affected customer by email and dashboard notification.
Was My Data Exposed in the Cloudflare Breach?
If your data was exposed, you likely would have been notified by Cloudflare. The breach specifically affected individuals who had communicated with Cloudflare’s sales or support teams. If you did not interact with these teams, it's unlikely your data was involved. There is no public lookup tool to check for exposure.
Key Impacts of the Cloudflare Breach
While not a catastrophic breach of its core systems, the incident had several key impacts:
Reputational Damage: As a leading cybersecurity and infrastructure company, any security incident, even indirect, can affect trust.
Operational Disruption: Cloudflare had to temporarily suspend the use of the affected platforms, disrupting sales and support workflows.
Customer Concern: The breach raised concerns among customers about how their data is handled, even by third parties.
Supply Chain Scrutiny: The incident put a spotlight on the inherent risks of relying on third-party vendors and the need for rigorous vetting.
Response to the Cloudflare Data Breach
Cloudflare’s response was swift and transparent. Within hours of confirming the incident, the company published a detailed blog post outlining what happened, what data was exposed, and the steps they were taking. This included:
Immediately disabling the compromised applications.
Forcing password and session token rotations for any employee who may have been impacted.
Working with the vendors to understand the root cause.
Communicating openly with customers and the public.
This fast, clear communication is a solid model for effective data breach response.
Lessons from the Cloudflare Data Breach
This incident offers some critical takeaways for any business. You don't want to learn these the hard way.
Your Security Is Only as Strong as Your Weakest Vendor: This breach is a textbook example of supply chain risk. You must vet and continuously monitor the security practices of all your third-party vendors.
Transparency Is Key: Cloudflare’s rapid and detailed disclosure helped manage the narrative and maintain customer trust. When a breach happens, hiding it only makes it worse. Get ahead of it.
Principle of Least Privilege: Limit the data that third-party apps can access. If Salesloft and Drift had only been able to access the bare minimum of data required, the impact would have been even smaller.
Have an Incident Response Plan: Cloudflare was able to act quickly because they had a plan. Do you?
Is Cloudflare Safe after the Breach?
Yes. It's important to reiterate that Cloudflare's core infrastructure, network, and customer services were never compromised. The company's internal security remains robust. Following the incident, Cloudflare enhanced its vendor security review processes and reinforced its internal security protocols to further protect against supply chain attacks.
Mitigation & Prevention Strategies
You can't just hope a breach like this won't happen to you. You need to act. Here are some practical steps to protect your organization from similar supply chain attacks:
Implement Multi-Factor Authentication (MFA): Enforce MFA across all services, especially for third-party applications. This makes it much harder for attackers to use stolen credentials.
Conduct Vendor Security Assessments: Before you sign a contract, do your homework. Scrutinize the security practices of any vendor that will handle your data.
Apply the Principle of Least Privilege: Ensure users and third-party apps only have access to the data and systems they absolutely need to do their jobs. Nothing more.
Continuous Monitoring: Use security tools to monitor for suspicious activity across your network and in your cloud applications. An early warning can make all the difference.
Develop an Incident Response Plan: Know exactly who to call and what to do when a security incident occurs. Practice it.
Cloudflare Data Breach FAQs
A threat actor named GRUB1 stole OAuth credentials tied to Salesloft's Drift chatbot integration with Salesforce. Those credentials gave them authenticated access to Cloudflare's Salesforce tenant, where they conducted nine days of reconnaissance before bulk-exfiltrating support case data. Cloudflare's own network and infrastructure were never touched.
The exposed data was limited to information from sales and support interactions. This included names, email addresses, phone numbers, and the content of communications. No passwords, financial data, or sensitive customer configuration details were compromised.
The specific threat actor or group behind the attack on Cloudflare's vendors has not been publicly identified. The investigation focused on the third-party compromise, and the ultimate culprit remains unknown.
Businesses can reduce their risk by rigorously vetting the security of their software vendors, implementing multi-factor authentication everywhere, and applying the principle of least privilege to limit data access. Having a well-rehearsed incident response plan is also critical for a swift reaction.
