Recent Salesforce data-theft campaigns usually do not mean attackers broke Salesforce’s core infrastructure. More often, criminals steal an identity, abuse an authorized application or integration, exploit an exposed public site, or use legitimate Salesforce APIs to copy data. For organizations storing customer records, employee information, support cases, files, or credentials in Salesforce, the practical question is which identity, app, session, site, object, or API path allowed access.
As of August 18, 2026, five attack paths account for most of the recurring risk: social engineering, OAuth-connected applications, compromised vendors, Experience Cloud guest access, and Salesforce’s own bulk-data tools.
1. Attackers often start with people, not Salesforce software
Threat actors have used phone calls, fake IT-support conversations, phishing pages, MFA manipulation, and help-desk deception. A victim may be persuaded to enter single sign-on credentials on a counterfeit page, read an MFA code aloud, approve a push request, register an attacker-controlled device, authorize an application, or install a modified utility.
Google Threat Intelligence reported January 2026 activity in which vishing groups captured SSO credentials and MFA codes, sometimes enrolling an unauthorized device before moving into SaaS applications such as Salesforce. Google Threat Intelligence describes the campaign.
Recommended Free Tools
#1 Best Overall
Why MFA is necessary but not sufficient
MFA still materially reduces ordinary password-only compromise, but it cannot reliably stop a real-time phishing proxy, a stolen browser session, a socially engineered approval, a fraudulent help-desk reset, or an OAuth token that was issued after authentication. FIDO2 security keys and passkeys provide stronger resistance to this type of social engineering than SMS or push approval. Salesforce’s MFA guidance is available at Salesforce MFA, and Google/Mandiant’s defensive guidance is at Proactive Defense Against ShinyHunters-Branded Data Theft.
High-risk support events
- MFA-method changes and new device enrollments
- Password resets and requests to disable security controls
- New OAuth authorizations or connected-app policy changes
- Urgent requests claiming to come from Salesforce, internal IT, or a vendor
Require independent verification for these events, preferably through a known contact method rather than the phone number or link supplied in the request.
2. OAuth can make a password reset incomplete
A Salesforce connected app can obtain OAuth access and refresh tokens that let an external program use Salesforce APIs. If a user authorizes a malicious app, or a trusted vendor’s token is stolen, an attacker may query data through an official connection without presenting the victim’s password again.
That creates four important distinctions:
- A password reset may not invalidate every existing OAuth token or external session.
- An MFA reset may not stop an already-authorized application.
- Login monitoring may show no failed login because the attacker is using a valid token.
- The customer organization can be compromised even when Salesforce’s platform itself was not.
The FBI described UNC6040 activity in which victims were persuaded to authorize a malicious connected app resembling Salesforce Data Loader. It also described UNC6395 activity involving compromised OAuth tokens associated with a third-party integration. These are attribution labels used by the FBI, not proof of a single publicly identified criminal identity. See the FBI advisory.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →What administrators should inventory
- Connected-app name, publisher, OAuth scopes, and approval status
- Users who authorized the app, token creation and refresh activity, and last-used date
- Objects, fields, reports, files, and API functions accessed
- Whether the integration uses a dedicated least-privileged identity
- Vendor security contacts, revocation procedures, and notification obligations
Controls that reduce persistence
- Restrict connected apps to approved users or permission sets.
- Require high-assurance sessions for sensitive apps where supported; see Salesforce’s connected-app high-assurance control.
- Remove unused apps and stale authorizations.
- Revoke access and refresh tokens during suspected compromise.
- Use separate, least-privileged integration users instead of powerful administrator accounts.
3. A trusted vendor can become the route into Salesforce
“Salesforce breach” can describe three different situations: a compromise of Salesforce infrastructure, theft of a customer user identity, or compromise of a vendor that already has a legitimate Salesforce connection. The third case is a supply-chain problem: the attacker may never need to phish your employee.
In a 2025 Gainsight advisory, Salesforce said unusual activity involving Gainsight-published applications may have enabled unauthorized access to some customers’ data through those applications’ connections. Salesforce disabled the connection on November 20, 2025 and said integrations were re-enabled on December 10, 2025 after remediation validated by Mandiant and CrowdStrike. Salesforce stated that the incident was not caused by a Salesforce-platform vulnerability. The advisory is at Salesforce’s Gainsight security notice.
Rank #3
Questions for vendor reviews
- Where are Salesforce refresh tokens stored, and are they encrypted and access-controlled?
- Can vendor employees access tokens?
- Are scopes limited to required objects and operations?
- Are integration identities separated by customer?
- How quickly can the vendor revoke all customer tokens?
- Does it monitor unusual API volume and object access?
- What is the incident-notification timeline, and can customers disconnect independently?
During a vendor incident, investigate OAuth authorizations, refresh-token activity, API calls, bulk exports, report downloads, Setup Audit Trail, Event Monitoring, and the vendor’s own logs—not just Salesforce login history. Also search Salesforce records, notes, cases, files, and attachments for secrets that may need rotation.
4. Experience Cloud can expose data without an employee account
Salesforce Experience Cloud sites can expose records through public or guest-user access when object permissions, sharing rules, Apex controllers, Aura components, site settings, or published content are too permissive. In March 2026, Salesforce warned about increased activity targeting overly permissive guest-user configurations. Exposure depends on the actual implementation; not every Experience Cloud site is vulnerable. Read Salesforce’s guest-user guidance.
Mandiant has reported finding Aura and Experience Cloud access-control misconfigurations capable of exposing identity documents, payment-card data, and health information. Its open-source AuraInspector auditing tool is intended to help identify such exposures; its existence does not establish that every Aura endpoint is exposed.
Review every site
- Classify the site as public, authenticated, or restricted.
- Review the guest-user profile and permission sets; remove unnecessary object and field access.
- Test visibility from an unauthenticated browser, including search, reports, files, and attachments.
- Review Apex and Aura-enabled methods for indirect record access.
- Audit sharing rules, external-user access, domains, and unused sites.
- Monitor Aura requests and unusual record retrieval.
This path differs from OAuth abuse: a public site may expose data without stolen credentials, even when employee MFA is configured perfectly.
5. Legitimate APIs can perform large-scale theft
Attackers can use Salesforce APIs, Data Loader-like applications, report exports, and bulk functions to query records, download files, read cases and notes, and search for credentials or cloud-service secrets. The FBI said UNC6040 abused a modified application resembling Data Loader and UNC6395 used compromised OAuth tokens to add or use Data Loader for exfiltration. That does not mean the official Salesforce Data Loader product itself was malicious.
Basic login history may miss this activity. Mandiant recommends telemetry covering logins, configuration changes, connected-app and API activity, and exports. Relevant records can require Event Monitoring, Real-Time Event Monitoring, Salesforce Shield, or an Event Monitoring add-on, depending on edition, licenses, retention, and enabled features. Consult the Salesforce Security Guide and Mandiant’s logging guidance.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
Signals to correlate
- New or rarely used connected apps
- OAuth refreshes from unfamiliar countries, networks, or devices
- Sudden Data Loader or bulk-API use
- Large record-query volumes, report downloads, or file retrieval
- Access to objects the user or app never previously used
- After-hours API activity following a new device or session
- Queries for terms such as “password,” “AWS,” “secret,” “VPN,” or “token”
- Configuration changes shortly before export activity
One unusual query is not proof of theft. A pattern linking identity changes, app authorization, unusual API volume, and sensitive-object access is far more significant.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to do in the first hour of suspected compromise
- Preserve evidence. Record the suspicious app’s name, client ID, scopes, authorized users, timestamps, and activity before deleting anything. Preserve Salesforce, identity-provider, endpoint, email, help-desk, and vendor logs.
- Revoke access. Revoke suspicious connected-app tokens, refresh tokens, and active sessions where appropriate. Disconnect compromised integrations.
- Contain identities. Freeze or deactivate affected users, reset credentials at the identity provider and Salesforce as appropriate, remove attacker-added MFA devices, and review password resets, MFA changes, and device enrollments.
- Protect other systems. Rotate secrets found in Salesforce records, files, cases, notes, or attachments, including AWS, Azure, Google Cloud, Snowflake, Slack, Git, and VPN credentials.
- Stop ongoing exposure. Restrict unapproved connected apps, apply safe IP or session controls, and temporarily disable public Experience Cloud access if exposure is suspected.
Salesforce specifically recommends revoking OAuth tokens and connected-app sessions after suspected unauthorized access and discusses session controls such as locking sessions to their originating IP address in its identity-compromise guidance.
What follows containment
- Determine which objects, fields, reports, files, and records were accessed, and establish the earliest suspicious activity.
- Compare API behavior with normal integration baselines and distinguish viewing from downloading or querying.
- Engage legal, privacy, security, cyber-insurance, and affected vendors.
- Assess notification duties based on jurisdiction, data type, contracts, and whether information was accessed or acquired.
- Look for follow-on phishing or extortion using stolen customer information.
- Reissue credentials and tokens across connected systems before restoring normal access.
- Complete a permissions, connected-app, public-site, and logging review.
Choosing controls without creating new blind spots
| Control | Benefit | Trade-off or limitation |
|---|---|---|
| FIDO2 keys or passkeys | Strongest resistance to phishing and approval manipulation. | Requires enrollment, recovery planning, and compatible identity systems. |
| IP or session locking | Can limit stolen-session usefulness. | May disrupt mobile users, VPN changes, remote work, or integrations; it does not stop an authorized API app. |
| Connected-app restrictions | Reduces shadow integrations and unauthorized grants. | Can break legitimate tools unless applications and owners are inventoried first. |
| Event Monitoring or Shield | Improves visibility into API, export, session, and configuration activity. | Availability and retention vary by edition and license; collection still requires detections and response staff. |
| Experience Cloud lockdown | Removes anonymous exposure paths. | Can affect public portals, partner access, and self-service workflows; custom Aura or Apex may still expose records indirectly. |
Bottom line for Salesforce administrators and executives
Salesforce security is shared responsibility. The central investigation question is not simply whether Salesforce was breached. Determine which identity, application, vendor connection, session, public site, permission, object, or API allowed data to leave—and revoke that path while preserving evidence.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute
