One vulnerable component, sitting inside a single shared email platform, was enough to potentially expose the login credentials of over 12 million people across six internet providers that most of their own customers probably don’t realize share the same back-end infrastructure. That’s the shape of the KDDI breach: not six separate incidents, but one incident wearing six different customer-facing names.

TL;DR

  • KDDI, one of Japan’s three major telecoms, disclosed on June 23, 2026 that attackers exploited a zero-day vulnerability in unnamed third-party software running on its shared ISP email platform, with intrusion activity dating back to May 16, 2026.
  • The initial worst-case estimate was up to 14.22 million exposed email address/password combinations. KDDI’s confirmed July 6 figures are lower and split: 12,233,087 email addresses and 7,616,173 passwords.
  • Six ISP brands were affected — @nifty, BIGLOBE, J:COM, Commufa (Chubu Telecommunications), Pikara (STNet), and KDDI Web Communications (CPI) — but four of them are already KDDI Group companies or joint ventures; only two are genuinely independent customers of KDDI’s wholesale email infrastructure.
  • KDDI says some passwords were stored hashed or encrypted, but has not disclosed the algorithm, the proportion affected, or named the vulnerable software or a CVE — so the real account-takeover risk for any individual user can’t be calculated from public information.
  • No evidence has surfaced of names, physical addresses, phone numbers, or payment data being exposed, and no credibly sourced report of the stolen data appearing for sale confirms fraud tied to this breach as of this writing.

Why This Matters to You

If you’ve never heard of KDDI, that’s the point. Millions of people who use @nifty, BIGLOBE, or J:COM email addresses every day have no direct relationship with KDDI at all — they signed up with their cable provider, their regional utility’s ISP arm, or an internet plan sold under a completely different brand. This breach is a clean illustration of a problem that’s becoming the default shape of telecom and ISP risk: your provider’s security posture is only as strong as the shared infrastructure vendor sitting underneath a dozen brands you’ve never heard of, and a single unpatched (or unpatchable, in the zero-day case) component there can outrank every security decision your actual provider made.

Table of Contents

What Happened

According to KDDI’s own disclosures, the timeline runs like this:

May 16, 2026   — Unauthorized access begins, exploiting a vulnerability
                 in third-party software on KDDI's ISP email platform
June 1, 2026   — Nifty detects suspicious activity on its email
                 service and contacts KDDI
June 17, 2026  — KDDI confirms the intrusion and blocks attacker access
June 21, 2026  — KDDI deploys EDR tooling across external-facing
                 communication servers
June 23, 2026  — Public disclosure: up to 14.22 million email
                 address/password combinations potentially exposed
June 24, 2026  — Japan's Ministry of Internal Affairs and
                 Communications (MIC) issues a formal report order
July 6, 2026   — KDDI submits its report and publishes confirmed
                 figures: 12,233,087 email addresses and 7,616,173
                 passwords confirmed leaked

That gap between May 16 and June 17 — over a month — is the part worth sitting with. The intrusion wasn’t caught by KDDI’s own monitoring; it was flagged by one of the affected ISPs, Nifty, noticing something wrong on its own side first. That detail alone tells you the shared platform’s own telemetry wasn’t sufficient to surface the compromise on its own.

The 14.22 million figure was an initial worst-case estimate, not a final count — a point that most of the early English-language coverage repeated without noting it would likely be revised. By July 6, KDDI’s confirmed numbers came in lower and, importantly, split by data type rather than combined: not every one of the ~12.2 million people whose email address was exposed also had a password taken. That distinction matters for anyone trying to gauge their own actual exposure.

Six ISPs, One Platform: Who Actually Owns What

Most coverage of this breach described it simply as “six ISPs affected,” which flattens an important nuance: this isn’t six independent companies that happened to pick the same vendor. Based on Japanese corporate ownership records, four of the six brands are already inside the KDDI corporate family:

  • KDDI Web Communications (CPI rental-server email) — a direct KDDI subsidiary
  • BIGLOBE — a wholly owned KDDI subsidiary since KDDI’s 2017 acquisition (KDDI holds 100% of voting rights as of the most recent filing)
  • Chubu Telecommunications (Commufa Hikari / Business Commufa) — became a KDDI subsidiary in 2008, having originally been part of the Chubu Electric Power group
  • J:COM (J:COM NET and cable-provider email services) — a 50/50 joint venture between KDDI and Sumitomo Corporation

Only two of the six are genuinely external customers buying wholesale ISP email infrastructure from KDDI rather than being part of its corporate group:

  • Nifty (@nifty) — owned by electronics retailer Nojima, with no capital relationship to KDDI
  • STNet (Pikara Hikari / Pikara Mobile) — a wholly owned subsidiary of Shikoku Electric Power, one of Japan’s regional power-utility telecom arms

KDDI’s own au and UQ mobile carrier email services were not affected — they run on a separate platform. The practical picture, then, is less “an independent vendor’s platform failed six of its unrelated customers” and more “a platform KDDI operates for its own group brands, and rents out to a couple of others, had one component fail — and the rental customers got pulled into the same blast radius as KDDI’s own subsidiaries.” That’s arguably a more useful lesson for anyone evaluating shared-infrastructure risk than the flattened “six ISPs” headline suggests.

The Root Cause: An Unnamed Zero-Day

KDDI has stated that the intrusion exploited a vulnerability in third-party software installed as part of its ISP email system, and that as of its own discovery on June 17, the vulnerability was not yet known to the software’s vendor — meaning this was, by KDDI’s own account, a zero-day at the time of exploitation.

As of the most recent reporting available, KDDI has not disclosed:

  • The name of the third-party software or its vendor
  • A CVE identifier, if one has since been assigned
  • Technical detail on how the vulnerability was exploited (remote code execution, authentication bypass, injection, etc.)

The vendor is reportedly coordinating with public authorities on disclosure, but as of this writing no independent technical write-up, CVE entry, or vendor advisory tied to this specific incident has surfaced. This is worth flagging plainly: every characterization of “what vulnerability was exploited” beyond “an unnamed third-party software flaw” is currently unverifiable, not just under-reported.

Scope and Impact: What Was Actually Exposed

Confirmed by KDDI (as of July 6, 2026):

  • 12,233,087 email addresses
  • 7,616,173 passwords (a subset — not every exposed email address had an associated password taken)
  • Affected accounts include current customers, former customers, and inactive/dormant accounts
  • Passwords were, in KDDI’s words, stored in hashed and/or encrypted form for at least some accounts — but KDDI has not disclosed which algorithm(s), nor what proportion of the 7.6 million exposed passwords fall into which storage category

Not confirmed by any source reviewed for this article:

  • Names, physical addresses, phone numbers, or payment/billing information — no report reviewed claims these were exposed, and KDDI’s own disclosures describe the exposure as limited to email addresses and passwords
  • Plaintext password storage — this claim appears in a small number of lower-quality aggregator posts that could not be corroborated against KDDI’s own statements or against the more carefully sourced coverage (BleepingComputer, Security Affairs, and Japanese outlets including Nikkei and the piyolog security blog all describe passwords as hashed/encrypted, with the caveat that the specifics weren’t disclosed)
  • Any confirmed dark web forum listing, sale, or specific fraud case tied to this breach — one aggregator site referenced a “630GB / over 204,000 files” forum listing, but this figure did not trace back to a verifiable primary source and contradicts KDDI’s own more cautious hashed/encrypted characterization, so it is treated here as unverified and excluded from the confirmed record

The honest summary: this is a large, real credential exposure with a genuinely uncertain severity ceiling, because the one variable that determines actual account-takeover risk — how the passwords were stored, and for what fraction of the 7.6 million — has not been disclosed.

KDDI’s Response and the Regulatory Fallout

KDDI’s response timeline shows containment happening within hours of confirmation: attacker access was blocked the same day the intrusion was confirmed (June 17), EDR tooling was deployed across external-facing servers four days later, and a third-party forensic firm was engaged before the public disclosure on June 23. KDDI has stated it is contacting affected users and prompting password resets for confirmed-affected accounts.

On the regulatory side, two Japanese bodies are involved, consistent with Japan’s legal requirements for data breach notification:

  • Japan’s Personal Information Protection Commission (PIPC) was notified, as required under the Act on the Protection of Personal Information for a breach of this scale.
  • The Ministry of Internal Affairs and Communications (MIC), which regulates telecom carriers, issued a formal report order (報告徴収) on June 24, requiring KDDI to detail the cause, scope, response measures, and prevention plan by July 6 — a deadline KDDI met with its confirmed-figures disclosure.

MIC has indicated it may pursue further administrative action depending on its evaluation of KDDI’s report, up to and including formal administrative guidance or a business improvement order — but as of this writing, no such further action has been confirmed publicly. Comparisons drawn by some Japanese commentators to a 2025 incident involving IIJ (which reportedly escalated to administrative guidance after a similar report order) are analytical speculation about a possible precedent, not a confirmed regulatory outcome for KDDI, and should be read as such.

MITRE ATT&CK Mapping

TacticTechniqueID
Initial AccessExploit Public-Facing ApplicationT1190
Credential AccessUnsecured CredentialsT1552
CollectionData from Information RepositoriesT1213
ExfiltrationExfiltration Over Web ServiceT1567

What You Can Do Today

  1. If you use @nifty, BIGLOBE, J:COM mail, Commufa, Pikara, or a KDDI Web Communications (CPI)-hosted mailbox, change your password now, even without an official notification in hand. KDDI’s per-account notifications are still rolling out, and a password change costs you nothing while an active exposure window does not.
  2. Check whether that same password is reused anywhere else — especially banking, e-commerce, or other email accounts. The real risk of this breach isn’t the ISP mailbox itself; it’s every other account that shares the same password, since credential-stuffing bots will test exposed pairs across unrelated services within hours of any real leak.
  3. Move to a password manager and unique, generated passwords for every account, starting with email. Email is the de facto password-reset hub for everything else you own online; a compromised email password is rarely just an email problem.
  4. Enable two-factor authentication on your ISP email account if the provider offers it, and on any downstream account that used the same password. TOTP or a security key beats SMS-based codes, but any second factor stops a bare credential-stuffing attempt cold.
  5. Watch for phishing that references this breach specifically. Breach disclosures of this size reliably attract follow-on phishing campaigns impersonating the affected provider (“verify your account” links); treat unsolicited “security alert” emails from these providers with the same suspicion as the original attack.
  6. If you run infrastructure that a third-party vendor’s software touches — especially anything customer-facing or internet-exposed — treat “unnamed third-party software” incidents like this one as a prompt to inventory your own dependencies, not just KDDI’s. The month-long gap between exploitation (May 16) and detection (June 17) happened despite KDDI running its own monitoring; detection came from a downstream customer noticing something wrong first. If your incident response plan assumes your vendor will catch it before you do, this is the case study that says otherwise.
  7. Organizations operating shared, multi-tenant infrastructure for downstream customers should assume a compromise of that shared layer is a compromise of every tenant simultaneously, and plan incident communication accordingly — KDDI’s six affected brands had to coordinate a joint disclosure across four subsidiaries and two external customers, which is a harder problem to solve during an active incident than before one.

Sources