Security Guides
How 2026 Breaches in Japan Got In: More Through Valid Credentials Than Vulnerabilities (A Cross-Case Analysis)
Line up the incidents disclosed in Japan in August 2026 and more of them started from valid credentials than from exploited vulnerabilities — a vendor's Microsoft 365, a BI tool, mailboxes, GitHub credentials, a provider's own console. Classified by entry path, with what to do about the part patching cannot prevent.
Who this is for: anyone responsible for a company's or their own site's security. This is not a per-incident write-up; it is the pattern that appears when you line up what Japanese organisations disclosed in August 2026. Every fact comes from those disclosures and from reporting; no inference about cause.
Classified by entry path
Based on what each organisation published; figures and causes only as disclosed.
| Disclosed | Organisation | Where it started | Class |
|---|---|---|---|
| 3 Aug | Kodansha | Corporate mailbox — contacts stolen, and mail impersonating that employee was sent to some of them | Credential |
| 4 & 7 Aug | Innovation Co. | GitHub credentials — the company disclosed two failures: tokens hard-coded in configuration, and personal data stored in repositories | Credential |
| 13 Aug | Charm | Unauthorised access to the e-commerce site (~230,000 records, including password hashes) | Direct |
| 14 Aug | Nichirei | Ransomware (system failure on 13 July; employee data possibly exposed) | Direct |
| 17 & 19 Aug | Sakura Internet | The provider's management environment, then the contract-management system (up to 1,360,563 member accounts in scope) | Credential / provider |
| 20 Aug | Expo 2025 Association | A subcontractor's Microsoft 365, starting from a phishing email received on 13 May | Credential / vendor |
| 20 Aug | VOISING | A BI tool (up to ~170,000 people) | Credential / SaaS |
| Aug | JST (reported) | Mailbox access (~16,000 messages) | Credential |
| 12 Aug | OCS, ANA Group (reported) | A vulnerability in the application | Direct |
How to read these numbers
The counts above are as published at the time, and most investigations are ongoing. In particular, Sakura Internet's 1,360,563 is the number of member records potentially in scope, not a confirmed leak — the company states no exfiltration has been confirmed. Not treating an under-investigation figure as final is the basic skill for reading coverage like this.
Why securing your own systems is not enough
Start: a legitimate account outside your control
a vendor's M365 / a BI tool / a mailbox / a GitHub token / a provider's console
The attacker performs ordinary actions
signs in normally with the stolen credential and reads data normally
Your server (untouched)
patches, WAF and CSP do not apply to this path
An exploited vulnerability means someone got in through a flaw, so fixing the flaw stops it. A stolen credential means someone signed in normally, so there is no flaw to fix. What needs protecting is the credential itself: who holds it, where it is stored, and how long it stays valid.
What does not work here
- Patching — irrelevant to an attack that exploits nothing
- WAF / IPS — a legitimate login does not look anomalous
- "We are too small to target" — the target was a vendor or provider, and you were affected as their customer
- Changing hosting model — a VPS does not stop credential theft
What does
- Multi-factor authentication, especially on mail, code hosting and SaaS admin
- Short-lived, narrowly scoped credentials — retire long-lived tokens
- An inventory of vendors and SaaS that can reach your data
- No secrets hard-coded in config; no personal data in repositories
- Planning on the assumption it was read — reduce what is there to take
What to do
List the outside services and subcontractors you depend on
Hosting, SaaS, BI tools, mail platform, code hosting — and subcontractors. Without that list you cannot even answer "are we in scope?" when the news breaks. How to build one: the asset inventory checklist.
Put multi-factor authentication on mail and code hosting first
Several of the starting points above were mailboxes and code-hosting credentials. Both are accounts from which everything else can be reissued, so they rank above the rest. → choosing multi-factor authentication
Inventory long-lived credentials and shorten their lifetime and scope
Secrets in config files, access tokens with no expiry, keys valid across every repository. Assume theft, and make what a thief gets small and short-lived. → what is dangerous about .env and API keys / stopping secrets at commit time
Work out in advance what happens if your provider is breached
When the notice arrives saying your provider was compromised, what do you actually lose? Answering that in advance decides what you do on the day. → what to do when your web host is breached
Assume opportunistic phishing follows
Large incidents are always followed by mail impersonating them. In one August case it was disclosed that mail impersonating the employee was sent to the stolen contacts. Do not click links in an "incident notification" email; open the official site yourself. → what phishing is
This site's view: this is not a big-company story
The table lists large organisations, but the places it started have nothing to do with size: a mailbox, SaaS admin rights, credentials left in a repository. It is identical for a solo developer, and arguably worse, because a small operation depends more on external services and one credential tends to give access to more. Our position is consistent: right now, not handing out credentials more widely than needed, and not leaving them in place unused, does more than trying to make systems impossible to break into. Keep patching as a baseline, and shift your focus toward credentials.
Sources
Facts come from each organisation's disclosure and from reporting. No attribution of cause or responsibility beyond what was published.
- Sakura Internet — first report (17 Aug) / second report (19 Aug, updated 26 Aug) / FAQ
- Expo 2025 Association — report on unauthorised access at a subcontractor (20 Aug)
- Kodansha — notice on personal data exposure (3 Aug)
- Charm — notice on unauthorised access (13 Aug)
- Innovation Co. — final report on the GitHub incident (7 Aug)
- Reporting on Nichirei — @IT (15 Aug)
- Reporting on VOISING — ITmedia NEWS (21 Aug)
Read next
- All 2026 incidents (Japan and worldwide): list of breaches and cyberattacks, and how the way in differs
- Comparing 2026's major cases: what KDDI, Aflac, the Digital Agency and Sakura Internet have in common
- When the VPN is the way in: VPN appliances are the main way in for ransomware: remote access defense after the Digital Agency breach
- Preparation: the asset inventory checklist / choosing multi-factor authentication
- When the provider is breached: what to do when your web host is compromised
- Credential theft: when a single npm install steals your credentials / what is dangerous about .env and API keys
- Design: password reset design flaws — where a service's own reset process issues credentials to an attacker
- Case: the KADOKAWA ransomware (2024) — credentials stolen by phishing as the entry point
FAQ
QWhat was the most common entry path in 2026?
Classifying the major incidents disclosed in Japan during August 2026 by what each organisation published, more of them began with valid credentials or accounts than with an exploited software vulnerability: a subcontractor's Microsoft 365 account, a BI tool, corporate mailboxes, GitHub credentials, and a service provider's own management environment.
QDoes patching prevent this?
Not this class. An intrusion that uses valid credentials may not touch a single vulnerability. Patching remains necessary against a different class of attack, but credential-led intrusion needs its own controls: credential lifetime and scope, multi-factor authentication, and an inventory of the vendors and SaaS that can reach your data. Either one alone is not enough.
QCan we be affected without being attacked directly?
Yes. Among the August 2026 cases, one began with a phishing email received by a subcontractor and put the commissioning organisation's contacts at risk, and another was a compromise inside a hosting provider that affected its customers. In both, the customer's own servers were untouched. That is why an inventory of 'the outside things I depend on' is part of your defence.
QDoes this apply to individuals and small teams?
It does — arguably more so, because smaller operations depend more on external services and one credential tends to give access to a wider area. The same month included a case whose starting point was credentials hard-coded into configuration files. What separates outcomes is not size but where credentials live and who can use them.