Credit bureau TransUnion has confirmed a data breach affecting 4,461,511 U.S. consumers, exposing names, dates of birth, billing addresses, contact details and unredacted Social Security Numbers. The intrusion did not touch TransUnion's core credit database. It reached a third-party application connected to Salesforce that supports the bureau's U.S. consumer support operations. The incident occurred on July 28, 2025, was discovered on July 30, and notification letters went out by U.S. Mail on August 26, 2025, with the notification pool reportedly expanded through 2026 as investigators mapped the full scope.
A sourcing caveat up front: this brief is written entirely from secondary reporting. None of the available sources is a primary artefact. TransUnion's letter to the Maine Attorney General is the anchor document for the 4,461,511 figure, but it is quoted here at second hand via DeafNews, Duggan USA and Al Jazeera rather than read directly. Treat the granular details accordingly.
What Happened
The consistent account across sources runs as follows. On July 28, 2025, an unauthorised party accessed a third-party application serving TransUnion's U.S. consumer support operations. TransUnion detected the activity two days later, on July 30. DeafNews, citing the New Jersey Cybersecurity and Communications Integration Cell (NJCCIC), reports the incident was contained within hours of detection.
TransUnion's own language, as quoted by Al Jazeera from the Maine AG filing, was that it "recently experienced a cyber incident involving a third-party application serving our US consumer support operations" and that it had "quickly contained the issue, which did not involve our core credit database or include credit reports." The company declined to name the third-party application. That refusal is the origin of most of the confusion that followed.
Maine's breach disclosure law is what forced the numbers into public view. Of the 4,461,511 people notified, roughly 17,000 were Maine residents, per Al Jazeera. TransUnion offered free credit monitoring to affected consumers. Al Jazeera notes the stock moved 0.2 percent on the announcement, which is to say the market did not care.
What Was Taken
Per TransUnion's consumer notifications as reproduced by PrivacyOn and DeafNews, the exposed fields include:
- Full name
- Date of birth
- Social Security Number, unredacted
- Billing address
- Email address
- Phone number
- Customer support ticket contents
Philip Metzger's write-up adds an important qualifier that the marketing-driven coverage tends to drop: the data varied by person, and only some records included SSNs. That matters for triage. It does not soften the headline, because unredacted SSN plus name plus date of birth plus address is a complete synthetic-identity kit with no further enrichment required.
The volume figures diverge sharply depending on who is counting:
- 4,461,511 individuals is TransUnion's own notified population, per the Maine AG letter as reported by DeafNews, Duggan USA and Al Jazeera. NJCCIC rounds this to approximately 4.4 million.
- 13.1 million records is a threat-actor claim. ObscureIQ reports that a group calling itself "Scattered LAPSUS$ Hunters" published a sample on October 3, 2025, with a full dataset of 13.1 million records reportedly scheduled for release on October 10, 2025. PrivacyOn repeats the same figure as a claim, not a confirmation.
These are not necessarily contradictory. Notified individuals and stolen records are different units, and duplicates, non-U.S. subjects and support-ticket rows can inflate a record count well past a person count. ObscureIQ's own summary undercuts the sensational framing of its headline by noting SSNs appeared in roughly 1 percent of sampled records. Nothing in the available sourcing confirms 13.1 million as validated. Only ObscureIQ asserts it as a figure, and it is the sole source for the October leak timeline, the "approximately 39 organizations" target list, and the additional fields it lists (IP addresses, support chat transcripts, authentication status flags). Treat all of that as single-source and unverified.
Where Accounts Diverge
The sources genuinely conflict on which campaign this belongs to, and the disagreement is worth stating plainly rather than resolving by fiat.
PrivacyOn places the breach inside the Salesloft Drift wave, naming UNC6395 and ShinyHunters and citing TransUnion and Mandiant for a compromise window of "late July 2025 and early August 2025," part of a campaign hitting 700-plus organisations via stolen OAuth tokens issued to the Drift chatbot integration.
Duggan USA argues the opposite, and argues it on dates rather than opinion. TransUnion's incident occurred July 28 and was discovered July 30. UNC6395 abused the stolen Drift OAuth tokens against Salesforce instances between August 8 and at least August 18, 2025; Salesloft and Salesforce revoked all Drift tokens and pulled the app from AppExchange on August 20. On that timeline, TransUnion's breach predates the Drift exfiltration window by eleven days and its discovery predates the first token abuse by nine. The conflation, Duggan argues, is an artefact of calendar coincidence: TransUnion's letters landed August 26, the same week the Drift story broke and Google's threat intelligence group published its fuller account.
DeafNews reports attribution converging on ShinyHunters, citing direct confirmation from the group to BleepingComputer linking the incident to a broader Salesforce campaign. ObscureIQ tags it "Scattered LAPSUS$ Hunters" and "social engineering." The Tech Edvocate attributes it vaguely to "a vulnerability within TransUnion's Salesforce account."
The defensible reading: this is part of the broader 2025 Salesforce-ecosystem campaign associated with ShinyHunters and its aliases, but the specific Drift-token attribution does not survive the timeline. Duggan's date argument is the strongest reasoning in the source set and PrivacyOn offers no dated evidence against it. If you are writing detection logic off Drift-specific indicators, that is the wrong hunt for this incident.
Why It Matters
TransUnion holds credit files on more than 200 million U.S. consumers. The core credit database held. Everything the sources report suggests TransUnion's primary infrastructure was never in play, and the company has been emphatic on that point across every filing and statement quoted.
That is precisely the finding. The bureau successfully defended the crown jewels and lost 4.46 million unredacted SSNs anyway, out of a support system nobody would have listed as a tier-one asset. The peripheral SaaS integration, the OAuth-connected app that nobody names in the org chart, held enough identity material to be functionally equivalent to a credit-file breach for the people involved. As PrivacyOn puts it, the stolen fields are more than enough to enable identity theft even without access to a credit file.
A second point defenders should sit with: support-ticket contents were in scope. Ticket bodies are an unmodelled data class. Consumers paste SSNs, account numbers and dispute documentation into support channels because they were asked to, and that text lands in a CRM object with a far weaker control surface than the system of record it describes.
Legal exposure is following the usual arc. Lawfold reports multiple consolidated and separately filed federal class actions against TransUnion LLC, focused on both data-security failures and Fair Credit Reporting Act violations, with N.D. Illinois among the primary courts. Lawfold notes these actions span multiple incidents and reporting failures rather than this breach alone, and it is a claims-marketing site, so read its payout estimates as advertising rather than intelligence.
The Attack Technique
The technical detail available is thin, because TransUnion has not named the application and no primary technical advisory appears in the source set.
What the sources support: the entry point was a third-party application connected to Salesforce, authorised via OAuth, serving U.S. consumer support. DeafNews, citing NJCCIC, reports the access vector did not involve a zero-day. Al Jazeera frames the surrounding wave as attackers "trick[ing] employees into opening up their respective employers' Salesforce databases," which is the voice-phishing and malicious-connected-app pattern that defined the 2025 Salesforce campaign. ObscureIQ tags the incident as social engineering and reports that Salesforce attributed the broader campaign to customer-side integration weaknesses rather than a compromise of its own platform.
The shape, then, is credential or token abuse against an authorised integration, not exploitation. The application had legitimate, standing API access to consumer support records. Whoever held its token inherited that access. No malware, no lateral movement, no alert on the core database, because from the platform's perspective an approved app read records it was approved to read. This is why detection lands on volume and behaviour rather than signature, and why containment in TransUnion's case meant revocation rather than eviction.
What Organizations Should Do
- Inventory every OAuth-connected app in your SaaS tenants and record what each one can actually read. In Salesforce, pull the Connected Apps list and the OAuth usage report. Most organisations discover apps authorised by someone who left two years ago. An app you cannot name is an app you cannot revoke under pressure.
- Cut standing API scopes to the minimum, and put a clock on them. A support-desk integration does not need read access to SSN fields. Scope reduction is the single control that would have changed the outcome here, because the attacker's access was exactly the app's access.
- Alert on API read volume, not just on logins. Bulk export by an authorised integration is the signal. Baseline normal query volume per connected app and page on deviation. TransUnion detected in two days and contained in hours; the two days are where the data went.
- Stop letting SSNs live in CRM and ticketing systems. Redact or tokenise sensitive identifiers at ingest, and enforce it on free-text ticket bodies as well as structured fields. Support-ticket contents were in scope in this breach.
- Harden the help desk against voice phishing and rehearse it. The surrounding campaign ran on social engineering of employees into authorising app access or handing over credentials. Require out-of-band verification for any request involving MFA resets or app authorisation, and test it with real callbacks.
- Write the app-revocation runbook before you need it. Salesloft and Salesforce revoked every Drift token in a single day in the parallel incident. Know now who can mass-revoke tokens in your tenant, what breaks when they do, and how you tell the business.
- Extend third-party risk review to OAuth grants, not just contracts. Vendor questionnaires do not cover the app an admin authorised in four clicks. Treat every OAuth grant as a vendor relationship with data-access rights, because that is what it is.
Sources: TransUnion, the SaaS Periphery Paradox: 4.4 Million SSNs Exposed…... | No, the TransUnion Breach Was Not the Salesloft Drift Breach. They... | TransUnion Credit Bureau Breach (Salesforce, 2025): 13 Million Cust... | TransUnion Data Breach: What to Do Now (2026 Guide) PrivacyOn | Is Trans Union Safe? Trans Union Data Breach Explained | Your TransUnion Data Exposed? 7 Critical Steps to Protect Your Iden... | Transunion hack exposes consumer data for millions of Americans Al... | TransUnion Data Breach Lawsuit: Your 2026 Full Guide