ShinyHunters extracted 1.7 million customer records from Hallmark Cards after exploiting a misconfigured Salesforce Experience Cloud portal, then published the data when Hallmark let a ransom deadline pass on April 2, 2026.
The intrusion began on March 9, 2026. ShinyHunters used a modified version of AuraInspector (an open-source Salesforce auditing tool originally developed by Mandiant) to mass-scan public-facing Experience Cloud sites for misconfigured guest user profiles. Hallmark's portal had guest user access enabled with object-level permissions broad enough to let unauthenticated callers reach the Salesforce Aura component APIs backed by live customer data. No credential was required. The guest user profile was already authorized to read PII.
Help Net Security reported on March 11 that this scanning campaign had already swept 300 to 400 Experience Cloud sites, two days after Hallmark's recorded intrusion date. On March 31, ShinyHunters posted a public ransom note with a final response deadline of April 2. Hallmark did not engage. The group published a 9.59-gigabyte archive on a dark web forum containing 1.7 million unique customer accounts: names, email addresses, phone numbers, mailing addresses, and the complete text of every customer support ticket stored in the Salesforce environment.
Two things are worth pulling out of the reporting.
What scanners would have missed
The attack required no CVE. Salesforce published no patch. The Aura framework behaved exactly as configured. Standard vulnerability scanners had no surface to work with.
SAST tools scan first-party source code. Hallmark's developers did not write the Salesforce platform. There is nothing to scan. DAST tools probe observed HTTP endpoints. A DAST tool pointed at the Hallmark Plus portal would follow the redirect to the Salesforce-hosted Experience Cloud domain and have no basis for testing whether the guest user context had read access to customer records inside the Aura API. DAST knows how to probe for things like injection and auth bypass in application code. It does not know how to ask: does this SaaS tenant's guest user profile have overly permissive object-level access?
SCA tools audit package dependency trees. Nothing in Hallmark's dependencies was the root cause.
Here are three compounding factors this breach shares with others in the same ShinyHunters campaign:
- Guest user profiles are a default-adjacent configuration. They get enabled during portal setup and rarely revisited.
- Object-level permissions are set to whatever makes the portal's intended read paths work. Nobody checks whether those read paths also expose customer PII fields to the unauthenticated guest context.
- The modified AuraInspector tool automated what would otherwise require a manual tester to probe each org by hand. That automation made it economically viable to sweep hundreds of portals in a single campaign.
No CVSS score appeared in any scanner report for this breach. The finding was not in any tool's detection scope.
What Sekura would have shown
Our recon and dynamic probing phases cover this surface directly.
Recon enumerates the external footprint of an org: domains, subdomains, and the SaaS portals the org exposes publicly. For a company running Salesforce Experience Cloud, that means identifying the *.force.com or custom-domain portal and flagging it for active probing.
Dynamic probing then exercises the identified surface. For an Experience Cloud site, that means issuing requests in the guest user context and querying the Aura component API to see what data comes back without authentication:
If the response to that probe includes customer PII fields, we produce a proof-of-exploit showing exactly what data is reachable with zero credentials. The finding states the endpoint, the guest profile permissions, the fields returned, and a sample of the data we extracted from the production environment.
I think the phrase "sample of data we extracted" is what changes how quickly this gets fixed. A CVSS score says the risk is theoretical. A working extract from your own Salesforce org says the risk already materialized.
The bigger pattern
The Salesforce Experience Cloud campaign is an example of how a CRM becomes an attack surface over time. Organizations configure these portals once, often under time pressure during a product launch. Guest user settings get left at whatever defaults made the portal functional. Nobody audits them in the next annual pentest cycle because the portal's domain is not in scope for the application pentest.
ShinyHunters ran this as an industrialized sweep. One tool, hundreds of orgs, consistent PII output at the end. The economics work because configuration drift is predictable.
The signal for 2026 is that SaaS configuration is now part of the attack surface in the same category as exposed APIs and unpatched services. An annual manual pentest might catch a specific misconfiguration once. It will not catch the same misconfiguration that returns during the next portal update.
If you want to see what proof-first continuous testing looks like on your own attack surface, see what scanners miss and we find.