Aflac Life Insurance Japan Ltd., the wholly owned Japanese subsidiary of Georgia-based Aflac Incorporated, has confirmed that an unauthorized third party accessed its systems repeatedly between June 15 and June 25, 2026, exfiltrating personal data tied to approximately 4.38 million people. The company disclosed the incident publicly on June 30 and filed a Form 8-K with the U.S. Securities and Exchange Commission the same day. Roughly 230,000 of those affected also had premium payment bank account details exposed. Every source reviewed here, including the SEC filing summary and Japanese-language reporting, converges on the 4.38 million figure, making this one of the rare large breaches with no meaningful dispute over headline scale. It is also the second major cyberattack against the Aflac corporate family in just over a year.
What Happened
Per Aflac's own 8-K, quoted directly by BleepingComputer and Security Affairs, "on June 25, 2026, Aflac Japan discovered an unauthorized third-party had unlawfully accessed certain of Aflac Japan's systems between June 15, 2026 and June 25, 2026." That is a ten day dwell window in which the intruder was inside undetected. IBTimes Japan and SecurityWeek both note this was not a single smash and grab: multiple separate unauthorized accesses were confirmed across the period, with the first traced back to June 15.
Detection was, by the company's own account, incidental rather than the product of a security alert. The Japan Times reports that Aflac Japan officials noticed an abnormality on Thursday, June 25, when system load rose following a surge in access traffic. An investigation of that anomaly surfaced the intrusions. Defenders should sit with that detail: a capacity signal, not a detection control, is what ended the intrusion.
Containment followed quickly once the access was identified. Aflac blocked the unauthorized access on June 25 and suspended affected systems to prevent further spread. SecurityWeek, citing an FAQ published on Aflac Japan's website, reports that at least five customer-facing services were disrupted as a result, with no estimated restoration date at the time of publication. IBTimes Japan adds that claims for insurance proceeds and benefits continued to be handled through call centers and other channels while systems remained down.
The primary entry surface was "Aflac Yoriso Net" (rendered "Aflac Yorisou Net" in IBTimes Japan's transliteration), the company's customer-only policyholder portal, plus other connected systems. Aflac has consistently stated that the incident is confined to Aflac Japan and that U.S. business systems were neither affected nor accessed, a point repeated in the 8-K, in SecurityWeek's coverage, and in the StockTitan filing summary.
One minor discrepancy is worth flagging for the record. BleepingComputer's June 30 report describes the SEC filing as landing "on Monday," while SecurityWeek describes the announcement as coming "on Tuesday." June 30, 2026 was a Tuesday, and the filing text itself is dated June 30. The substance is unaffected.
What Was Taken
The exposed data set is broad and, for a supplemental insurer, unusually intimate. Across SecurityWeek, Security Affairs, the Japan Times, and IBTimes Japan, the confirmed categories include:
- Names, dates of birth, gender, addresses, and telephone numbers
- Policy numbers, coverage details, and insurance account information
- Security information (the phrasing used in Aflac's notice and carried by SecurityWeek and Security Affairs)
- Premium payment account information, specified by IBTimes Japan as financial institution name, branch name, account type, account number, and account holder name
The bank data subset is the sharpest edge. SecurityWeek, the Japan Times, IBTimes Japan, and Nikkei Asia all put it at approximately 230,000 people out of the 4.38 million total. SecurityWeek states explicitly that no credit card information was accessed.
There is a scope nuance in how the 4.38 million is described. SecurityWeek and Security Affairs both characterize the population as "customers and agents," and IBTimes Japan reports that leaked agency-related information includes agency representatives' names. Nikkei Asia and the Japan Times describe the figure simply as customers. Read the 4.38 million as a combined policyholder and agency-channel population rather than a pure retail customer count.
Aflac has been consistent that the exact mix of stolen data varies by individual, and that each affected person will receive a notification letter with specifics. The company also states that no misuse of the information has been confirmed to date. That is a status report on current visibility, not an all clear.
For context on proportion: Nikkei Asia reports Aflac holds a high market share in Japan for cancer and medical insurance, with 13.5 million policyholders in total. The 4.38 million figure therefore represents roughly a third of the company's Japanese book.
Why It Matters
Insurance data is a durable asset for an attacker in a way that payment card data is not. Card numbers get reissued in weeks. A name, date of birth, home address, phone number, bank account and branch, and the fact that a person holds cancer or medical coverage does not rotate. That combination supports high credibility social engineering against both the policyholder and their bank, and it supports it for years.
The bank detail exposure is the near-term risk. Japanese direct debit arrangements typically key on institution, branch, account number, and account holder name, exactly the fields IBTimes Japan lists as leaked. Nikkei Asia reports the disclosure has led to calls for policyholders to watch for suspicious transactions, and Japan's Financial Services Agency has ordered the insurer to report on the cause of the incident and its prevention measures. That is regulatory escalation beyond routine notification.
The recurrence angle deserves care. Tech Insider, an OTHER-tier source, frames this as the second major cyberattack on the Aflac corporate family in just over a year and refers to the company having spent the back half of 2025 explaining a breach of its U.S. operations. None of the higher-tier sources in this set corroborate the details of that earlier incident, so treat the specifics as unverified here. What the primary record does establish is that this June 2026 event is contained to Japan and that the U.S. environment was not touched, which suggests separate infrastructure rather than a single failure propagating across the group.
Finally, the detection story matters more than the breach story. Ten days of repeated, successful unauthorized access to a customer portal ended because a server got busy. Whatever monitoring stack sat in front of that portal did not raise the alarm on its own.
The Attack Technique
No source in this set identifies a threat actor, a malware family, an exploited CVE, or an initial access vector. No ransomware group has been publicly named, and none of the reporting describes an extortion demand. Anyone claiming attribution on this incident right now is ahead of the evidence.
What can be said from the record:
- Access was achieved against an internet-facing customer portal and spread to "other connected systems," per Aflac's own notice, which points to lateral movement from the portal rather than an isolated web application compromise.
- Access occurred multiple times across ten days, per IBTimes Japan and SecurityWeek, indicating either persistent access or a repeatedly reusable entry path rather than a one-time exploit.
- The activity generated enough traffic volume to raise system load noticeably, per the Japan Times, which is a pattern consistent with bulk automated data retrieval, whether through credential-based scraping, an authorization flaw permitting enumeration of records, or direct database access.
Aflac's investigation is ongoing with third-party cybersecurity experts engaged, and the 8-K states plainly that the full scope and potential impact have not yet been determined. Expect the technical picture to change.
What Organizations Should Do
- Instrument your customer portals for volume, not just for errors. The signal that caught this was load, and it was caught by operations rather than security. Set alerting on per-account and per-session record retrieval rates, on anomalous API pagination depth, and on authenticated sessions pulling volumes no human workflow would produce. Route those alerts to the security team.
- Assume subsidiaries are separate attack surfaces with separate maturity. Aflac's U.S. environment was untouched while its Japanese unit lost a third of its policyholder base. Segmentation limited the blast radius, which is a win, but it also means group-level security assurance did not reach the subsidiary. Audit regional units against the same detection and logging standard as headquarters, not just the same policy document.
- Treat stored bank routing data as a tiered asset. The 230,000 records containing institution, branch, account type, account number, and holder name are what turn this from an identity exposure into a fraud enablement event. Tokenize or vault direct debit details, restrict which application paths can read them in bulk, and log every bulk read.
- Rehearse the ten day question. Ask your team directly: if an authenticated actor pulled records from your main customer portal continuously for ten days, which control fires and on what day? If the honest answer is "we would probably notice the load," you have the same gap.
- Pre-build the regulator notification path. Aflac notified Japan's Financial Services Agency and the police, and the FSA responded with a formal order to report on cause and prevention. Know your equivalent obligations and timelines before the incident, including for every jurisdiction where a subsidiary operates.
- Plan for graceful degradation. At least five services went offline, per SecurityWeek, with no restoration estimate. Aflac kept claims and benefits processing running through call centers. Identify which customer functions must survive a full portal shutdown and test the manual fallback for them.
Sources: Aflac Data Breach: Japan Arm Hit for 4.38M in 2026 | Insurance giant Aflac discloses data breach after subsidiary hack | Aflac Japan Data Breach Impacts 4.38 Million - SecurityWeek | Hackers Steal Data of 4.38 Million Aflac Japan Customers | Aflac Japan reports breach on 4.38m customers, includes bank detail... | Aflac Japan reports data breach affecting over 4 million customers... | Aflac discloses Japan cyber breach with data exposure AFL 8-K Filing | Aflac Japan says breach exposed data of 4.38 million customers IBT...