Salesforce identified unauthorised access to customer data occurring through the Gainsight application, a customer success platform integrated with tenant environments.
The Corpus Has Now Recorded Both Halves Of This Problem
At 25-0806, attackers persuaded employees to authorise an application the attackers controlled. The consent model at 25-0311 routed a security decision to whoever happened to be logged in.
Here the application was legitimate, chosen deliberately, authorised correctly, and doing exactly what it was integrated to do. The compromise arrived through it anyway.
The first case argues for stronger consent controls. The second demonstrates that consent controls would not have helped, because nothing about the authorisation was wrong.
It Is The Supplier Problem In A New Location
The corpus files supplier concentration constantly — Marquis at 25-0814, Chain IQ at 25-0613, SitusAMC at 25-1112b. In each, an organisation sent data to a vendor.
An integration is different in mechanism and identical in effect: the data does not move, and a third party is granted continuing authorised access to it in place. The token-revocation argument at 25-1207 applies in full — the grant persists until somebody removes it, and nothing generates an alert while it sits there.
And Nobody Has An Inventory
This desk argued at 25-1207 that you cannot revoke what you have not enumerated, and that organisations unable to list their connected applications have no remediation available after any of these incidents.
The practical question this file raises for every tenant is narrower and answerable: which applications currently hold standing access to your data, who approved each, and when was that last reviewed. The corpus has found no evidence that this is routine anywhere.
Graded medium: the incident is described in vendor and press reporting, and this desk has not established the mechanism, the scope, or the number of tenants affected.
Compiled from published reporting, listed below. The mechanism and scope are not established. We do not assert fault on the part of any party. Corrections: corrections@forensicpost.com.