On 15 October 2026, Japanese software company Sourcenext announced that a third party had gained unauthorized access to the system that manages its member information. The company says up to 22,519,960 records may have been exposed. Credit card data is not stored in that system, according to the company.
The details below come from Sourcenext's notice as reported by Impress Watch and ASCII.jp, and from NHK coverage. We could not load the company's own page ourselves, so company statements are attributed to those reports. Times are Japan Standard Time.
What happened
Per the reports, the timeline is:
- 9 October, around 10:00: unauthorized access began, as found in the later investigation.
- 13 October, around 09:00: Sourcenext confirmed the access.
- 13 October, by 13:36: the company says it completed containment.
- 15 October: the company announced the incident and says it completed its report to Japan's Personal Information Protection Commission.
- 16 October (planned): a damage report to local police.
The stated cause is misuse of a member information retrieval API. Reports say the underlying vulnerability was fixed right after discovery, and that its nature has not been made public.
What data may be involved
The company lists email address and password, name, address, gender, phone and fax numbers, birth date, company name, job title, department, and system identifiers such as subscribed services, registration date and login date. Not every member has every field. The notice does not say how passwords were stored, so we do not know whether they were hashed.
Confirmed, reported, unknown
- Confirmed by the company (as reported): the dates above, the API misuse, the data fields, the regulator report, forced password resets and an external forensic investigation.
- Reported by third parties only: one outlet calls it the second largest leak by record count in Japan. We could not confirm that from a primary source.
- Unknown: who was behind it, how many records were actually taken versus potentially exposed, how the API authorization failed, and the password storage method.
Why it matters
The access ran for roughly four days before it was noticed. An API that returns member records in bulk without strong per caller limits is a data export tool for whoever finds it. Rate limits, volume alerts and object level authorization checks are the usual controls here, though Sourcenext has not said which was missing.
What to do now
- If you have a Sourcenext account, reset the password and change it anywhere you reused it.
- Treat email and SMS that mention Sourcenext as suspect. The company warns of phishing that impersonates it.
- For your own APIs, list every endpoint that returns personal data and check that each one authorizes per record, not just per login.
- Alert on unusual read volume per token or account, and set a hard cap on records per request and per hour.
- Store passwords with a slow salted hash such as Argon2id or bcrypt.
How this could have been avoided
- Object level authorization on the retrieval API. A member lookup should only return data the caller is entitled to.
- Per caller rate limits and volume alerts. Four days of bulk reads should have tripped a threshold.
- API inventory. Unknown or forgotten endpoints are where this class of bug lives. Free in-browser checks such as the Safeguard dependency scan cover libraries, not logic flaws, so pair them with API testing.
- Data minimization. Keeping job title, fax and birth date for every member enlarges what leaks.
Quick check
Does the notice say passwords were stolen in plain text?
No. It says passwords may be among the exposed fields. The storage method has not been stated in the reports we read.
