The Carhartt Breach Was Half What Was Claimed

ShinyHunters said it stole 25 million Carhartt accounts. When Troy Hunt, the researcher who runs Have I Been Pwned, actually verified the leaked dataset field by field, the real number of unique, genuine people was about 12.9 million. Nearly half the claimed dump was synthetic addresses, disposable test accounts, and duplicate junk records padding the total. That gap is the actual story here, not because 12.9 million exposed records is a small breach (it isn’t), but because it shows how much of a breach headline is negotiation theater, and because the way attackers got in says more about where the next breach is coming from than the record count does.

What was real, and what wasn’t

Carhartt disclosed the incident after ShinyHunters published data it claimed came from the workwear retailer, with an initial extortion demand reported around $3.3 million. The published dump listed close to 25 million records. Hunt’s analysis, cross-referencing the data against known patterns of synthetic and test entries, found that a large share of the dataset was garbage: auto-generated addresses, obviously fake phone numbers, and rows that repeated across the file with only cosmetic differences. Once those were stripped, roughly 12.9 million real, de-duplicated individuals remained, exposed fields limited to names, phone numbers, physical addresses, and emails. More than 15,000 of those addresses belonged to Carhartt’s own staff (@carhartt.com), which matters for a different reason: internal addresses are the raw material for a convincing follow-up phishing campaign against the company itself, independent of how many customers were affected.

No passwords or payment data were reported in the leak, which is the one piece of genuinely good news in an otherwise bad month for Carhartt’s security team.

The entry point matters more than the headcount

The breach traces back to Carhartt’s Databricks analytics platform, not a direct hit on the e-commerce checkout flow or the primary customer database. That detail is the part worth remembering after the record-count argument fades from the news cycle.

Analytics and data-warehouse platforms like Databricks and Snowflake typically hold a synced or exported copy of production customer data, refreshed on a schedule, so that business intelligence teams can query it without touching the live transactional system. That’s a sensible architecture for performance and isolation. It also means the analytics layer ends up holding the same sensitive data as the production database, frequently with a different, often less scrutinized, set of access controls: broader service-account permissions, longer-lived credentials, fewer people reviewing who has query access, and less monitoring for the kind of bulk-export pattern that would trip an alert on the primary system.

ShinyHunters ran an extended 2025 campaign against Salesforce and Snowflake customers using exactly this pattern: compromise credentials or an OAuth integration tied to the analytics or CRM layer, then pull a bulk export that looks, from the platform’s perspective, like a normal reporting job. Carhartt’s Databricks breach is the same playbook applied to a different vendor. If your organization has spent 2025 hardening the production database and hasn’t run the same review against whatever platform your data team uses for reporting, that gap is now a documented attack pattern, not a hypothetical one.

Verifying a breach claim before you act on it

Extortion groups have a direct financial incentive to inflate the number attached to a breach. A bigger headline number pressures the victim company harder in ransom negotiations and generates more press coverage, both of which serve the attacker regardless of what’s actually in the file. Treat a first-reported record count the way you’d treat any other unverified claim from an interested party:

1. Check whether an independent researcher has validated the sample. Troy Hunt’s write-ups, and Have I Been Pwned once a dataset is loaded, are the standard reference point for consumer breach data specifically because he checks for duplicates, synthetic records, and prior-breach recycling before publishing a number.
2. Look at what fields are actually populated, not just the row count. A dump with 25 million rows but sparse, inconsistent, or obviously templated fields in a third of them is not a 25-million-person breach.
3. Assume the entry vector reported by researchers is more actionable than the headline number. Knowing it was a Databricks compromise tells you exactly what to go check in your own environment. Knowing “25 million” or “12.9 million” tells you almost nothing about your own risk.

This same discipline applies to the npm supply chain attacks that have hit the JavaScript ecosystem through 2026: the initial claimed blast radius is rarely the verified one, and the mechanism of compromise is always the more useful thing to act on.

What to actually check this week

If your stack includes Databricks, Snowflake, or a comparable analytics platform holding a copy of customer or user data, the Carhartt incident is a specific, concrete reason to run the same access review you’d run against your production database:

Control	Production database (usually already done)	Analytics platform (often skipped)
MFA enforced on all human accounts	Yes	Check this week
Service account credentials rotated on a schedule	Yes	Check this week
Bulk export or large-query alerting	Yes	Check this week
Least-privilege query scoping per team	Yes	Often “everyone with access sees everything”
Regular access review (who still needs this)	Yes	Frequently stale

None of this is exotic. It’s the same checklist most security teams already run against the systems they think of as “the real database.” The Carhartt breach is a reminder that a synced analytics copy of that same data is, from an attacker’s perspective, an equally good target with a historically easier door.

The record count will get corrected downward, argued about, and eventually forgotten. The entry point won’t change: it’s still Databricks, and the fix is still an access review most teams haven’t scheduled yet.