Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →The key lesson is that “the Salesforce breach” was not one stolen password or one platform-wide flaw. Recent incidents used several paths: voice phishing that induced users to authorize malicious connected apps, compromise of a trusted integration’s OAuth tokens, and overly broad public access on Salesforce Experience Cloud sites. Defending Salesforce data therefore requires control of identities, tokens, applications, APIs, guest users and help-desk procedures—not just passwords and multifactor authentication (MFA).
Why “the Salesforce breach” is misleading
Salesforce is a cloud platform used by many organizations, but the incidents reported in 2025 and 2026 were not one identical event. Responsibility and exposure differed by case:
- A customer employee could authorize a malicious application after a convincing phone call.
- A software vendor or integration could be compromised, allowing attackers to use OAuth tokens that customers had already trusted.
- A customer’s Experience Cloud configuration could expose records to unauthenticated or insufficiently authorized visitors.
- An attacker could defeat identity safeguards through stolen sessions, captured MFA codes or a help-desk-assisted account takeover.
Calling every case a Salesforce infrastructure breach obscures the control that would have prevented it. The more accurate term is Salesforce-related breaches.
The main attack paths
1. Voice phishing followed by a malicious connected app
- The attacker identifies a Salesforce user or administrator.
- Someone posing as IT support or another trusted person directs the victim to a login or application-authorization page.
- The victim authenticates and approves a modified Data Loader-style application.
- Salesforce issues OAuth authorization to the application.
- The attacker uses official APIs to enumerate objects and export data.
- Extortion or a demand may follow weeks or months later.
Google Threat Intelligence described this pattern and said attackers moved from modified Data Loader applications to custom applications and automated collection scripts. In one affected instance, the retrieved information was limited to basic business contact data and notes, not a universal set of Salesforce records. Google Threat Intelligence’s account does not establish a single victim count or a common impact for every customer.
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 →#1 Best Overall
MFA can still be present in this scenario. It protects the sign-in, but not a user who knowingly—or unknowingly—grants a new application permission after authentication.
2. Third-party OAuth and SaaS supply-chain compromise
Customers authorize applications to read or change Salesforce data. If the vendor or its environment is compromised, attackers may obtain tokens that work against customer organizations without stealing each customer’s password.
After the Salesloft Drift incident, Salesforce said the Drift connection could have enabled unauthorized access to a small number of customer organizations and told customers to review and revoke tokens at Setup → Connected Apps → OAuth Usage. Salesforce’s advisory is the authoritative instruction for that review. FINRA’s guidance on the Gainsight incident likewise emphasizes app-permission review and least privilege when integrations are reinstalled: FINRA’s cybersecurity advisory.
An approved integration is a bearer of privilege, not evidence that every action taken with its token is trustworthy.
Free tools Windows power users keep installed
One-click scans. No signup required.
3. Experience Cloud and Aura exposure
Experience Cloud sites can provide customer portals, forms and public content. They can also expose Salesforce records when guest-user permissions, sharing rules, Apex controllers, APIs or components are too broad.
Mandiant reported exposures involving identity documents, health information and payment-card data, and described GraphQL-related techniques that defeated assumptions about ordinary record retrieval. Its AuraInspector tool can support an authorized audit; it is not a Salesforce security certification or a substitute for a penetration test. Mandiant’s Aura and Experience Cloud research explains the technical findings.
In March 2026, Salesforce warned that a known threat group was exploiting misconfigured Experience Cloud guest profiles. FINRA summarized that warning and its relationship to earlier Drift and Gainsight activity at this security alert. A public website must not be treated as a public database.
4. Social engineering against identity controls
Mandiant described campaigns that captured single-sign-on credentials and MFA codes or persuaded victims to enroll attacker-controlled devices. The reporting says these compromises were not necessarily caused by a vulnerability in the SaaS provider’s infrastructure. Mandiant’s 2026 analysis and its containment guidance both stress high-assurance identity verification.
Rank #3
What attackers may obtain—and what has not been proved
There is no single verified victim or record total for all Salesforce-related incidents. Separate these categories when communicating an event:
| Category | Meaning |
|---|---|
| Confirmed unauthorized access | Evidence shows an account, token, site or application was used without authorization. |
| Potential access | An integration or guest profile could reach data, but retrieval has not been established. |
| Observed retrieval | Logs show records, files or reports were queried or exported. |
| Threat-actor claim | A number announced by an attacker; it remains unverified unless independently supported. |
| Customer-specific impact | The result of correlating Salesforce, identity-provider, application and vendor logs. |
Large claims about millions of records or organizations should therefore be attributed to the claimant, not presented as established fact.
Why ordinary defenses missed the activity
Valid credentials, tokens and APIs
An attacker may use a valid password, OAuth grant, session and official Salesforce API. Failed-login alerts, impossible-travel rules and MFA-prompt monitoring can remain quiet. Google Cloud’s Cloud Threat Horizons report identified identity issues in 83% of major cloud and SaaS incidents it analyzed from the second half of 2025, citing high-volume API exfiltration through compromised OAuth tokens.
Excessive scope and poor inventory
An app that can read or modify more objects than it needs creates a large blast radius. Organizations may track purchased software while missing trial apps, employee-authorized applications, legacy clients and stale grants.
Guest-user and help-desk weaknesses
Public sites are sometimes governed as web projects instead of data-access layers. Separately, a support agent who resets a password or enrolls a device without robust verification can undermine even phishing-resistant authentication.
Prioritized remediation checklist
Do today
- Inventory connected apps, external client apps, OAuth grants, integration users and Experience Cloud sites.
- Review Setup → Connected Apps → OAuth Usage; preserve relevant authorization details before revoking suspicious grants.
- Disable or freeze obviously compromised users, revoke identity-provider sessions and reset identity-provider passwords.
- Re-enroll MFA only after verifying the user’s identity, and pause unverified privileged-user resets or device enrollment.
- Search for bulk exports, unusual API volumes, new apps and access to high-value objects such as Contacts, Accounts, Cases, Files, Contracts and regulated custom objects.
- Contact a suspected integration vendor through a verified channel.
Do this week
- Assign a business owner and technical owner to every app; record vendor, purpose, scopes, objects, installation date and last use.
- Restrict authorization to approved users or profiles, remove dormant apps and use separate integration users for separate vendors.
- Review Setup → Connected Apps → Manage Connected Apps for permitted users, IP-relaxation settings, refresh-token behavior and scopes.
- Audit every Experience Cloud site, including guest profile permissions, sharing rules, Apex, Flow, Aura and Lightning components.
- Test each site from a genuinely unauthenticated browser session for record enumeration, files, reports, search and direct-object access.
- Confirm where Salesforce, identity-provider and vendor logs are retained and whether timestamps are normalized to UTC.
Do this quarter
- Apply phishing-resistant MFA—security keys or built-in authenticators—to administrators and other privileged users.
- Connect available API, login, report-export, URI and connected-app telemetry to a SIEM.
- Measure actual object and field use before narrowing OAuth scopes, then test integrations for silent failures.
- Review scripts, middleware, Data Loader use and embedded credentials ahead of Salesforce’s planned retirement of the OAuth 2.0 username-password flow for connected apps in Winter ’27.
- Run a tabletop exercise covering malicious consent, stolen tokens, guest exposure and help-desk takeover.
Repeat continuously
- Reapprove scope changes and vendor renewals.
- Revoke tokens when an integration is offboarded; cancelling a license is not enough.
- Monitor API volume, object access, user agents, source networks, time of day and reauthorization attempts.
- Retest guest access after every site, package, sharing-rule or component change.
How to review Experience Cloud safely
- List every site and identify whether guest access is enabled.
- Document objects and fields visible to the guest user.
- Review guest-profile permissions, sharing rules and external-sharing settings.
- Inspect unauthenticated Apex, Flow, Aura and Lightning functionality.
- Attempt record enumeration and direct-object access without logging in, using an authorized test plan.
- Check APIs, search, reports, files and custom endpoints for sensitive fields.
- Remove public access that is not essential, separate public content from private records and repeat the test after changes.
Detection that works with valid sessions
Prioritize behavior over failed logins. Alert on:
- Large or sudden API query volumes, bulk exports and unusually large report downloads.
- Access to objects an application does not normally use.
- New connected apps, unexpected OAuth grants or token use after a password or MFA change.
- Data Loader, custom-script or unusual-user-agent activity from unfamiliar networks or countries.
- After-hours access, guest requests to internal records and similar API patterns across multiple customer organizations.
IP restrictions are useful but incomplete: a compromised vendor may operate from trusted infrastructure, attackers may use proxies, and OAuth activity may not follow the organization’s ordinary login path. Use network controls as one layer.
Verify in advance which logs are licensed. Shield and some Event Monitoring capabilities are edition- and license-dependent. Setup → Login History provides authentication context but cannot by itself reveal token-based API abuse. Review Setup → Session Settings and use Setup → Event Monitoring / Shield Event Monitoring where available. Salesforce’s Security Guide is at this official PDF.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Incident-response playbook
First hour
- Declare an incident and appoint an incident commander.
- Disable clearly compromised users; revoke identity-provider sessions and suspicious Salesforce grants.
- Freeze unverified privileged-user password resets and MFA enrollment.
- Preserve app metadata, authorization records, tokens’ identifiers, IP addresses, user agents and timestamps before destructive changes.
- Search Salesforce, identity-provider, SIEM and vendor logs for exports and high-volume API activity.
First day
- Determine whether the entry point was a user, app, vendor, guest site or help desk.
- Identify affected users, apps, tokens, sites and objects; establish the earliest suspicious and latest confirmed events.
- Compare activity with normal integration baselines and check other services using the same identity provider or vendor.
- Assess legal, contractual, regulatory and customer-notification duties.
- Rotate secrets after identifying where they were used and whether replacement credentials are trusted.
Recovery
- Rebuild affected integrations from trusted packages or source and reauthorize only after vendor containment.
- Reduce scopes, require approval for new apps and apply phishing-resistant MFA to privileged users.
- Retest Experience Cloud externally, add API/export anomaly rules and run a tabletop exercise based on the actual path.
Immediate containment guidance from Mandiant is available at its SaaS-compromise response article. Salesforce’s identity-compromise guidance covers session revocation, password resets, MFA re-enrollment, bulk-export review and OAuth-token revocation: Salesforce’s response guidance.
Recommended Free Tools
Best Value
MFA and Salesforce’s upcoming controls
Salesforce says its 2026 security changes include MFA for all users, phishing-resistant MFA for administrators and privileged users, login IP restrictions and retirement of the OAuth 2.0 username-password flow for connected apps in Winter ’27. The exact timing and scope can vary by release group, edition, user category, authentication method and architecture; administrators should follow current release documentation at Salesforce’s security-enhancements notes.
Salesforce identifies security keys and built-in authenticators as phishing-resistant; Salesforce Authenticator and third-party TOTP applications are standard MFA methods. In SSO deployments, the identity provider communicates authentication context through SAML or OpenID Connect signals such as AMR and ACR. See Salesforce’s MFA guidance.
MFA reduces password-only takeover but does not stop malicious consent, stolen tokens, session theft or unauthorized device enrollment. Roll out changes in stages and test recovery; Salesforce has documented a sandbox enforcement issue that caused login problems for some users.
The practical decision framework
An organization is in a materially stronger position when it can answer these questions with evidence:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- What sensitive data is stored in Salesforce?
- Who and what can access it interactively, through APIs and through guest sessions?
- Which applications can export data, and are their scopes narrower than their maximum capabilities?
- Can every token be identified and revoked quickly?
- Are API, export, identity-provider and vendor events correlated in a SIEM?
- Can the organization prove whether a guest user or integration accessed specific records?
- Do support staff have high-assurance procedures for resets and MFA enrollment?
Use Salesforce-native controls first. Add Shield or a SaaS-security platform only when basic app inventory, MFA, guest governance and logging are operating effectively. A monitoring purchase cannot compensate for an unapproved connected app or a weak help-desk verification process. Salesforce’s security-advisory index is available at security.salesforce.com.
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.
