Security Guides
In 2026 the Breaches Came Through Valid Credentials, Not Vulnerabilities — A Cross-Case Read
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 where patching cannot reach.
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 hardening your own castle does not stop it
Start: a legitimate door outside you
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 are all off this path
An exploited vulnerability means someone broke in, so fixing it closes the way. A stolen credential means someone walked in with a key — there is no hole to close. What needs protecting is not a hole but the key: who holds it, where it sits, 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; you are collateral
- 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 doors that are outside you
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 doors from which everything else can be reissued, so they rank above the rest. → choosing multi-factor authentication
Inventory long-lived credentials and cut 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
Rehearse the case where the provider is the one 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. Treat the "incident notification" email as the one you never click — go to 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 are size-independent — a mailbox, SaaS admin rights, credentials left in a repository. It is identical for a solo developer, and arguably worse, because a small operation leans harder on external services and one credential tends to unlock more. Our position is consistent: right now, "do not hand out and leave keys lying around" buys more than "make it unbreakable". Keep patching as a baseline, and move the centre of gravity.
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
- 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 one npm install empties your credentials / what is dangerous about .env and API keys
- 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 leaves a hole.
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 lean harder on external services and one credential tends to unlock 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.