Security Guides

#data breach #incident response #detection #rate limiting #Japan

Different Doors, Same Ending — What Japan's Four Biggest 2026 Breaches (KDDI, Aflac, Digital Agency, Sakura) Have in Common

Four major Japanese breaches of 2026, compared using only the organisations' own disclosures. The ways in differed completely, yet three of the four named better detection as their fix. What works against attacks that look like normal use.

Published 2026-09-11 Updated 2026-09-11 Last verified 2026-09-11 13 min read

Who this is for: people responsible for protecting a service or internal systems, and anyone who has seen these names in the news and wants the facts straight. This article compares each organisation's own official disclosures as primary sources, and contains no attack techniques.

The takeaway: assume the entrance will fail, and invest in watching volume and time

Line up the four major breaches disclosed in Japan in 2026 and the ways in have nothing in common — a flaw in third-party software that even its vendor did not know about, the data-query function of a web service, a VPN appliance, and one that was not disclosed. Yet they end the same way. Three of them — KDDI, Aflac and Sakura Internet — named stronger detection in their remediation plans, and the fourth, the Digital Agency, was caught through an anomaly in volume: bulk file access. Aflac wrote in its own words that the attack "looked the same as normal use", so it was not detected immediately. That is where this site's conclusion comes from: when an attack takes the shape of legitimate use, the only signals left are volume and time. Keep working on the entrance, but put as much into noticing how much data left, per request and per hour.

The four cases side by side (per each organisation's disclosures)

Organisation (disclosed)	Scope (as disclosed)	Way in (as disclosed)	From start to discovery
KDDI (from 23 Jun)	Confirmed exposure: email addresses of 12,231,954 people, passwords of 7,616,173	A vulnerability in third-party software built into the system — unknown to the vendor when found	Began 16 May → confirmed 17 Jun (about a month)
Aflac Life Insurance Japan (from 30 Jun)	About 4.4 million customers (about 220,000 with bank details), about 40,000 agencies	Insufficient controls on the access and data-query methods in "Online Consultation" and "Yorisou Net"	First leak 10 Jun → found 25 Jun (15 days)
Digital Agency (11 Sep)	About 246,000 records of staff and others possibly exposed	A VPN appliance vulnerability	Start of intrusion not disclosed → detected 25 Jun through bulk access
Sakura Internet (from 17 Aug)	1,360,563 member accounts possibly in scope, 951 hosting accounts	Withheld to avoid enabling copycat attacks	Sales system: Apr 2023 – Mar 2026 → detected 9 Aug 2026 via a different anomaly (about three years)

Do not read this table as a ranking of who did worst

The figures in this table are not equally firm. KDDI and Aflac report people whose data was confirmed exposed; the Digital Agency reports data possibly exposed; Sakura Internet reports the total possibly in scope. The systems differ, and so does the kind of data they held. Ranking them by headcount means nothing, and this site does not do it. What is worth comparing is what each organisation said it learned — its remediation plan.

What each organisation disclosed

KDDI: mail system for internet service providers

What: Unauthorised access to a mail platform KDDI developed for ISPs (account management, sending and receiving, web mail and mail storage in one system). KDDI says its own au mail and related services run on separate equipment and were not affected
Cause: "Exploitation of a vulnerability in third-party software installed as part of this system". As of 17 June, when it was confirmed, it was "a vulnerability the software vendor was not aware of"
Scope: The first notice (23 June) gave a possible maximum of 14.22 million. The report of 6 July (corrected 21 July) confirmed exposure of email addresses of 12,231,954 people, including passwords of 7,616,173
Response: Password changes coordinated with the ISPs, including forced resets by the ISPs for rarely used accounts. EDR rolled out to every server that controls external communication by 21 June. Going forward, a move to more secure communication standards

Aflac Life Insurance Japan: customer web service and agency tool

What: Unauthorised access to "Online Consultation", used by agents for remote policy design and applications, and the policyholder web service "Aflac Yorisou Net". Aflac says it confirmed no similar leak in its other systems
Cause (31 July results): "Controls against the access and data-query methods used in this attack were insufficient". Detection and blocking functions existed, but "because the format of the access was the same as during normal use, it could not be detected immediately as unauthorised access". Also, "functions to monitor and control large volumes of data queries in a short time were lacking"
Prior measures: Security reviews at design time and penetration tests before release had been carried out, but "the risk of the methods used in this attack had not been anticipated"
Scope: About 4.4 million customers (about 220,000 including premium-payment bank details) and about 40,000 agencies. My Number, card data and email addresses were not included

Digital Agency: Government Solution Service (GSS)

What: Unauthorised access to a work environment shared by staff across ministries and agencies. The agency says it confirmed no personal data of the general public was included
Cause: "A third party exploited a vulnerability in a network connection device (VPN) to get into the system". Product and vulnerability identifier not disclosed
Detection: On 25 June, bulk access to files on servers using a maintenance operator's account was detected. Covered in detail in VPN appliances are the biggest way in

Sakura Internet: sales management system and shared hosting

What: Unauthorised access to the sales management system holding contract records, and to part of the shared hosting environment. The company says no clear grounds link the two
Duration: Unauthorised access to the sales management system took place "between April 2023 and March 2026". Detection came on 9 August 2026, from an anomaly on a hosting maintenance server
Cause: The intrusion path is withheld to avoid enabling copycat attacks. The company also disclosed that some initial passwords were not hashed. What customers should do is covered in what to do when your web host is breached

What they had in common was detection

Talk about the entrance and the four cases scatter. But line up the remediation plans each organisation wrote for itself, and the same words keep appearing.

3 / 4

organisations that named stronger detection or monitoring (KDDI, Aflac, Sakura)

15 days

Aflac: from first leak to discovery

~1 month

KDDI: from start to confirmation (unknown vulnerability)

~3 years

Sakura: how long the sales-system access ran

The detection measures each named

KDDI: to strengthen detection of unauthorised access, EDR on every server that controls external communication (completed 21 June)
Aflac: stronger monitoring and control of bulk access in applications and security devices
Sakura Internet: wider monitoring and detection for early detection, and a review of the scope, retention and analysis of security logs

The Digital Agency was the case where detection worked

What tipped it off was bulk access to files using a maintenance operator's account
The intrusion was not prevented, but the volume anomaly let the agency scope it, suspend the account and cut communication
Its remediation — "reviewing vulnerability management" and "improving external connections" — is about the entrance

Legitimate use

An attack shaped like legitimate use

Volume

A few records per person, or tens of thousands?

Speed

Human pace, or machine pace?

Time span

Are there logs going back far enough?

When an attack takes the shape of legitimate use, you cannot tell them apart by what was done. The only signals left are how much and when.

What to do in your own organisation, today

Put a volume limit, and an alert, on anything that returns data

One of the causes Aflac named was that "functions to monitor and control large volumes of data queries in a short time were lacking". Give every API or screen that returns customer data a cap on records per request and per hour, plus an alert to a human as usage approaches the cap. Even with a valid login, pulling tens of thousands of records in a short time does not look like how people use a system. How to decide what to count, per whom, and up to what number, is covered in rate limiting and abuse control.

Check, on every query, whether this person may see this record

The first item in Aflac's remediation is stronger "authentication at access and authorisation at data query". Whether someone could log in (authentication) and whether they may see a particular record (authorisation) are separate questions, and if the second is not checked record by record, a properly logged-in user can query other people's data. The difference is explained in authentication vs authorisation, and the classic flaw in IDOR.

Keep logs for as long as you would need to look back

In the Sakura Internet case, access to the sales management system began about three years before it came to light. If the logs for that period are gone when you notice, you can say neither what happened nor what did not. Sakura too listed a review of log scope and retention. If storage only allows a few weeks, a realistic split is to keep at least authentication and data-query logs for much longer.

Assume unknown vulnerabilities exist, and plan to notice after entry

The flaw exploited in the KDDI case was one the vendor itself did not know about when it was found. No fix existed at the time. Since some entrances cannot be closed even with perfect patching, the ability to notice suspicious activity and outbound traffic on servers — the EDR KDDI deployed to every server is one example — is the last line of defense.

And still keep the entrance patched

None of this means the entrance matters less. The Digital Agency case came in through a VPN appliance vulnerability. Not leaving known vulnerabilities open is still the most cost-effective defense there is. For VPN appliances, see VPN appliances are the biggest way in; for ordering the work, see prioritising with CVSS, EPSS and KEV.

This site's view: a penetration test only finds the methods someone thought of

In this site's reading, the weightiest sentence in Aflac's results is not the cause itself but this: "We carried out security reviews at system design and penetration tests before system release, but had not anticipated the risk of the methods used in this attack." It is not that the measures were not done; it is that they were done, and the attack came from outside what was imagined — something that can happen to any organisation.

Checks before release can only test the methods the tester thought of. So the final net is noticing, in production, unusual volume, speed and timing. That three of the four named detection in their plans reads as each of them hitting that same limit in its own incident. Reviews and tests exist to shrink the entrance; detection exists to shorten the time after entry — different jobs, and neither covers for the other.

What to do as an individual, today

The real risk to you is less the breach than the follow-up messages it invites

(1) Do not reuse passwords — passwords were confirmed exposed in the KDDI case, and a reused one opens your other accounts too (a password manager is the practical answer). (2) Do not use links or phone numbers from messages invoking the organisation's name — the Digital Agency and Sakura Internet explicitly warned about messages impersonating them, and Aflac asks anyone who receives a suspicious contact to call its own line. Check by going to the official website yourself. (3) If bank details are involved, check your account activity — Aflac says it is working with the relevant banks for policyholders whose account details were exposed. If anything looks wrong, contact both your bank and the organisation.

Sources

The facts above come from each organisation's official disclosures. No speculation about unpublished product names or intrusion paths.

KDDI Corporation, notice on unauthorised access to the mail system for ISPs (23 June 2026, Japanese) — newsroom.kddi.com
KDDI Corporation, apology and report on the unauthorised access to the mail system for ISPs (6 July 2026, updated 21 July; Japanese) — newsroom.kddi.com
Aflac Life Insurance Japan, second report on the unauthorised access and information leak (13 July 2026, Japanese) — aflac.co.jp
Aflac Life Insurance Japan, investigation results and remediation measures (31 July 2026, Japanese) — aflac.co.jp
Digital Agency (Japan), on the possible leak of personal information via unauthorised access to the Government Solution Service (11 September 2026, Japanese) — digital.go.jp
Sakura Internet Inc., investigation results and remediation measures (third report, 10 September 2026, Japanese) — sakura.ad.jp

Update log

2026-09-11: First version, based on the four organisations' official disclosures (the latest published as of 11 September 2026). Will be updated as each case develops.

FAQ

QWhich major data breaches were disclosed in Japan in 2026?

Per each organisation's official disclosures: KDDI's mail system for ISPs (confirmed exposure of 12,231,954 people's email addresses, including 7,616,173 people's passwords); Aflac Life Insurance Japan (about 4.4 million customers, about 220,000 of them with premium-payment bank account details, plus about 40,000 agency records); Japan's Digital Agency and its Government Solution Service (about 246,000 records of staff and others possibly exposed); and Sakura Internet (1,360,563 member accounts possibly in scope). The figures are those published at the time, and how firmly they are established differs from case to case.

QWhat caused the Aflac Japan breach?

In its investigation results of 31 July 2026, Aflac stated that its 'Online Consultation' and 'Aflac Yorisou Net' systems had insufficient controls against the access and data-query methods used in the attack. The systems did have functions to detect and block unauthorised access, but because the access looked the same as normal use it was not detected immediately, and there was not enough monitoring and control for large volumes of data queries in a short time.

QCould a patch have prevented the KDDI incident?

According to KDDI, the vulnerability exploited was in third-party software it had built into the system, and as of 17 June 2026 — when KDDI confirmed the intrusion — the software's vendor itself was not aware of it. In other words, no fix existed at the time. Against unknown vulnerabilities like this, the last line of defense is noticing the intrusion and stopping it from spreading.

QWhat is the common lesson across the four cases?

The ways in do not resemble each other. Yet KDDI, Aflac and Sakura Internet all listed stronger detection in their remediation plans (EDR on every server, monitoring and control of bulk access, wider early-detection monitoring and longer log retention), and the Digital Agency case was caught through an anomaly in volume — bulk file access. When an attack looks like legitimate use, the signals left are volume and time. Keep guarding the entrance, but invest as much in noticing once someone is inside.

QWhat should I do as an individual?

Three things. Do not reuse passwords across services — passwords were confirmed exposed in the KDDI case. Do not use links or phone numbers from messages that invoke the organisation's name after an incident; go to the official website yourself. If bank account details are involved, check your account activity and contact both your bank and the organisation if anything looks wrong.