As of August 23, 2025, Cloudflare was aware of suspicious activity within our Salesforce tenant and learned that we, as well as hundreds of other companies, had become the target of a threat actor responsible for exploiting a vulnerability in the Salesloft Drift integration. The attacker managed to gain access to our Salesforce instance by leveraging an OAuth token obtained from a compromised Salesloft account. This access was then used to exfiltrate data from our Salesforce environment, including customer contact information, case subject lines, and body of the cases. The attacker also gained access to the Salesforce case objects, which primarily consist of customer support tickets and their associated data within our Salesforce tenant. The data exfiltration was limited to the freeform text in Salesforce case objects, excluding attachments or files.
The threat actor’s specific actions during the incident included:
– Using the Trufflehog user agent to attempt to verify a customer token against the Cloudflare Customer Tenant API.
– Logging in to Cloudflare’s Salesforce tenant from the IP address 44.215.108.109.
– Sending a GET request to the /services/data/v58.0/sobjects/ endpoint to enumerate all objects in the Salesforce tenant.
– Sending a
Last week, Cloudflare was notified that we (and our customers) are affected by the Salesloft Drift breach. Because of this breach, someone outside Cloudflare got access to our Salesforce instance, which we use for customer support and internal customer case management, and some of the data it contains. Most of this information is customer contact information and basic support case data, but some customer support interactions may reveal information about a customer’s configuration and could contain sensitive information like access tokens. Given that Salesforce support case data contains the contents of support tickets with Cloudflare, any information that a customer may have shared with Cloudflare in our support system—including logs, tokens or passwords—should be considered compromised, and we strongly urge you to rotate any credentials that you may have shared with us through this channel.
As part of our response to this incident, we did our own search through the compromised data to look for tokens or passwords and found 104 Cloudflare API tokens. We have identified no suspicious activity associated with those tokens, but all of these have been rotated in an abundance of caution. All customers whose data was compromised in this breach have been informed directly by Cloudflare.
No Cloudflare services or infrastructure were compromised as a result of this breach.
We are responsible for the choice of tools we use in support of our business. This breach has let our customers down. For that, we sincerely apologize. The rest of this blog gives a detailed timeline and detailed information on how we investigated this breach.
Last week, Cloudflare became aware of suspicious activity within our Salesforce tenant and learned that we, as well as hundreds of other companies, had become the target of a threat actor that was able to successfully exfiltrate the text fields of support cases from our Salesforce instance. Our security team immediately began an investigation, cut off the threat actor’s access, and took a number of steps, detailed below, to secure our environment. We are writing this blog to detail what happened, how we responded, and to help our customers and others understand how to protect themselves from this incident.
Cloudflare uses Salesforce to keep track of who our customers are and how they use our services, and we use it as a support tool to interact with our customers. An important detail to understand as part of this incident is that the threat actor only accessed data in Salesforce “cases,” which may be created when Cloudflare sales and support team members need to comment to each other internally in order to support our customers; they are also created when customers interact with Cloudflare support. Salesforce had an integration with the Salesloft Drift chatbot, which Cloudflare used to give anyone who visited our website a way to contact us.
As Salesloft has announced, a threat actor breached their systems. As part of the breach, the threat actor was able to obtain OAuth credentials associated with the Salesloft Drift chat agent’s Salesforce integration to exfiltrate data from Salesloft customers’ Salesforce instances. Our investigation revealed that this was part of a sophisticated supply chain attack targeting business-to-business third-party integrations, affecting hundreds of organizations globally that were customers of Salesloft. Cloudforce One—Cloudflare’s threat intelligence & research team—has classified the advanced threat actor as GRUB1. Additional disclosures from Google’s Threat Intelligence Group aligned with the activity we observed in our environment.
Our investigation showed the threat actor compromised and exfiltrated data from our Salesforce tenant between August 12-17, 2025, following initial reconnaissance observed on August 9, 2025. A detailed analysis confirmed the exposure was limited to Salesforce case objects, which primarily consist of customer support tickets and their associated data within our Salesforce tenant. These case objects contain customer contact information related to the support case, case subject lines, and the body of the case correspondence—but not any attachments to the cases. Cloudflare does not request or require customers to share secrets, credentials, or API keys in support cases. However, in some troubleshooting scenarios, customers may paste keys, logs, or other sensitive information into the case text fields. Anything shared through this channel should now be considered compromised.
We believe this incident was not an isolated event but that the threat actor intended to harvest credentials and customer information for future attacks. Given that hundreds of organizations were affected through this Drift compromise, we suspect the threat actor will use this information to launch targeted attacks against customers across the affected organizations.
This post provides a timeline of the attack, details our response, and offers security recommendations to help other organizations mitigate similar threats.
Throughout this blog post, all dates and times are in UTC.
When Salesforce and Salesloft notified us on August 23, 2025, that the Drift integration had been abused across multiple organizations, including Cloudflare, we immediately launched a company-wide Security Incident Response. We activated cross-functional teams, pulling together experts from Security, IT, Product, Legal, Communications, and business leadership under a single, unified incident command structure.
We set up four clear priority workstreams with the goal to protect our customers and Cloudflare:
-
Immediate Threat Containment: We cut off all threat actor access by disabling the compromised Drift integration, conducted forensic analysis to understand the scope of the compromise, and eliminated the active threat from our environment.
-
Secure our third-party ecosystem: We immediately disconnected all third-party integrations from Salesforce. We issued new secrets for all services and implemented a new process to rotate them weekly.
-
Safeguard the integrity of our wider systems: We expanded credential rotation to all our third-party Internet services and accounts as a precautionary measure to prevent the attacker from using compromised data to access other Cloudflare systems.
-
Customer Impact Analysis: We analyzed our Salesforce case objects data to identify whether customers could be compromised and to ensure they received timely and accurate communication about potential exposure.
Our forensic investigation reconstructed the threat actor’s activities against Cloudflare, which occurred between August 9 and August 17, 2025. The following is a chronological summary of the threat actor’s actions, including initial reconnaissance prior to the initial compromise.
At 11:51, GRUB1 attempted to validate a Customer Cloudflare-issued API token to the Salesforce API. The actor used Trufflehog (a popular open-source secrets scanner) as their User-Agent and sent a verification request to client/v4/user/tokens/verify. The request failed with a 404 Not Found, confirming the token was invalid. The source of this API token is unclear—it could have been obtained from various sources including other Drift customers that GRUB1 may have compromised prior to Cloudflare.
At 22:14, GRUB1 gained access to Cloudflare’s Salesforce tenant by using a stolen credential used by the Salesloft integration. Using this credential, the GRUB1 logged in from the IP address 44[.]215[.]108[.]109 and made a GET request to the /services/data/v58.0/sobjects/ API endpoint. This action appeared to enumerate all objects in our Salesforce environment, giving the threat actor a high-level overview of the data stored there.
One day after the initial breach, the threat actor GRUB1 launched a subsequent attack from the same IP address, 44[.]215[.]108[.]109. Starting at 19:33, the threat actor stole customer data from the Salesforce case objects. They first re-ran an object enumeration to confirm the data structure, then immediately retrieved the case objects’ schema using the /sobjects/Case/describe/ endpoint. This was followed by a broad Salesforce query that enumerated fields from the Salesforce case object.
The threat actor GRUB1 dedicated hours to conduct comprehensive reconnaissance of Cloudflare’s Salesforce tenant from the IP address 44[.]215[.]108[.]109. It appears their objective was to build an understanding of our environment. For several hours, they executed a series of targeted queries:
-
00:17 – They measured the tenant’s scale by counting accounts, contacts, and users;
-
04:34 – Analyzed case workflows by querying CaseTeamMemberHistory; and
-
11:09 – Confirmed they were in a production environment by fingerprinting the Organization object.
The threat actor completed their reconnaissance with additional queries to understand how our customer support system operates—including how team members handle different types of cases, how cases are assigned and escalated, and how our support processes work—and then queried the /limits/ endpoint to learn the API’s operational thresholds. The queries run by GRUB1 provided them with insight into their level of access, the size of the case objects, and the precise API limits they needed to respect to avoid detection within our Salesforce environment.
Following the reconnaissance on August 14, 2025, we observed no traffic or successful logins from the threat actor GRUB1 for nearly 48 hours.
They returned on August 16, 2025. At 19:26, GRUB1 logged back into Cloudflare’s Salesforce tenant from the IP address 44[.]215[.]108[.]109 and, at 19:28, executed a single, final query: SELECT COUNT() FROM Case. This action served as a final “dry run” to verify the exact size of the dataset they were about to steal, marking the definitive end of the reconnaissance phase and setting the stage for the main attack.
GRUB1 initiated the data exfiltration phase by switching to new infrastructure, logging in at 11:11:23 from the IP address 208[.]68[.]36[.]90. After performing one final check on the size of the case object, they launched a Salesforce Bulk API 2.0 job at 11:11:56. In just over three minutes, they successfully exfiltrated a dataset containing the text of support cases—but not any attachments or files—in our instance of Salesforce. At 11:15:42, GRUB1 attempted to cover their tracks by deleting the API job. While this action concealed the primary evidence, our team was able to reconstruct the attack from residual logs.
We observed no further activity from this threat actor after August 17, 2025.
Salesloft revoked Drift-to-Salesforce connections across its customer base and published a notice on their website. At that point, Cloudflare had not yet been notified, and we had no indication that this vendor action might relate to our environment.
Our response to this incident began when Salesforce and Salesloft notified us of unusual Drift-related activity. We promptly implemented the vendors’ recommended containment steps and engaged them to gather intelligence.
By August 25, we had received additional intelligence about the incident and escalated our response beyond the initial vendor-recommended containment steps. We launched our own comprehensive investigation and remediation effort.
Our first priority was cutting off GRUB1’s access at the source. We disabled the Drift user account, revoked its client ID and secrets, and completely purged all Salesloft software and browser extensions from Cloudflare systems. This comprehensive removal mitigated the risk of the threat actor reusing compromised tokens, regaining access through stale sessions, or leveraging software extensions for persistence.
Separately, we expanded our security review to include all third-party services connected to our Salesforce environment, rotating credentials as a precautionary measure to prevent any potential lateral movement by the threat actor.
Since we use Salesforce as our primary tool for managing our customer support data, the risk was that customers had submitted secrets, passwords, or other sensitive data in their customer service requests. We needed to understand what sensitive material the attacker now had.
We immediately focused on whether any of that data could have been used to compromise our customers accounts, systems, or infrastructure. We examined the data obtained by the threat actor to see if it contained exposed credentials, since cases include freeform text fields where customers may submit Cloudflare API tokens, keys, or logs to our support team. Our teams developed custom scanning tools using regex, entropy, and pattern-matching techniques to detect likely Cloudflare secrets at scale.
Our investigation confirmed that the exposure was strictly limited to the freeform text in Salesforce case objects—not attachments or files. Cases are used by sales and support teams to communicate internally about customer support issues and to communicate directly with customers. As a result, these case objects contained text-only data consisting of:
-
The subject line of the Salesforce case
-
The body of the case (freeform text which may include any correspondence including keys, secrets, etc., if provided by the customer to Cloudflare)
-
Customer contact information (for example, company name, requestor email address and phone number, company domain name, and company country)
This conclusion was validated through extensive reviews of integrations, authentication activity, endpoint telemetry, and network logs.
While the primary Salesforce and Salesloft credentials had already been rotated, our next step was to terminate and securely re-establish our third-party integrations. We began methodically re-onboarding the terminated services, ensuring each was provisioned with new secrets and subject to stricter security controls.
Meanwhile, our teams continued to analyze the data that was exfiltrated. Based on the analysis, we triaged & validated potential exposures, operating under the principle that any data that could have been exposed, was examined. This enabled us to take direct action by rotating Cloudflare platform-issued tokens immediately upon discovery—a total of 104 API tokens were rotated. No suspicious activity has been identified related to those tokens.
Based on Cloudflare’s detailed analysis—all impacted customers were formally notified via email and banner notices in our Dashboard with information about the incident and recommended next steps.
This incident highlights the critical need for heightened vigilance in securing SaaS applications and other third-party integrations. The data compromised across hundreds of companies targeted in this attack could be used to launch additional attacks. We strongly urge all organizations to adopt the following security measures:
-
Disconnect Salesloft and its applications: Immediately disconnect all Salesloft connections from your Salesforce environment and uninstall any related software or browser extensions.
-
Rotate credentials: Reset the credentials for all third-party applications and integrations connected to your Salesforce instance. Rotate any credentials that may have been previously shared in a support case to Cloudflare. Based on the scope and intent of this attack, we also recommend rotating all third party credentials in your environment as well as any credentials that may have been included in a support case with any other vendor.
-
Implement frequent credential rotation: Establish a regular rotation schedule for all API keys and other secrets used in your integrations to reduce the window of exposure.
-
Review support case data: Review all customer support case data with your third-party providers to identify what sensitive information may have been exposed. Look for cases containing credentials, API keys, configuration details, or other sensitive data that customers may have shared. For Cloudflare customers specifically: you can access your support case history through the Cloudflare dashboard under Support > Technical Support > My Activities, where you can filter cases or use the “Download Cases” feature to conduct a comprehensive review.
-
Conduct forensics: Review access logs and permissions to all third-party integrations and review public materials associated with the Drift incident and conduct a security review of your environment as appropriate.
-
Enforce least privilege: Audit all third-party applications to ensure they operate with the minimum level of access (least privilege) required for their function and ensure that admin accounts are not used for vendors. Additionally, enforce strict controls like IP address restrictions and session binding on all third-party and business-to-business (B2B) connections.
-
Enhance monitoring and controls: Deploy enhanced monitoring to detect anomalies such as large data exports or logins from unfamiliar locations. While capturing third party to third party logs can be difficult, it is imperative that these logs are part of your security operations teams.
Below are the Indications of Compromise (IOCs) that we saw from GRUB1. We are publishing them so that other organizations, and especially those that may have been impacted by the Salesloft breach, can search their logs to confirm the same threat actor did not access their systems or third parties.
|
Indicator |
Type |
Description |
|---|---|---|
|
208[.]68[.]36[.]90 |
IPV4 |
DigitalOcean based infrastructure |
|
44[.]215[.]108[.]109 |
IPV4 |
AWS based infrastructure |
|
TruffleHog |
User Agent |
Open source Secret Scanning tool |
|
Salesforce-Multi-Org-Fetcher/1.0 |
User Agent |
User-Agent string linked to malicious tooling |
|
Salesforce-CLI/1.0 |
User Agent |
Salesforce Command Line Interface (CLI), |
|
python-requests/2.32.4 |
User Agent |
User agent may indicate custom scripting |
|
Python/3.11 aiohttp/3.12.15 |
User Agent |
User agent which may allow many API calls in parallel |
We are responsible for the tools that we select and when those tools are compromised by sophisticated threat actors, we own the consequences. Our team responded to the notice, and our investigation confirmed that the impact was strictly limited to data in Salesforce case objects, with no compromise of other Cloudflare systems or infrastructure.
That said, we consider the compromise of any data to be unacceptable. Our customers trust Cloudflare with their data, their infrastructure, and their security. In turn, we sometimes place our trust in third-party tools which need to be monitored and carefully scoped in what they can access. We are responsible for this. We let our customers down. For this, we sincerely apologize.
As third-party tools increasingly integrate with internal corporate data across the industry, we need to approach each new tool with careful scrutiny. This incident affected hundreds of organizations through a single integration point, highlighting the interconnected risks in today’s technology landscape. We are committed to developing new capabilities to help us and our customers defend against such attacks in the future—stay tuned for announcements during Cloudflare’s Birthday Week later this month.
We are also committed to sharing threat intelligence and research with the broader security community. In the weeks ahead, our Cloudforce One team will publish an in-depth blog analyzing GRUB1’s tradecraft to support the broader community in defending against similar campaigns.
The following table provides a granular, chronological view of GRUB1’s specific actions during the incident.
|
Date/Time (UTC) |
Event Description |
|---|---|
|
2025-08-09 11:51:13 |
GRUB1 observed leveraging Trufflehog and attempting to verify a token against a Cloudflare Customer Tenant: |
|
2025-08-12 22:14:08 |
GRUB1 logged into Cloudflare’s Salesforce tenant from |
|
2025-08-12 22:14:09 |
GRUB1 sent a |
|
2025-08-13 19:33:02 |
GRUB1 logged into Cloudflare’s Salesforce tenant from |
|
2025-08-13 19:33:03 |
GRUB1 sent a |
|
2025-08-13 19:33:07 and 19:33:09 |
GRUB1 sent a |
|
2025-08-13 19:33:11 |
GRUB1 first observed executing Salesforce query: A broad query against the case object by |
|
2025-08-14 0:17:40 |
GRUB1 lists available objects and counts |
|
2025-08-14 00:17:47 |
GRUB1 queried Account table in Cloudflare’s Salesforce tenant: |
|
2025-08-14 00:17:51 |
GRUB1 queried Contact table in Cloudflare’s Salesforce tenant: |
|
2025-08-14 00:18:00 |
GRUB1 queried User table in Cloudflare’s Salesforce tenant: |
|
2025-08-14 04:34:39 |
GRUB1 queried “CaseTeamMemberHistory” in Cloudflare’s Salesforce tenant: |
|
2025-08-14 11:09:14 |
GRUB1 queried Organization table in Cloudflare’s Salesforce tenant: |
|
2025-08-14 11:09:21 |
GRUB1 queried User table in Cloudflare’s Salesforce tenant: |
|
2025-08-14 11:09:22 |
GRUB1 sent a |
|
2025-08-16 19:26:37 |
GRUB1 logged into Cloudflare’s Salesforce tenant from |
|
2025-08-16 19:28:08 |
GRUB1 queried Cases table in Cloudflare’s Salesforce tenant: |
|
2025-08-17 11:11:23 |
GRUB1 logged into Cloudflare’s Salesforce tenant from |
|
2025-08-17 11:11:55 |
GRUB1 queried Case table in Cloudflare’s Salesforce tenant: |
|
2025-08-17 11:11:56 to 11:15:18 |
GRUB1 leveraged Salesforce BulkAPI 2.0 from |
|
2025-08-17 11:15:42 |
GRUB1 leveraged Salesforce Bulk API 2.0 from |
