Skip to main content

Salesforce security in 2026 so far

· 10 min read
Vulkro
Vulkro
Security research

Salesforce data theft did not stop when 2025 ended. In the first half of 2026 there was a mass scan of public Experience Cloud sites in March, a run of extortion claims through the spring, and in June another third-party integration whose OAuth tokens were used against customer orgs.

The pattern from last year held. In each case where Salesforce made a statement, it said its platform had not been breached. What attackers used was configuration that customers own: what an anonymous site visitor may read, what an employee account can reach, and what an integration's token is allowed to do.

This post sticks to what has been confirmed by Salesforce, by the affected companies or by a regulator, and says so when a claim comes only from the attackers. Then it lists what to check in your own org.

March: mass scanning of public sites​

On 7 March 2026 Salesforce warned customers about increased activity against public Experience Cloud sites, and updated the post on 11 March. A threat actor was mass-scanning sites through the /s/sfsites/aura endpoint with a modified version of Aura Inspector, a public auditing tool released in January, changed so that it extracted data rather than only reporting what was exposed. Salesforce attributed the exposure to customer-configured guest user settings and said the issue "is not due to any vulnerability inherent to our platform."

The attacker's side of the story came through the press. ShinyHunters told BleepingComputer it had been taking data from misconfigured sites since September 2025, claimed between 300 and 400 affected organisations, and claimed ways around the 2,000-record limit on standard Aura queries. BleepingComputer could not verify the claim that its method also worked on properly configured sites, and reported that Salesforce had addressed a bypass before publishing its advisory. Treat all of those numbers as claims.

The regulator's view is more useful for deciding what to do. FINRA issued a cybersecurity alert to member firms that attributes the activity to ShinyHunters, describes the data being used for phishing, voice phishing and extortion against staff and clients, and gives advice that applies well beyond financial services: "Treat any data already exposed through misconfigured guest access as potentially compromised." Closing the gap today does not undo what was readable last month.

We walked the mechanism hop by hop, from the site to the guest profile to sharing to Apex, in the anatomy of a guest user data leak. The short version: whatever the guest user can read, anyone can read, and a without sharing class the guest can call reads more than the guest profile suggests.

March: an employee's account​

On 24 March, BleepingComputer reported that Infinite Campus had notified customers of a breach in which an attacker accessed an employee's Salesforce account, and that the information exposed was mostly publicly available. The company's notice did not say how the account was accessed. ShinyHunters had claimed the attack.

It is a reminder that the 2025 route through people, covered in how Salesforce orgs get breached, did not go away. One account's access to the org is one account's access to the org, however it was obtained.

June: Klue and another integration token​

In June the integration path repeated. According to The Hacker News, Salesforce posted a status alert saying it had disabled the connection between the Klue Battlecards app and Salesforce after a security incident at Klue on 11 June, and that the issue did not arise from a vulnerability in the Salesforce platform.

Klue's own statement of 18 June says it found unauthorised activity in part of its integration infrastructure on 12 June. The attacker came in through an older credential tied to an integration service, used it to obtain the OAuth tokens customers had granted Klue to connect to platforms including Salesforce, and used those tokens to access data in a number of customer environments. Klue revoked the affected credentials and tokens and disconnected the affected integrations.

At least one customer filed with the SEC. 8x8's Form 8-K says it learned on 13 June that a threat actor had exploited the Klue integration connected to its Salesforce CRM. The data taken included contract and opportunity information, sales team notes and customer contact details. 8x8 says the incident was isolated to information in Salesforce that was reachable through the Klue integration, and that with Salesforce's support the integration was disabled. The Hacker News reported that an extortion group called Icarus claimed the theft.

That last sentence of the filing is the whole lesson. The damage was bounded by exactly what the integration's token could reach, and nothing else. We covered which connected app settings decide that reach (scopes, IP relaxation, refresh token policy and the integration user) in connected apps and OAuth tokens.

What was claimed, and what was confirmed​

Through the spring, extortion groups named a long list of companies whose Salesforce records they said they held. Some of those companies have confirmed a breach. Fewer have said how it happened. ADT, for example, confirmed to The Register that it detected unauthorised access on 20 April, while the link to Salesforce came only from the group claiming it.

We have not listed those claims here as Salesforce incidents. A record count posted by an extortion group is a sales pitch, not evidence, and repeating it as fact helps the extortion.

What the year shows​

Three doors, the same as last year:

Door2026 exampleWhat decided the damage
The anonymous visitorMarch mass scanning of public sitesGuest profile, guest sharing rules, guest-callable Apex, public API access
An employee accountInfinite CampusThat user's permissions and what they could export
An integration tokenKlueThe connected app's scopes, IP policy and refresh policy, and the integration user's reach

None of them needed a platform vulnerability, and none of them is visible from a single setting.

What to check in your org now​

Public sites. For each active site with public access, work through Salesforce's March list: start the guest profile from zero access, turn off API Enabled and guest access to public APIs, set external org-wide defaults to Private, turn off Portal User Visibility and Site User Visibility, and turn off self-registration where the site does not need it. Then read every guest sharing rule as "anyone can read all of these records", and check every Apex class the guest can call for with sharing and user-mode queries.

Assume past exposure. If a site was over-permissive, follow FINRA's advice and treat what it exposed as already taken. Warn the people whose data it was, and watch for phishing that uses it.

Integrations. Inventory every connected app with a live token. For each one, know its scopes, whether IP restrictions apply, how long its refresh tokens live, and what its integration user can read. Ask each vendor how it stores your tokens and how it would tell you about an incident. Make sure you can revoke one app's tokens quickly.

People. Keep the permissions to authorise uninstalled connected apps and to use any API client with a handful of administrators, and grant API access through a permission set rather than a profile.

Watching. Review login history, API usage and unusual guest traffic, and make sure the org has a designated security contact, as Salesforce's March guidance recommends. Search text fields for secrets, because the 2025 attackers did.

How Vulkro for Salesforce shows it​

In your project, on your machine. vulkro-sf entrypoints --guest-only ./force-app lists every Apex entry point a guest profile or permission set grants, with the class's sharing keyword and resolved API version. vulkro-sf exposure builds one report per site: what the guest can read, which Apex it can call and in which sharing mode, the settings that widen its reach, the top proven paths, and a verdict (exposed, at risk, limited, no guest access, or not determined). With --target-org it adds live site status and record counts, read with SELECT COUNT(), never the records themselves. vulkro-sf scan checks connected app metadata in the repository for broad scopes, long-lived refresh tokens and IP relaxation.

In the live org, read-only, through your own sf CLI login. vulkro-sf org guest-live checks the guest posture of the sites that are actually serving, and reports a site whose guest user it cannot resolve as unknown, never as clean. vulkro-sf org oauth-risk rates every connected app, External Client App and app seen through its tokens, lists who can authorise new apps, flags integration users with org-wide data access, and produces a revoke list as recommendations only. vulkro-sf org threat-detection reads the event logs every org already has and flags signals such as an administrator or integration user signing in from a new country, an API client the org has never seen, API use far above a user's baseline, bulk exports and a connected app policy being relaxed. A detection is a reason to investigate, never proof of a breach.

Across a team's orgs. Vulkro Cloud connects to each org through an External Client App you own, reads configuration, metadata and access, never the contents of your business records, and runs the same checks on a schedule. Changes between scans are the useful part here: a widened guest profile or a new integration shows up at the next scan, not at the next incident.

Where to see it​

The guest-live and connected apps pages cover the live checks, live-org setup explains the read-only connection, and connecting an org to Vulkro Cloud lists exactly which permissions are used and why. To check your own org, start here.

Sources​