NTT Docomo My docomo breach: 294,839 lines' data

An attacker took customer data for up to 294,839 NTT Docomo lines through My docomo and the Docomo Online Shop on 4 November 2026, and Docomo says no password was cracked and no bug was exploited. The way in was a d account, Docomo's customer login. From there, the attacker abused how several internal systems pass a request to one another, and used that to search for and pull customer records in bulk, including the numbers of customers' identity documents. Docomo's monitoring raised its first alert three and a half hours after the probing began. Docomo reopened My docomo that evening, then shut it again after midnight when its own checks pointed to a leak. This analysis starts with what leaked, then sets out the timeline, how Docomo says the attack worked, and what other organisations should change.

What is affected, and what is not

Status as of Docomo's third report (6 November, 18:00) and its press conference the same evening, as reported.

Item	Status	What is known
Customer data for up to 294,839 lines	Affected (confirmed)	204,157 personal and 90,682 business lines, including customers who have cancelled and users of the online shop. For everyone affected: name, date of birth and age; address, phone number and email; the number of the identity document they showed; mobile number and contract start date; and plan, options and discounts.
Extra data for some customers	Affected (confirmed)	Names and contacts of legal guardians or agents; employer or company name and address; bank name, branch, account number and account holder; and details of a child-support programme.
My Number	Not stored, per Docomo	Docomo says it does not keep images of My Number cards, so they were not part of the leak.
Card numbers	Not listed	Docomo's notices do not list card numbers among the leaked data.
Contents of communications	Not leaked, per Docomo	Docomo says no information protected by the secrecy of communications leaked.
Logins	Not bypassed, per Docomo	Two-step verification and passkeys worked as designed; the attack did not break authentication.
Services	Stopped	My docomo and the Docomo Online Shop have been in emergency maintenance since 01:05 on 5 November, with no restart date. The ahamo site was stopped as a precaution and reopened on 8 November.

If you are a Docomo customer, expect messages that use these details to look convincing. Docomo is notifying affected individuals by SMS and post, and business customers through their sales contacts. Do not open links or attachments in messages about the incident, and do not give passwords or personal details. Check through Docomo's own channels instead: its special line for this incident is 0120-451-360 (9:00 to 20:00).

How it unfolded

Figure 1. Original graphic built from Docomo's notices and reports of its 6 November press conference. Times are Japan time.

The timeline has three moments worth dwelling on:

The slow start. Docomo found later in its logs that probing had begun at about 07:00, below the level that triggers an alert. The first alert came at 10:30 and was about load: a flood of requests straining the systems.
The block that did not work. At 14:30 Docomo blocked access from overseas IP addresses, and it had no effect. Whatever the attacker used, it was not only foreign addresses.
The reopening. After blocking the route at 18:10, Docomo reopened My docomo at 20:32, judging it safe under its existing recovery rules. Checks it was running in parallel then raised fears of a leak, and it shut both services at 01:05. The leak was confirmed at 02:10. Docomo says it will revise its recovery rules and IT governance.

How Docomo says the attack worked

Docomo explained the method at its press conference without naming the systems involved:

The entry was a d account. Authentication, including two-step verification and passkeys, worked normally. Docomo has not said whose account it was or how the attacker got it.
The attacker abused linked systems. When My docomo receives a request, several internal systems and functions work together to process it. The attacker used that chain to search for and retrieve customer information "mechanically", in bulk.
The data was protected, except where it was read. Customer data was encrypted or masked in storage and between systems. The protection was removed at the stage where one system interprets the data, and that is where the attacker took it.

Docomo's chief information security officer called it a combination "we had not thought of". Regular vulnerability assessments had not found the route. Docomo describes it as an abuse of how the systems were connected, not a bug in any one system, and has avoided saying whether it counts as a vulnerability. It also said this was not an API attack. It has blocked the route and similar routes. Whether AI agents were used is being examined, and Docomo has not named an attacker.

The attacker's view

Step	ATT&CK	What Docomo describes
Get in with a real account	T1078 Valid Accounts	Entry through a d account. If it was the attacker's own account, nothing was stolen to get in at all.
Stay under the alarm	No single technique	Probing from about 07:00, below the alert threshold, three and a half hours before the first alert.
Chain internal functions to reach other customers' data	T1213 Data from Information Repositories	Linked systems abused to search customer records; protection removed where the data is interpreted.
Harvest in bulk	T1119 Automated Collection	Customer data "mechanically searched and retrieved" for up to 294,839 lines.
Survive the obvious block	No single technique	Blocking overseas IP addresses at 14:30 had no effect.

What makes this case instructive is what the attacker did not need: no cracked password, no malware, no known vulnerability. Every request may have looked like a customer using the site. The weakness was in what the combined system allowed one account to see.

The defender's view

Alert on what an account takes, not only on how fast it asks. The first alert here was about load. Count how many different customers' records one account or session touches, and alert well before that number reaches the thousands. Outside accounts built to manage many lines, such as business accounts, one login should rarely touch more than a handful of customers' data.
Do not treat blocking foreign addresses as containment. It may cut noise, but here it had no effect. Attackers can route through domestic connections. Block the route or the account instead, as Docomo did at 18:10.
Reopen only when a leak has been ruled out. Docomo reopened under its existing recovery rules while leak checks were still running, then had to shut again. Write the reopening criteria before an incident: the route is closed, logs back to the first probe have been reviewed, and the people checking for a leak agree.
Enforce access where data becomes readable. Encryption at rest and in transit did not help at the point where a system decrypted data to work with it. Check the caller's right to see each customer's record there, and return only the fields the task needs. Bulk access to ID-document numbers and bank details should be impossible from one customer login.
Test the chain, not just the parts. Docomo's assessments tested systems, and the route lay in how they combined. Include abuse cases across linked systems in testing: "as one logged-in customer, can I reach another customer's data by any path?"

Our risk model treats this kind of design weakness as a recurring shock, and our guide to API leaks covers the same rule, checking each record against the caller, even though Docomo says this was not an API attack.

Team	Action	Done when
IT Operations	Map which portal functions can return other customers' data, and through which internal systems	Every path is listed with the check that guards it
SIEM	Add an alert on distinct customer records read per account or session	The rule is live and tested with a replay
Legal / Privacy	Prepare notices and reporting for a leak that includes ID-document numbers and bank details	Templates and the reporting path are agreed

Also on 6 November: a separate matter

On the same day as the press conference, Japan's Ministry of Internal Affairs and Communications gave Docomo written administrative guidance over a different problem. Docomo had passed contract details of about 340,000 users of a particular plan to Amazon Japan without valid consent. That case is not part of this breach.

What remains unknown

How the attacker got the d account, and whether it was their own or someone else's.
Which systems were chained, and what exactly removed the data's protection.
Which identity documents' numbers leaked. Docomo has not said, citing privacy.
Whether AI agents were used, and who the attacker is.
When My docomo and the online shop will reopen, and the amount and terms of the compensation Docomo is considering.

Sources and updates

9 November 2026: first published. Figures and times come from Docomo's notices and from reports of its 6 November press conference; we confirmed each in at least two of them. CNET Japan's report of the conference could not be opened by our fetcher, so we relied on the others; piyolog's summary helped us find them. Docomo's notices do not mention card numbers, so we say only that. We will update this analysis when Docomo publishes its next report or restarts the services.

NTT Docomo: 294,839 lines' customer data taken through My docomo, by abusing how its systems work together

30-second briefing