Sorting 2026's data breaches by how attackers got in
2026 data breaches grouped by entry method, each tied to a primary source (company, regulator, researcher) or marked as press coverage.
Large breaches have kept coming in 2026, and several landed in quick succession between June and early October: Times Car in Japan (about 6.6 million accounts), the Yakiniku King restaurant app (about 10.79 million member records), Aflac Life Insurance Japan (about 4.4 million people), and Denmark's national population register (about 8.8 million people).
I sorted the public disclosures by how the attacker got in, and labeled the source of every claim. This is a survey as of October 6, 2026. It covers cases disclosed from January to early October whose sources I could check, and it uses published information only. Gaps stay marked as gaps.
One question runs through the article. The entry methods differ a lot, so is there anything the large cases have in common? The answer comes near the end.
How to read the sources
Each source carries one of two labels.
- Primary: a page published by the organization involved, a government body, or the researcher who did the analysis
- Press: news or commentary, used when I could not find a primary page
Where a cause has not been published, I write "not disclosed". Each case sits in the category its own disclosure points to. Some cases fit two, and I note that.
A. Exploited vulnerabilities
Perimeter devices, file transfer systems, and third-party software.
| Case | Scale | Entry | Source |
|---|---|---|---|
| Japan's Digital Agency, GSS (announced Sep 11) | about 246,000 records | A VPN vulnerability. The attacker then read a large number of files through a maintenance operator's account | Primary: Digital Agency (Japanese) |
| KDDI mail platform for ISPs (confirmed Jun 17) | about 12.23 million email addresses, about 7.62 million passwords | A vulnerability in older third-party software | Press: INTERNET Watch (Japanese) |
| US Defense Manpower Data Center (found Jul 16) | about 3 million people, including about 294,000 deceased | A flaw in a file-sharing system. The product is not named | Press: SecurityWeek , Military Times |
| Citrix NetScaler (late September) | number of affected organizations unknown | CVE-2026-88771 and CVE-2026-88772 are confirmed as actively exploited | Primary: UK NCSC |
The GSS disclosure shows how detection happened. On June 25 the agency noticed bulk file access through a maintenance operator's account. It confirmed the VPN vulnerability as the entry on July 9. The way in was a vulnerability, but the activity inside looked like a legitimate account at work, which leads to category B.
Counts for the DMDC case differ by outlet. Military Times, citing two people familiar with the matter, reported about 4 million. I used SecurityWeek's figure of about 3 million.
B. Access that looked like normal use
In these cases the activity inside looked like normal use of a legitimate credential, permission or feature. Denmark's ministry says a legitimate lookup permission was misused. Aflac's report says only that the access matched normal use; it does not say a permission was abused or credentials were stolen. Putting Aflac in this group is my call.
| Case | Scale | Method | Source |
|---|---|---|---|
| Denmark's CPR population register (September, announced Oct 5) | about 8.8 million people | A Danish company's legitimate lookup permission was misused | Primary: Ministry of Research, Education and Digitalisation , CPR (Danish) |
| Aflac Life Insurance Japan (started Jun 10, found Jun 25) | about 4.4 million people; about 220,000 with bank account details | Access in a form that matched normal use, with a large volume of data lookups in a short time | Primary: Aflac report to the FSA, Jul 31 (Japanese) |
| Ryomo Systems (intrusion Aug 12) | about 124,000 records at Daito Gas, 3,789 at Isesaki City, and others | A VPN account was abused; ransomware followed | Press: Security Measures Lab (Japanese) |
| Vercel (announced Apr 19) | environment variables of some customers | A third-party AI tool (Context.ai) led to a takeover of an employee's Google Workspace account | Primary: Vercel |
| ShinyHunters-branded activity (reported Jan 31) | no counts given | Phone calls that lead employees to give up SSO credentials and MFA codes, followed by enrolling the attacker's own MFA device | Primary: Google Cloud |
Aflac's report lists three causes:
- The system had detection and blocking, but the access looked like normal use, so it was not caught right away
- Monitoring and control for a large number of lookups in a short time was missing
- Design-time security review and pre-release penetration testing had not anticipated this method
The report does not say credentials were stolen. Some secondary summaries call this case "abuse of a legitimate account", but the primary document describes lookups that were indistinguishable from normal use.
Denmark's case is the clearer one. The ministry's release says a Danish company's legitimate access was misused. The minister's remark that a small company ran an unusually large number of queries over about ten days comes from wire coverage (Danish), and I could not confirm it on a primary page.
Google's write-up gets specific about detection. Examples include an MFA enrollment within 30 minutes of a password reset, and a Google Takeout export of 500 MB or more. It watches what happens after authentication succeeds.
C. Through AI agents
These are researcher demonstrations, not reports of real-world damage.
| Case | Method | Status | Source |
|---|---|---|---|
| AWS AgentCore Harness (Unit 42, published Sep 18) | Hidden instructions in a support ticket make the agent run its default shell tool, which reads the execution role's JWT from process memory and replays it against a downstream MCP server | AWS closed the report on Jun 10 as within the shared responsibility model; no code change | Primary: Unit 42 . Press: CSA |
| Salesforce Agentforce, "SalesBleed" (Zenity, published Sep 24) | A malicious Web-to-Lead submission; the agent leaks CRM data over DNS while processing it | Salesforce fixed the URL redaction bypass on Aug 18; this chain is closed | Primary: Zenity |
The AgentCore case depends on configuration. The tools were left at their defaults with no allow list, and the shell tool ran as root. Unit 42 recommends narrowing the allowed tools, giving the credential vault the least privilege, and monitoring outbound traffic.
The June 10 closure date comes from the CSA note. Unit 42's own article gives no date for it.
D. Cause not disclosed
As of October 6, 2026, the entry point is not public for these cases.
| Case | Scale | What is published | Source |
|---|---|---|---|
| Times Car (detected Sep 25) | about 6.6 million accounts | Detected at 9:07 on Sep 25, access path cut by 7:25 on Sep 26. Passwords were stored in a non-reversible form. Entry route and vulnerability not disclosed | Primary: Park24, second report (Japanese) |
| Yakiniku King app (confirmed Oct 2) | about 10.79 million member records | Member management system of the official app. Name, email address, phone number and similar. Passwords and payment data not included. Cause under investigation | Primary: Monogatari Corporation (Japanese) |
| ShopServe by E-Store (May 21 to Aug 1) | 8,853,839 records, which may include duplicates for one person | An unauthorized program ran on the server and sent purchaser data out. Entry not disclosed | Press: Net Shop Tanto-sha Forum for the count and the account. E-Store's own release not checked |
| Scala Communications, a contractor of Daiwa Securities (Oct 2 to 3) | about 110,000 people | Unauthorized access to an inquiry-management server. The contractor is investigating | Press: Security Measures Lab (Japanese) |
Times Car and Seasar2
Some commentators point out that Times Car's website appears to use Seasar2, a Japanese Java framework that has been out of support for years. The evidence offered is a set of identifiers in the public HTML. What the sources confirm:
- The Seasar project ended maintenance and support for most of its products on September 26, 2016, including Seasar2 and Teeda. Primary: Seasar project
- Park24's second report says nothing about the entry route, the vulnerability or the framework
- Seeing an identifier does not show it was the way in, and no causal link has been published
The write-up that raised the point (Japanese) also separates its speculation from fact and does not name Seasar2 as the cause. A follow-up report with preventive measures could change the picture.
Cross-cutting axis 1: spread through contractors and shared platforms
A single compromise can reach many customers at once.
| Case | How it spread | Source |
|---|---|---|
| ielove CLOUD, a cloud service for real estate firms (Apr 5 to 6) | Customer account details were stolen with infostealers and a system vulnerability was also exploited. Victims included real estate firms, portal operators and end users | Primary: ielove GROUP, second report (Japanese) |
| KDDI mail platform | Six ISPs, including @nifty, BIGLOBE and J:COM, share the same platform | Press: @IT (Japanese) |
| ShopServe | Merchants were affected. One merchant, PFU, announced that up to 169,355 order records may be involved | Primary: PFU (Japanese), for PFU's own count only |
| Ryomo Systems | Spread to Daito Gas, Isesaki City and Nabari Kintetsu Gas | Press: Security Measures Lab (Japanese) |
| Vercel | Entry came through a third-party AI tool | Primary: Vercel |
Digital Arts' own analysis (primary for its tally) of the first half of 2026 counted 727 publicly disclosed incidents at Japanese organizations: 267 unauthorized accesses, 153 malware infections, and 55 cases of misuse or removal of data by insiders. The last category is 3.7 times the same period a year earlier, and 14 of the 55 started with an employee's social media post. The report also says one cloud service for the real estate industry affected 67 organizations, and one system vendor's ransomware incident affected 25. The summary I could read does not name the service or the vendor.
Cross-cutting axis 2: data that was kept
What an organization kept, for how long and in what form shaped what was exposed.
- DMDC kept unencrypted personal data on a file-sharing system, including records of about 294,000 deceased people (Press: SecurityWeek and Military Times, linked above)
- Times Car exposed identity-document information such as driver's license images, which cannot be invalidated by changing a password (Primary: Park24, second report, linked above)
- The KDDI platform's exposed data included information on users who had already canceled (Press: @IT , Japanese)
Times Car's retention period of about seven years after leaving the service comes from a press piece citing the company's FAQ. I did not check the FAQ itself, and I could not tell how it applies to people who never finished signing up.
How long it ran, and how much data was there
Back to the opening question. Entry methods differ. Among the cases with a known duration, two things stand out. This is my reading of public information from a small number of cases, so treat it as a tendency. Times Car and Yakiniku King have not published a duration, so they are not counted here.
Time until discovery, or until the customer organizations were told (sources are in the tables above; DMDC's dates come from the press sources):
- Denmark: about 10 days in September (press)
- Aflac: 15 days, from June 10 to June 25
- ShopServe: about 72 days, from May 21 to August 1
- Ryomo Systems: 43 days from the August 12 intrusion to the September 24 notice to customers
- DMDC: about 9 months, from October 2025 to July 16, 2026
The amount of data held can only be inferred from the counts. The Daiwa Securities contractor was accessed for roughly 11.5 hours (about 20:33 on Oct 2 to 8:01 on Oct 3), and about 110,000 people were still affected. No source gives the amount held independently, so I use this only as an example of a short window with a lot of data within reach.
My reading: the size of each case tracked two things, how long the activity went on and how much data was within reach. Aflac's own preventive measures point the same way: stronger monitoring and control of mass access, plus stronger authentication and authorization.
What I could not confirm
- The entry points for Times Car and Yakiniku King are not public. I cannot say whether the incidents around October 2 share an attacker
- For the Daiwa Securities contractor, Ryomo Systems, KDDI and ShopServe, I could not reach the company's own release and used press coverage
- The DMDC count varies by outlet
- The two AI agent cases are researcher demonstrations, not reports of real damage
- I did not list victim names or counts for ShinyHunters-branded activity, because I could not confirm them from a primary source
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article