KDDI Corporation disclosed on June 23 that attackers exploited a vulnerability in third-party software to breach the centralized email platform it operates for six Japanese internet service providers, putting credentials belonging to up to 14.22 million accounts at risk.
The company detected unauthorized access on June 17 and cut off the attackers the same day. KDDI notified Japan's Personal Information Protection Commission and the Ministry of Internal Affairs and Communications immediately. BleepingComputer reported that affected providers include NIFTY, BIGLOBE, J:COM, STNet, Commufa, and KDDI Web Communications, all of which run their email services on KDDI's shared backend. Email addresses and passwords were potentially obtained. KDDI confirmed that passwords were stored in hashed or encrypted form, though the company did not specify the algorithm used or what proportion of credentials may have been stored in a weaker form.
The 14.22 million figure covers current subscribers, former customers, and dormant accounts. The specific third-party software component was not named in KDDI's public disclosures. KDDI urged all affected users to change their email passwords immediately. SecurityAffairs noted that the attack maps to MITRE ATT&CK technique T1190, exploiting a public-facing application.
Two things are worth pulling out of the reporting.
What scanners would have missed
The entry point was a vulnerability in a vendor-supplied component running inside KDDI's shared email platform. That creates a specific blind spot for conventional security tooling.
SAST scans your source code. It does not scan the third-party software your vendor ships. DAST probes your own web application endpoints. It does not test the internal platform components a managed-service provider runs on your behalf. When the vulnerable software is something the ISP partners never wrote and cannot inspect, neither scan type touches it.
There is a second problem: scope. A CVSS score on the underlying vulnerability would not have conveyed what the blast radius actually was. A medium-severity finding in an email server library means one thing when it affects a single organization's inbox. It means something different when the same library is the authentication backend for six ISPs sharing a common platform. Severity scores are computed against the vulnerability in isolation. They do not model multi-tenant scope.
The structural gap here is familiar. Managed email services, hosted identity platforms, and outsourced communication infrastructure all create the same situation: multiple organizations sit behind a shared technical layer, and security responsibility for that layer is ambiguous. The ISPs assumed KDDI secured it. KDDI operated third-party software it did not develop.
A scanner pointed at any of the six ISPs would have found nothing wrong. The vulnerability did not live in their systems.
What Sekura would have shown
Sekura's recon phase builds the full attack surface before dynamic testing begins. For an organization like KDDI, that means including the infrastructure it operates on behalf of others.
Recon would have identified that the same email backend serves six separate ISP domains. It would have fingerprinted the third-party software components in that shared layer. And it would have computed the combined scope: a finding in the shared authentication layer is not a finding against one ISP, it is a finding against all six.
That scope calculation changes how findings are triaged. Here is how the output of recon flows into exploit-chain analysis for a case like this:
- Shared platform confirmed: six tenants, single authentication backend.
- Third-party email server software identified and version-pinned.
- Known vulnerability class detected in the public-facing authentication handler.
- Combined exposed scope: 14.2 million accounts across all tenants.
- Priority elevated above single-tenant findings with higher individual CVSS scores.
Phase 3, dynamic probing, would then target the email platform's authentication endpoints specifically. The resulting report would not assign a CVSS score to the finding in isolation. It would show a working proof of access together with the recon-derived tenant scope, so the finding's real weight is legible without interpretation.
I think this is the core difference between score and proof. The score lives inside the vulnerability. The proof, paired with the recon scope, shows what an attacker can actually do with it.
The bigger pattern
This is a shared-infrastructure breach. One flaw in one platform component simultaneously exposed credentials at six separate organizations. The ISPs did not each get breached. The centralized platform got breached, and the consolidation multiplied the blast radius without any additional attacker effort.
This pattern repeats across managed services. Hosted email, cloud identity providers, SaaS payment processors, outsourced HR platforms: all create the same structure, where many organizations depend on a single shared technical layer that may fall outside any individual tenant's security scope.
Assessments tend to stay inside the customer's perimeter. Attackers work on the asset's actual architecture.
If you want to see how proof-first recon maps the full blast radius on your own infrastructure, compare what Sekura finds versus what scanners report.