ShinyHunters extracted records for 185,000 franchise applicants from 7-Eleven's Salesforce portal by querying it without credentials.
7-Eleven notified state regulators in Maine, Vermont, and Massachusetts on May 15 and 16, 2026 that attackers had accessed its franchise application system on April 8. The stolen data included names, physical addresses, Social Security numbers, driver's licenses, dates of birth, and phone numbers. ShinyHunters demanded a ransom. When 7-Eleven declined, the group published a 9.4-gigabyte archive of the stolen files.
The vector was not a code flaw. BleepingComputer reported that ShinyHunters used a modified version of AuraInspector, an open-source tool originally built by Mandiant for auditing Salesforce Aura components, to scan publicly accessible Experience Cloud deployments for misconfigured guest user profiles. When a guest user profile carries excessive object-level permissions, any HTTP client can query the Aura endpoint and receive CRM records. No credentials, no CVE, no exploit code.
By March 2026, ShinyHunters told reporters they had breached between 300 and 400 organizations using this technique, with roughly 100 described as high-profile. 7-Eleven is the most publicly recognized victim confirmed to date. Two things are worth pulling out of the reporting.
What scanners would have missed
The franchise application portal lives on a *.force.com subdomain hosted on Salesforce's infrastructure. That is a separate domain from 7-eleven.com. Pentest scope is typically defined by what the customer registers: the main domain, an API subdomain, a staging environment. A Salesforce Experience Cloud portal running on a *.force.com hostname rarely appears on that list.
But suppose it did. Here is what traditional tooling would return:
- SAST analyzes source code. Salesforce org configuration is not source code. A guest user profile permission setting lives in Salesforce metadata, not in a repository.
- DAST probes for known vulnerability patterns: reflected XSS, SQL injection, SSRF, CVE signatures. It has no model for "this endpoint returns CRM records to anonymous callers." The tool reports nothing.
- SCA scans third-party dependencies. There are no dependencies involved here.
- CVSS does not apply. There is no CVE. Any severity dashboard that ranks findings by CVSS score returns a blank row for this failure mode.
The issue is a coverage gap, not a missed finding. Traditional tooling is built to test code artifacts and network-accessible services against known signatures. A Salesforce permission profile is neither. It lives outside the scan perimeter and accumulates drift without triggering any CI/CD hook or scheduled scan.
What Sekura would have shown
Phase 2 (Recon) and Phase 3 (Dynamic Probing) would have surfaced this finding together.
The Recon agent starts from the registered domain and enumerates external assets. Certificate transparency logs expose subdomains that organizations operate but do not always document internally. A *.force.com entry associated with 7-Eleven appears in those logs. The agent classifies it as a Salesforce Experience Cloud deployment and passes it to the probing queue with a flag for guest user permission testing.
The Dynamic Probing agent then sends a sequence of unauthenticated requests to the Aura API endpoint on that subdomain.
The finding would state: the guest user profile on the franchise application portal returns Contact records including personal identifiers. No authentication is required. The proof is the response body from the query above.
We would not say the portal is probably misconfigured. We would show it is. That is the distinction proof-first makes.
The bigger pattern
This is a SaaS misconfiguration breach, not a software vulnerability. The pattern is predictable: an administrator set a permission profile when the franchise portal went live, possibly for a legitimate testing or support workflow. Over time the scope of that permission was never reviewed. The configuration drifted from intention.
I think this class of failure is underrepresented in most security programs. Organizations invest in SAST, DAST, and SCA for their own code. SaaS configuration surfaces get almost no continuous coverage. There are no tools watching Salesforce org settings the way a SAST scanner watches a repository on every commit.
ShinyHunters turned this gap into a systematic campaign. They ran AuraInspector across hundreds of organizations and found that many carried the same unchecked configuration. The technique requires no novel exploit. It requires only that a guest user profile is misconfigured and nobody has checked.
That pattern will not resolve on its own.
If you want to see what we would surface on your external attack surface, book a POC.