Skip to main content

2025-26 Salesforce breach class map

This page is the empirically-grounded counterpart to the AppExchange Top-20. The Top-20 lists what Salesforce's review team finds in submissions; this page lists what actually compromised real customer orgs in 2025-26.

Each entry names the breach, the technical attack vector, the Vulkro detector that catches the vector, and a precise "what Vulkro does not catch" note. The point of the second list is honesty: detectors close the technical preconditions of an attack class, but every class also has a vector that no static scanner can see.

1. Salesloft Drift OAuth token theft (2025, 700+ orgs)​

The breach. Refresh tokens issued to the Salesloft Drift Connected App, stored in Drift's vendor-side OAuth backing store, were stolen at the vendor and replayed against ~700 customer Salesforce orgs to exfiltrate CRM data. The customer orgs were not themselves compromised; the third-party vendor was.

The technical vector. A Connected App configured with the Full OAuth scope and a persistent refresh token (the standard Drift integration shape). Once the refresh token leaks from the vendor, the attacker holds the same access the vendor had: Full over the org's data, for as long as the token stays unrevoked.

Detector. detectors/connected-apps. The sf_metadata Connected App rule flags the dangerous co-occurrence: Full scope plus a configured refresh token / offline-access grant. The combination is the technical precondition that turns a vendor breach into an org-data breach.

What Vulkro does NOT catch. The vendor-side compromise itself. Vulkro cannot see what is happening inside Salesloft, Gainsight, or any other Connected-App vendor's infrastructure. What it does is name every Connected App in your org that, if its vendor were compromised tomorrow, would become a 700-org-class incident. The mitigation is revoking the scope (or the app), not patching a detector.

2. Gainsight OAuth abuse (2025, 200+ orgs)​

The breach. Architecturally identical to Drift; the Gainsight Connected App's refresh tokens were abused to read CRM data across ~200 customer orgs.

The technical vector. The same as Drift: a Full-scope Connected App with a persistent refresh token on the vendor side.

Detector. The same detector that catches Drift. From a defender's perspective the two incidents are one class with two CVE labels, and the precondition (broad scope + long-lived token grant) is the same thing Vulkro flags.

What Vulkro does NOT catch. Same as Drift: the vendor-side compromise itself is invisible. Vulkro's job is to name the orgs that would be exposed if any current Connected-App vendor goes the way of Drift or Gainsight. The remediation is the same: tighter scope, fewer refresh-token-bearing integrations, faster rotation.

3. Experience Cloud guest-user exposure (Loblaw 75M, ADT 10M+)​

The breach. The "AuraInspector" campaign of 2023-25 mass-scanned Experience Cloud sites for guest-user profiles whose object permissions granted read or View All Records on PII-bearing standard objects (Account, Contact, Lead, Case). Loblaw exposed 75M records; ADT exposed 10M+; numerous smaller sites were hit through the same automated probe.

The technical vector. A Guest User License profile (an Experience Cloud anonymous-visitor profile) with <objectPermissions> granting allowRead = true (or viewAllRecords = true) on Account, Contact, Lead, or Case. The combination of the unauthenticated entry point and the over-broad object permission is the exposure: any visitor reading the site can pull the full sObject through the Aura API.

Detector. detectors/profiles-permsets. The Guest User License profile elevation rule reads every *.profile file under the project (or every Profile pulled from the live org), identifies the Guest User License variant, and flags object-permission grants on the sensitive-object allowlist. Critical when viewAllRecords is true; High when allowRead is true on a sensitive object.

What Vulkro does NOT catch. The runtime probe (the AuraInspector network call) is a DAST concern: Vulkro does not send packets to your Experience Cloud site to confirm the exposure is reachable. What it does is name the guest profile that creates the exposure, on the source artifact (the profile XML) that any pull request modifies. The DAST follow-up (run AuraInspector against your own site as a red-team check) is the complementary step.

4. ForcedLeak (Agentforce, CVSS 9.4)​

The breach. Disclosed in 2025. An Agentforce agent, driven by an indirect prompt injection through a Web-to-Lead Description field, invoked a GenAiFunction Apex action whose target class was declared without sharing. The Apex action ran in the agent's runtime user context, which let the agent return rows the prompting visitor should never have seen.

The technical vector. A GenAiFunction (Agentforce Apex action) whose target class carries without sharing at the source-code declaration level. The agent runtime executes the action in the context of the user driving the conversation; without sharing elevates that to system-level data access. Indirect prompt injection on the grounding text turns the elevation into exfiltration.

Detector. detectors/agentforce. The ForcedLeak rule is a two-pass walk: pass one identifies every GenAiFunction metadata file and the Apex class it references; pass two opens the .cls file and confirms the source-level sharing keyword. Fires High when the target class is without sharing or carries no sharing declaration on a user-reachable class.

What Vulkro does NOT catch. The prompt-injection vector itself is in the grounding-text content, not in the Apex source. Vulkro cannot read the live Lead.Description that an attacker submitted. What it catches is the precondition: every Apex action that, if its grounding text were attacker-controlled, would leak data across users. The prompt-template grounding-source detector (mapping which fields a GenAiPromptTemplate actually grounds on) is planned but not yet shipped.

5. ShinyHunters / UNC6040 vishing (Google 2.55M, Qantas 5.7M, Allianz 1.4M)​

The breach. Over 2025, the ShinyHunters / UNC6040 threat group social-engineered IT help desks at Google, Qantas, Allianz, and a long tail of others. The endgame in each case was installing or elevating a Connected App with broad OAuth scope, then using that app's token to exfiltrate Salesforce records. Public claims ran to ~1B records across victims.

The technical vector. Two pieces. First, a dormant or over-privileged System Administrator account whose credentials the vishing call could surface (the social-engineering target). Second, an over-permissioned Connected App with broad OAuth scope, used as the pivot from a single human credential to bulk data egress.

Detector. Two complementary rules.

  • detectors/profiles-permsets: the dormant-admin rule (live-org only) flags System Administrator users whose LastLoginDate falls outside a configurable rolling window. These are the highest-value vishing targets.
  • detectors/security-settings
    • detectors/connected-apps: the Connected App scope rule flags broad OAuth scopes (Full, api, refresh_token) on every Connected App in the org. These are the pivots once a human credential is compromised.

What Vulkro does NOT catch. The vishing call itself. Social engineering is a human-factor attack: a static scanner cannot see the phone ringing at your help desk. What Vulkro does is name the assets that turn one successful vishing call into a multi-million-record incident: the dormant admin who is most attractive to call, and the broad-scope Connected App that scales the access from "one user's session" to "the whole org's data." Fixing both narrows the blast radius even when the vishing call eventually succeeds.

Why publish this map​

Salesforce security in 2025-26 is dominated by misconfiguration and vendor token theft, not new Apex injection bugs. The Top-20 is a useful baseline (it gates AppExchange submissions), but the Top-20 ranking dates from 2023 and predates the entire OAuth-token-theft and Agentforce attack surface.

The breach class map exists so a prospect can verify what Vulkro covers against what actually happened in 2025-26, instead of trusting marketing. Every entry above names:

  • the breach (with the customer scale, so you know the threat is real),
  • the technical vector (so you know what a defender is looking at),
  • the Vulkro detector that catches the vector (so you can audit the finding against the source code or metadata it claims to be reading),
  • the explicit gap (so you know what falls outside the tool by design, not by oversight).

When a new breach class lands in 2026-27, this page gets a new entry and a new row in the methodology coverage matrix. The detector arrives in the same commit that updates this list.