ShinyHunters accessed Amtrak's customer relationship data in April 2026 not through a vulnerability in Amtrak's systems, but through credentials obtained by social engineering Salesforce support personnel.
The attack surfaced publicly in mid-April when ShinyHunters posted on criminal forums claiming a large Amtrak dataset. The group set a ransom deadline. On April 17, Have I Been Pwned confirmed the dataset's authenticity after adding 2.1 million records to its breach notification service. The confirmed dataset included customer names, email addresses, physical addresses, and support ticket records. ShinyHunters also claimed a larger dataset of up to 9.4 million records, which Amtrak has not confirmed.
As CyberNews and SC Media reported, the group did not attack Amtrak's own infrastructure directly. ShinyHunters used social engineering against Salesforce support personnel to obtain platform credentials. With valid credentials in hand, they accessed the CRM tenants of multiple Salesforce customers through the same pivot. Amtrak was one of several organisations affected. The attack required no exploit code. The entire path ran through a trusted vendor's authentication layer.
Two things are worth pulling out of the reporting.
What scanners would have missed
No CVE exists for this breach. A static analysis scan of Amtrak's codebase would produce no finding relevant to it. A dynamic probe of Amtrak's public-facing endpoints would observe only authenticated sessions behaving normally. A software composition audit of Amtrak's dependencies would find no vulnerable package. The attack surface was not in Amtrak's software.
The Salesforce integration operates with valid credentials. From the perspective of any tool scanning Amtrak's systems, those sessions look exactly like authorised access. There is no malformed request, no injection payload, no unexpected status code. The attacker was already inside a trusted channel before they touched any record.
CVSS severity ratings describe the risk profile of specific software flaws. They say nothing about whether a SaaS vendor's personnel can be manipulated into handing over platform credentials. These are different threat surfaces. Standard scanners are built to assess the first. They have no model for the second.
Here are four things no scanner in Amtrak's stack could have evaluated:
- Whether Salesforce support staff were targeted and successfully social-engineered.
- Whether credentials held by vendor personnel gave access to Amtrak customer data.
- Whether an attacker's session was already authenticated before any probing began.
- What data is reachable through a CRM tenant your engineering team did not build.
What Sekura would have shown
Sekura's recon phase maps external attack surfaces, including live third-party integrations and the data those integrations expose. When the recon agent identifies an active Salesforce CRM integration with access to customer PII fields, it produces a finding documenting the trust boundary: what data is accessible through the integration, and where the credential control point sits.
That finding would not say Salesforce is breached. It would say: this integration exposes customer records to any party holding valid CRM credentials for this tenant, and that credential is not under your direct control.
From there, Sekura's exploit-chain analysis phase would synthesise the full path from a social engineering event at the vendor layer to a complete data extraction. The chain is deterministic, not a probability estimate.
I think the more useful output here is not a list of missing patches. It is a documented proof that your customer data is reachable through a path your own team does not own or monitor.
The bigger pattern
This breach belongs to a category that security programs underweight: SaaS trust chain compromise. The attacker never touches the victim's code or infrastructure. They compromise a vendor who holds a credential granting access to the victim's data. The victim's internal controls, patching cadence, and scanner results are all beside the point.
In 2026, most organisations using a cloud CRM, a SaaS support platform, or a hosted ERP have some portion of customer data reachable through credentials managed by a third party. This is not unusual. It is the baseline SaaS architecture.
ShinyHunters ran the same playbook against multiple Salesforce customers in the same campaign. Amtrak was one entry in a list, not a unique target. The shared attack surface was the vendor's support portal.
The credential your vendor holds is part of your attack surface. Whether your security tools can model that path is the question worth asking.
If you want to see what proof-first looks like on your own attack surface, book a POC.