Nikkei: stolen credentials expose 1.83 million records

Nikkei Inc., the Japanese business and financial news group that publishes the Nikkei newspaper and the Financial Times, has disclosed a new data breach: using previously stolen credentials, someone entered a cloud service used for system development and accessed about 1.83 million records. According to BleepingComputer, this is the third security incident the company has disclosed in about a month.

What happened

According to the notice published by Nikkei, as reported by BleepingComputer, SecurityWeek and Security Affairs, the unauthorized access took place in the early morning of 7 October 2026. The attackers used login credentials that had already been compromised; the company revoked them after discovering the access and on 11 October notified the breach to the Personal Information Protection Commission, Japan’s data protection authority.

The sources describe the affected system slightly differently: for SecurityWeek and Security Affairs, which quote the notice, it is a cloud service Nikkei uses for system development; for BleepingComputer, it is a development system within the company’s network, through which personal data stored in the cloud was exposed. Nikkei has not said which service it is, nor how the credentials were stolen.

Data involved

According to the notice, as of 16 October about 1.83 million items of personal information are involved:

• about 150,000 contain at least one of the following: name, email address, postal address, phone number, date of birth;
• of these, about 120,000 include an email address;
• about 1.68 million contain only information that, on its own, cannot identify a person;
• no record contains credit card data.

As of 16 October, Nikkei says it has found no evidence that the data has been misused or, according to BleepingComputer, published online; there have been no service outages and no changes to the data. The investigation into the scope and cause of the incident is still ongoing, and the people involved will be notified individually.

Previous incidents

According to BleepingComputer, in early October Nikkei had already disclosed a breach that occurred in late July: an employee’s Google Workspace account had been compromised, giving access to personal data of employees and business partners. In September, the company reported that another employee’s Microsoft 365 account had been used to send spear-phishing emails to staff. SecurityWeek and Security Affairs also recall a breach that started from a compromised Slack account, disclosed, according to Security Affairs, in November 2025.

Nikkei has not said whether the credentials used on 7 October came from one of the earlier incidents: based on public information, no link can be established.

Technical details

There are no CVEs and no malware: entry was gained with valid credentials. Based on what is known, the pattern fits the MITRE ATT&CK techniques Valid Accounts: Cloud Accounts (T1078.004) and, for data collection, Data from Cloud Storage (T1530). No indicators of compromise have been published.

The point that matters to system administrators is where the incident happened: a development environment holding real personal data, 1.83 million records. Development and test environments often have weaker controls than production (shared accounts, long-lived keys, less monitoring), yet they can hold copies of the same data.

Impact for European and Italian companies

Under the GDPR, personal data in development environments is treated like production data: it requires the same security measures (Art. 32) and data protection by design (Art. 25), meaning minimal, pseudonymised or synthetic data. Unauthorized access to that data is a breach to be assessed for notification to the supervisory authority within 72 hours.

For NIS2 entities (in Italy, Legislative Decree 138/2024), access management, multi-factor authentication and security in system development are among the required risk management measures.

There is also an indirect risk: 120,000 email addresses linked to names and contact details enable convincing phishing in the name of Nikkei or the Financial Times, including against employees of European subscriber companies.

What to do now

1. Take stock of development and test environments in the cloud: which services, who has access, what data they hold. Treat repositories, test databases and object storage the same way.
2. Remove real personal data from development environments: use synthetic or masked data; where real data is needed, keep only the minimum, with an expiry date and deletion.
3. Protect access as you would in production: corporate single sign-on, phishing-resistant multi-factor authentication (FIDO2 or passkeys), no shared accounts, short-lived API keys and tokens.
4. After any compromised account, rotate everything it could see: passwords, tokens, keys and secrets stored in email, chat and documents, not just the password of the affected account.
5. Bring cloud logs into monitoring: logins from new countries or devices, off-hours access, bulk data exports, new access keys.
6. Look for company credentials exposed in breaches and on stolen-credential markets, and disable the ones you find.

How ARXDOME helps

ARX Expose flags company accounts exposed in known breaches, so compromised credentials can be disabled before anyone uses them. ARX Sentry collects logs and events from computers, servers and firewalls and groups them into families such as failed logins, explicit credential use and account changes. ARX Retain keeps the logs so that, during an investigation, you can reconstruct who had access and when.

Last updated: 20 October 2026