Nissan's Fourth Breach in Four Years Wasn't Nissan's. That's the Whole Problem.
- Patrick Duggan
- 5 minutes ago
- 5 min read
Every time Nissan customer data hits a leak site, Nissan says the same true, useless thing: our systems were not compromised. And every time, it is correct — because the data did not leave through Nissan. It left through a vendor. The pattern is the story, and "our systems are clean" is becoming the most hollow reassurance in breach response.
There are two separate Nissan data incidents in the public record from the last nine months, plus a longer tail of prior years, and they share exactly one feature that matters: none of them is a compromise of Nissan's own infrastructure. Hold that thought, because it is the entire point.
Thread one: the dealer data, via a vendor's FTP
The big-number one belongs to a ransomware-and-extortion crew called Everest. Everest breached a third-party vendor — GCSSD Apps (Global Customer Service & Sales Data) — whose FTP infrastructure served the Nissan and Infiniti dealer network across North America. The group claimed roughly 910 gigabytes of customer records and car-loan information. When DataBreach.com parsed the dump, it reported something like 17.1 million vehicle identification numbers, 4.19 million names, 4.06 million street addresses, 2.68 million phone numbers, and 2.05 million email addresses.
The timeline reads like a textbook extortion play. Everest tried a quiet shakedown in January 2026, posted the claim on its leak site on January 10, and then, when the money did not come, went loud on April 1 with a two-day release threat. Nissan's response: "no indication that Nissan systems were compromised or that any Nissan customer information was accessed or put at risk." Both halves of that sentence are technically defensible — and both sidestep the fact that millions of Nissan customers were in a file a stranger was selling.
Thread two: the Japanese customer data, via Red Hat
The fresher one came in through a completely different vendor and a completely different crew. A group calling itself Crimson Collective breached Red Hat's consulting GitLab in the fall of 2025 — claiming around 570 gigabytes from some 28,000 private repositories. One of the things sitting in that haystack was personal data for about 21,000 customers of Nissan Fukuoka Sales in Japan: names, addresses, phone numbers, partial emails, sales-activity records. No payment-card data. Red Hat notified Nissan on October 3, 2025; Nissan disclosed in Japan on December 19 and reported it to the country's privacy regulator.
One disambiguation worth making, because the names blur: this Red Hat incident is not the same as the "Miasma" npm-package backdooring that hit the Red Hat ecosystem in June — that one poisoned published packages; this one stole source repositories. Same vendor name, two unrelated compromises. We are not connecting them, and neither should anyone else without evidence.
The thing both threads have in common
Look at the two incidents side by side. Different attackers — Everest, a financially-motivated extortion brand; Crimson Collective, a repo-theft extortion crew. Different vendors — a dealer-data FTP host, an enterprise software consultancy. Different continents, different data sets, different months. And the same root: Nissan's customers were exposed because Nissan's data was sitting somewhere Nissan does not run.
This is what the term extended blast radius actually means, stripped of consultant gloss. Your security program can be flawless inside your own walls and it changes nothing if the customer record also lives at a dealer-data processor, a regional sales subsidiary's software vendor, and an enterprise consultancy's source-code repository. The attacker does not need your front door. There are fifteen side doors with your data behind them, and you do not hold the keys to any of them.
It is the same lesson we keep writing from every direction this year: the crews increasingly do not build their own malware, and they increasingly do not breach the brand-name target directly. They breach the supplier and let the brand name do the reputational damage for them. The way in is almost never the dramatic zero-day against the famous logo. It is the contractor login, the vendor's exposed FTP, the consultancy's GitLab token nobody rotated.
What "our systems were not compromised" should trigger, not end
When a company responds to a breach with "our systems were not compromised," the correct reaction is not relief. It is a question: then whose were, and how many of them hold our data? A few things follow, in plain order.
First, inventory the data, not just the network. You cannot defend customer records you have not mapped to the third parties holding them. Most organizations cannot produce that list on demand, which is the whole problem.
Second, treat vendor breach notification as a clock you do not control. Nissan learned about the Red Hat exposure a week after the fact, from Red Hat. The dealer-data exposure surfaced when an extortion gang posted screenshots. In both cases the victim org was downstream of someone else's detection — and someone else's disclosure timeline.
Third, contract for it before you need it. Breach-notification windows, forensic access, and data-handling limits are cheap to negotiate at signing and impossible to impose mid-incident. The vendor whose FTP server leaks your customers' loan data should already owe you a defined response, not a shrug.
Fourth, assume the data is already copied. Everest is part of the broader move toward extortion that does not bother to encrypt anything — it just takes the files and threatens to publish. There is no "restore from backup" defense against publication. The only thing that blunts it is knowing, in advance, what a given vendor could lose on your behalf.
The honest cap
We cap our confidence at 95%, and here is where the missing five percent lives. The 910-gigabyte and 17-million-VIN figures are leak-site and third-party-parsing claims; extortion crews inflate, recycle, and occasionally fabricate. The Crimson Collective repository counts are the attacker's own numbers. Nissan's statements that its internal systems were untouched are plausible and, on current evidence, probably accurate — which is exactly the point of this piece, not a contradiction of it. The systems being clean is not the same as the customers being safe.
Nissan is not unusually careless here. It is unusually visible — a brand big enough that every vendor it touches becomes a target, and every vendor breach becomes a Nissan headline. That is the future for every recognizable name. The breach that hurts you next will, statistically, not be yours. It will be theirs, with your data in it.
DugganUSA builds threat intelligence from first-hand collection and a curated, inspectable corpus of more than 24 million documents. Breach volumes and attacker claims here are drawn from public reporting and adversary leak-site statements and are treated as claims, not confirmed facts; we cap our confidence at 95% because something is always wrong. Sources include SecurityWeek, BleepingComputer, The Record, Hackread, Cybernews, and DataBreach.com reporting on the Everest and Crimson Collective incidents.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.