Japan’s second-largest mobile carrier spent 52 days containing a breach before telling anyone about it. On July 7, 2026, KDDI Corporation confirmed that attackers had exploited a zero-day flaw in third-party software to reach a shared email platform used by six internet service providers, exposing roughly 12.2 million email addresses and 7.6 million passwords. Nearly a week later, the vendor behind the flawed software still hasn’t been named. No CVE number has been issued. No security firm has pinned the intrusion on a known threat actor.
That mix of scale and mystery has turned the KDDI data breach into one of the most closely watched cybersecurity stories of the summer. It lands in a market already on edge about telecom security after Salt Typhoon’s multi-year run through American carriers, and it raises a question that keeps recurring in 2026: when one vendor’s code sits inside six companies’ infrastructure, whose breach is it really?
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Happened Inside KDDI’s Email Platform
KDDI runs shared email infrastructure that serves more than its own subscribers. Five other Japanese internet providers, STNet, JCOM, Chubu Telecommunications, NIFTY Corporation and BIGLOBE, route customer email through the same backend. That setup is common in Japan’s telecom sector, where smaller ISPs lease infrastructure from larger carriers instead of building redundant systems from scratch. It’s efficient. It’s also, as KDDI learned this year, a single point of failure.
By KDDI’s own account, an attacker exploited a zero-day vulnerability in third-party software connected to that shared email system starting May 16, 2026. The company says it discovered the intrusion and cut off the attacker’s access on June 17, more than a month later. A forensic audit on June 23 confirmed the exploited flaw had been closed. KDDI then spent close to two more weeks preparing a formal report for Japan’s Ministry of Internal Affairs and Communications, filed it on July 6, and went public the next day.
A 52-Day Gap: The Timeline From Exploit to Disclosure
The gap between exploitation and public disclosure is one of the more debated details of the incident. Attackers sat inside the platform for roughly a month before KDDI’s security team caught them, then the company took another three weeks to confirm the fix and prepare its disclosure. For a carrier with about 45,000 employees and roughly $32.4 billion in annual revenue, that pace fits Japan’s typical breach-reporting pattern, but it runs slower than what US regulators now expect. The SEC’s cyber disclosure rule generally pushes American public companies toward reporting material incidents within four business days. Japan has no equivalent hard deadline tied to a specific clock for private-sector breach notification.
| Date (2026) | Event |
|---|---|
| May 16 | Attacker exploits zero-day in third-party email platform software |
| June 17 | KDDI discovers intrusion and blocks attacker’s access |
| June 23 | Forensic audit confirms exploited vulnerability has been patched |
| June 28 | KDDI reports no secondary damage, such as fraud or identity theft, identified so far |
| July 6 | KDDI files detailed incident report with Ministry of Internal Affairs and Communications |
| July 7 | KDDI discloses breach publicly, ministry comments at press briefing |
| July 9 | Security trade press widely reports the incident internationally |
The Numbers: 12.2 Million Emails, 7.6 Million Passwords
KDDI’s own figures are specific enough to feel almost clinical: 12,233,087 email addresses and 7,616,173 passwords accessed without authorization. The company says the affected platform serves up to 14.22 million accounts in total once former and inactive users are counted, which marks the outer limit of how bad this could look if more dormant accounts turn out to be compromised too.
What Was Exposed, and What Wasn’t
Password protection was inconsistent across the platform. Some accounts had passwords stored in hashed or encrypted form. Others, KDDI has acknowledged, may have been stored in a way that left them readable if accessed directly, though the company hasn’t published the exact split between the two groups. That detail matters more than the headline number. A properly salted, hashed password is expensive for an attacker to crack at scale. A plaintext or weakly protected one is not. KDDI has said payment card data and its My Number national ID equivalents were not stored on the breached platform, which limits the immediate fraud risk even as the phishing risk from exposed addresses climbs.
Six ISPs, One Shared Vendor Platform
Count KDDI itself, and six internet providers in Japan now have customers whose email credentials were exposed: KDDI, STNet, JCOM, Chubu Telecommunications, NIFTY Corporation and BIGLOBE. None of the other five built the vulnerable system. They inherited the risk by plugging into KDDI’s shared email backend, an arrangement that lets smaller providers skip the cost of running their own mail infrastructure.
That’s the uncomfortable lesson for enterprise security teams everywhere, not just in Japan. When five companies rely on a sixth for a core service, one unpatched dependency inside that shared platform becomes five companies’ incident at once. None of STNet, JCOM, Chubu Telecommunications, NIFTY or BIGLOBE had any control over the vulnerable code. All five still had to activate their own customer notification and password-reset processes.
Why There’s Still No CVE or Vendor Name
Nearly a week after disclosure, three basic facts about the KDDI data breach remain undisclosed: which vendor wrote the flawed software, what that software actually does, and whether the flaw has a CVE identifier at all. KDDI describes it only as “third-party software” integrated into its email platform. Researchers tracking the incident say that’s unusual for a breach of this size, though not unheard of in Japan, where vendor-disclosure norms differ from the US habit of naming affected software in CISA advisories or vendor bulletins.
The silence could mean a few things. The vendor may still be building a patch and asked KDDI to hold off naming it until a fix ships more broadly, a common courtesy in coordinated disclosure. It could also mean the software runs widely enough that naming it would tip off other companies running the same stack before they’ve checked their own exposure. SecurityWeek reported the vendor was still “developing a patch” as of its July 9 report, which points toward the second explanation.
Whatever the reason, the missing CVE number complicates life for every other company that might run the same software. Without a CVE, there’s no entry to search in the National Vulnerability Database, no CVSS score to prioritize against, and no automated way for vulnerability scanners to flag exposure. That’s a real cost of delayed disclosure, and it’s a cost paid by everyone who isn’t KDDI.
No Attribution: Investigators Rule Out the Usual Suspects
Attribution has moved slower than the technical fix. As of this writing, no security firm or government agency has linked the KDDI breach to a known threat actor. That stands out given how many regional attacks in 2025 and 2026 got attributed within days to established groups such as Salt Typhoon, the China-linked group that spent 2024 and 2025 burrowing into telecom networks worldwide, or financially motivated crews like ShinyHunters.
The lack of attribution leaves two possibilities open. Either the attacker took unusual care to avoid the tool reuse and infrastructure overlap that usually gives away a group’s identity, or investigators know more than they’ve said publicly and are holding attribution back for operational reasons. Analysts tracking the case have pointed to MITRE’s ATT&CK framework technique T1190, exploiting a public-facing application, as the closest technical classification for how the attacker likely got in. That’s a category, not a name.
For KDDI’s customers, attribution matters less than the practical fallout. For the wider security industry, an unattributed zero-day against critical telecom infrastructure is the kind of gap that tends to get filled eventually, sometimes months later, once a patch gets reverse-engineered or a second victim turns up using the same technique.
Inside KDDI’s Response: EDR, Forensics and Mass Password Resets
KDDI’s remediation followed a fairly standard incident-response playbook, run at telecom scale. The company deployed Endpoint Detection and Response software across the affected environment to catch any renewed attempts. It ran the forensic audit that closed out on June 23, confirming the exploited vulnerability had been shut. And it began enforcing mandatory password resets for active users within days of disclosure, with a rolling one-to-two-day window for less frequent users tied to each ISP’s own notification schedule.
KDDI has also said it’s using AI-assisted tools to review software design specifications across its infrastructure, hunting for similar classes of vulnerability before an attacker finds them elsewhere in the stack. That detail is worth watching. A growing share of large breach responses in 2026 now include some version of AI-driven code or spec review as a stated remediation step, reflecting how much cheaper that scanning has become in the past two years. Whether it actually catches the next zero-day is a claim nobody can verify until it either works or doesn’t.
As of KDDI’s most recent update, the company says it has found no evidence of secondary damage, meaning no confirmed cases of financial fraud or identity theft tied to the exposed credentials. That’s a meaningful data point, but it’s also early. Credential-based fraud from a breach like this one often shows up in stages, as attackers or the buyers of leaked data test accounts for reuse across banking, retail and social logins in the weeks after a breach goes public. Exposed address lists like this one are also a known feeder for phishing campaigns, a risk Google highlighted directly in its own lawsuit against an AI-driven phishing ring earlier this year.
Regulators Step In: Japan’s Communications Ministry Responds
KDDI notified two Japanese regulators once the scope of the breach became clear: the Personal Information Protection Commission and the Ministry of Internal Affairs and Communications. The ministry’s involvement matters because it oversees telecom licensing in Japan, giving it leverage well beyond what a typical data-protection regulator can claim.
At a July 7 press briefing, the ministry acknowledged the breach as a serious matter affecting a large number of users and said it was reviewing KDDI’s incident report alongside the company’s remediation plan. Japan doesn’t currently write a US-style mandatory 72-hour disclosure clock into law for telecom operators, though the ministry has pushed carriers toward faster voluntary reporting since KDDI’s 2022 network outage drew sharp political criticism over the pace of the company’s public communication.
That history explains why this breach is being watched so closely inside Japan’s regulatory apparatus. A second major KDDI incident within four years, even one of a completely different kind, raises the sort of pattern-recognition questions that tend to produce new rules rather than just fines.
History Repeats: KDDI’s 2022 Network Collapse vs. Today’s Breach
KDDI has been here before, in spirit if not in substance. In July 2022, a botched core router replacement triggered a cascading network failure that knocked out voice and data service for an estimated 39.15 million mobile connections, about 72% of the company’s contracts, for 72 straight hours. That outage disrupted emergency calls, banking systems and logistics networks across Japan and forced KDDI to pay compensation to affected subscribers.
The 2022 incident and the 2026 breach are different animals. One was an availability failure caused by an internal technical mistake. The other is a confidentiality failure caused by an external attacker exploiting someone else’s code. Both expose the same underlying reality, though: KDDI sits deep enough inside Japan’s digital infrastructure that when something goes wrong, whether from a bad configuration change or a zero-day exploit, the blast radius reaches tens of millions of people who may not even know they’re KDDI customers, because they signed up with STNet or BIGLOBE instead.
Market and Financial Impact
As of July 10, 2026, KDDI’s stock hasn’t shown the sharp drop that sometimes follows a breach disclosure at a public company. Analysts covering the stock have stayed cautious rather than alarmed, largely because the exposed data, email addresses and passwords, is less immediately monetizable than payment card numbers or the My Number identifiers that tend to move markets after a Japanese breach.
That muted reaction doesn’t make the breach free. KDDI will absorb the cost of the EDR rollout, the forensic audit, the password-reset infrastructure and whatever support services it eventually offers customers across all six brands. Class-action-style claims are less common in Japan than in the US, but fines under Japan’s Act on the Protection of Personal Information remain a live possibility once the Personal Information Protection Commission finishes its review.
The bigger financial risk may be reputational and contractual. STNet, JCOM, Chubu Telecommunications, NIFTY and BIGLOBE now have a business reason to renegotiate or diversify away from a shared infrastructure arrangement that just exposed their combined customer bases to a vulnerability none of them controlled. If even one of those five partners moves its email infrastructure in-house or to a different vendor, that’s a direct hit to KDDI’s wholesale business.
How KDDI Stacks Up Against AT&T, Verizon and Salt Typhoon
Telecom breaches aren’t rare in 2025 and 2026, but they vary widely in method and motive. Comparing the KDDI data breach against the biggest recent telecom security failures in the US puts its scale in perspective and shows how differently these stories unfold depending on the attacker’s goal.
Salt Typhoon and AT&T: The US Comparison
Salt Typhoon, the China-linked group tied to a wave of US telecom intrusions, hit at least nine American carriers, including AT&T, Verizon, Lumen Technologies and T-Mobile, according to congressional and trade-press reporting. By August 2025, the FBI said the group’s reach extended to roughly 200 companies across 80 countries, a scope built for long-term espionage rather than one-time data theft. AT&T’s separate 2025 exposure involved 86 million customer records, including nearly 44 million Social Security numbers decrypted and posted to dark web forums, though that data mostly traced back to breaches first disclosed in 2024.
KDDI’s breach looks different from both. It isn’t tied to state-sponsored espionage like Salt Typhoon, at least not yet, and it isn’t a repackaging of older stolen data like AT&T’s 2025 exposure. It’s a single zero-day in one piece of shared software, hitting six companies’ customers in one disclosed event. That combination, contained scope but wide blast radius, may turn out to be a more common failure mode for the rest of 2026 than either a years-long espionage campaign or old data resurfacing on a forum.
| Incident | Year | Companies Affected | Scale | Attribution |
|---|---|---|---|---|
| KDDI email platform breach | 2026 | 6 (KDDI, STNet, JCOM, Chubu Telecommunications, NIFTY, BIGLOBE) | ~12.2M emails, ~7.6M passwords | None confirmed |
| Salt Typhoon campaign | 2024-2025 | 200+ globally, 9+ in the US including AT&T, Verizon, Lumen, T-Mobile | Undisclosed total, call records and network metadata | China-linked, state-sponsored |
| AT&T dark web leak | 2025 (sourced from 2024 breaches) | 1 (AT&T) | 86 million records, ~44M SSNs decrypted | Unattributed reseller |
| KDDI network outage | 2022 | 1 (KDDI) | 39.15 million mobile connections, 86-hour outage | Not an attack, internal misconfiguration |
The Third-Party Software Problem Nobody Fixes
Strip away the Japan-specific details and the KDDI data breach fits a pattern that has defined enterprise security for three straight years: the weakest link usually isn’t the company whose name ends up in the headline. It’s a vendor two or three steps removed that nobody outside the security team had heard of. MOVEit, SolarWinds, the open-source package compromises that hit AI tooling supply chains earlier in 2026, and now an unnamed piece of software sitting inside KDDI’s email platform. The names change. The shape of the problem doesn’t.
What makes this pattern hard to fix isn’t awareness. Security teams already know third-party risk is real. It’s economics. Auditing every vendor’s code to the same standard a company applies to its own software is slow and expensive, and most companies can’t do it for the hundreds of vendors touching their infrastructure. KDDI’s answer, using AI tools to scan software design specs for risky patterns, is one attempt at making that audit cheaper. Whether it actually catches the next zero-day before an attacker does is a claim that can’t be verified until it either works or doesn’t.
For US enterprises watching this story, the practical takeaway isn’t really about KDDI. It’s a prompt to check which vendors sit inside shared infrastructure, email platforms, identity providers, customer support tools, and ask the same question KDDI’s five ISP partners are presumably asking right now: what happens to us if our vendor gets breached and we had no say in their code?
What This Means for US and Global Telecom Security
The KDDI data breach lands at a moment when US regulators and lawmakers are already on edge about telecom security. Salt Typhoon prompted congressional hearings, a CISA advisory pushing carriers toward encrypted communications, and renewed talk of mandatory security baselines for critical telecom infrastructure. A separate, unattributed zero-day breach in Japan carries no direct regulatory weight in the US, but it adds to a growing case file that shared telecom infrastructure, wherever it sits, is now a standing target.
Expect this story to feed into ongoing debates in Washington and Brussels over whether telecom operators should face the same mandatory vendor-disclosure and software bill of materials requirements already reaching federal software procurement. The core argument gets easier to make with every new incident: if a telecom carrier can’t say which vendors touch its shared infrastructure, regulators increasingly want to make them find out.
For everyday users, the practical advice is familiar and still under-followed. Change reused passwords, turn on multi-factor authentication anywhere it’s offered, and treat any unexpected password-reset email as a phishing risk until verified directly through the provider’s app rather than a link in the message.
Predictions: Where the KDDI Story Goes Next
Based on how similar breaches have played out over the past two years, here’s how the KDDI data breach is likely to develop over the coming months.
- A vendor name and CVE surface within weeks. Coordinated disclosure timelines for third-party zero-days typically resolve once a patch ships broadly. Expect the unnamed vendor to be identified by late July or August 2026, likely through independent researcher analysis rather than a KDDI announcement.
- Phishing attempts targeting the 12.2 million exposed addresses spike. Even without payment data, a confirmed-active list of email addresses tied to a specific breach is valuable for targeted phishing. Expect a rise in KDDI-, STNet- and BIGLOBE-themed phishing campaigns through the rest of 2026.
- Japan’s regulators tighten shared-infrastructure oversight. Between this breach and the 2022 outage, KDDI has triggered two major regulatory reviews in four years. Expect the Ministry of Internal Affairs and Communications to propose guidance on vendor risk management for shared telecom platforms.
- At least one partner ISP announces an infrastructure change. STNet, JCOM, Chubu Telecommunications, NIFTY or BIGLOBE renegotiating their reliance on KDDI’s shared email platform, or moving it in-house, is a realistic outcome given the reputational exposure they took on with zero control over the vulnerable code.
- The breach becomes a reference case in the vendor-risk debate. Expect security conference talks and analyst notes to cite KDDI alongside Salt Typhoon and MOVEit as evidence that shared third-party software remains the industry’s most persistent unsolved problem.
Related Coverage
- Novo Nordisk Breach: $25M Ransom, 1.3TB Claimed [2026]
- Foxconn Cyberattack: Nitrogen Steals 8TB, 11M Files [2026]
- FortiBleed Cracks 86,644 Fortinet Firewalls [2026]
- Google Sues AI Phishing Ring Tied to $1.9B in Losses [2026]
- North Korea Poisons 140 npm AI Packages in 19 Min [2026]
- New CitrixBleed Flaw: NetScaler Hit in 24 Hours [2026]
- The Gentlemen Ransomware: 483 Victims, 90% Cut [2026]
For ongoing coverage of breaches, ransomware and zero-day disclosures, see Tech Insider’s cybersecurity section.
Frequently Asked Questions
What is the KDDI data breach?
The KDDI data breach is a 2026 cybersecurity incident in which attackers exploited a zero-day vulnerability in third-party software to access a shared email platform used by KDDI and five partner internet providers: STNet, JCOM, Chubu Telecommunications, NIFTY Corporation and BIGLOBE. KDDI disclosed the breach on July 7, 2026, confirming that roughly 12.2 million email addresses and 7.6 million passwords were accessed without authorization.
When did the KDDI breach happen?
The attacker first exploited the vulnerability on May 16, 2026. KDDI discovered the intrusion and blocked the attacker’s access on June 17, 2026, then confirmed a fix after a forensic audit on June 23, 2026. The company disclosed the breach publicly on July 7, 2026.
How many people were affected by the KDDI breach?
KDDI confirmed 12,233,087 email addresses and 7,616,173 passwords were compromised. The shared platform serves up to 14.22 million accounts in total once former and inactive users are included, which represents the outer limit of potential exposure rather than a confirmed count.
Was my data exposed if I don’t use KDDI directly?
Possibly. Customers of five other Japanese providers that share KDDI’s email infrastructure, STNet, JCOM, Chubu Telecommunications, NIFTY Corporation and BIGLOBE, were also affected, even though none of those companies use the KDDI brand name for their own subscribers.
Who is behind the KDDI breach?
No threat actor has been publicly attributed as of July 10, 2026. Researchers have not linked the attack to known groups such as Salt Typhoon or ShinyHunters, and KDDI has not named the vendor whose software contained the exploited zero-day.
Has KDDI released a CVE number for the vulnerability?
No. As of this writing, no CVE identifier or vendor name has been published for the exploited zero-day, which researchers say is unusual for a breach of this scale.
What should affected users do?
KDDI and its partner ISPs are enforcing mandatory password resets for affected accounts. Security experts recommend changing reused passwords immediately, enabling multi-factor authentication where available, and treating unsolicited password-reset emails with caution, since exposed address lists are commonly used to fuel follow-up phishing campaigns.
How does this compare to other 2026 telecom breaches?
The KDDI breach is smaller in scope than Salt Typhoon’s multi-year campaign against global telecom networks, which the FBI says touched over 200 companies across 80 countries, but it’s a distinct type of incident: a single zero-day in shared vendor software rather than a sustained espionage operation.
