Lessons From the 22.5 Million-Record Sourcenext Breach: Protecting Member Data APIs

Hello, this is Ryuta Hamamoto from TIMEWELL.

On 15 October 2026, Japanese software company Sourcenext announced that unauthorized access to its member information system may have exposed up to 22,519,960 records. Names, addresses and phone numbers are included, and so are passwords. Many people who run member-facing services will read this as something that could happen to them.

This article separates what has been disclosed from what is still unknown. It then sets out what operators of APIs that handle member data should review, and how to act if a breach occurs, using OWASP and Japan's Personal Information Protection Commission as references. It is not a search for anyone's fault. It uses the facts that the company chose to disclose to think about what we should prepare.

What has been disclosed, and what is still unknown

Here is what can be confirmed from Sourcenext's official notice and FAQ.¹²

Item	What has been disclosed
Start of unauthorized access	Around 10:00 on Friday, 9 October 2026 (found by later investigation)
Method	Obtained member data by misusing the member information retrieval API
Confirmed	Around 09:00 on Tuesday, 13 October
Containment	Completed by 13:36 on Tuesday, 13 October
Announced	Thursday, 15 October
Report to the Personal Information Protection Commission	Completed on 15 October
Police	Consultation planned for 16 October
Number of records	22,519,960 (records that "may have been" exposed)
Scope	Customers registered up to 13:36 on 13 October
Fields	Email address, password, name, name in kana, address, gender, phone number, fax number, date of birth, company name, job title, department, and identifiers such as services subscribed, registration date and last login (not every field for every person)
Credit card data	Not held in the affected system and not part of the exposure
Response for users	All passwords invalidated; resetting requested; users asked to change reused passwords on other services

From the start of the unauthorized access to confirmation, about four days passed: it began around 10:00 on 9 October and was confirmed around 09:00 on 13 October.

Meanwhile, the notice and FAQ do not say the following.

• Where in the API the weakness was, and what it was. The FAQ says "the vulnerability in the system that caused this has been fixed," but gives no specifics.²
• How passwords were stored (whether hashed, and with what method).
• What happened during the roughly four days between the start and the confirmation.
• Whether individual products and services, such as Pocketalk, are covered. Both the notice and the FAQ describe the scope as "customers with a registered account" and name no products. The surest way to know whether you are affected is the individual notice email being sent out.

For prevention, the company lists an emergency review of all systems, a detailed investigation with external specialists, continued monitoring for unauthorized access, and a fundamental review of its security measures, monitoring and information management. The details and timing of specific measures are not given.¹

So what we can say now is this: an API that returns member data was misused, about four days passed between the start and the confirmation, and a large amount of data may have been taken. Why it happened has to wait for further disclosure.

Where member data APIs commonly fail: in general terms

From here on, this is general background, not a guess at the cause of this incident. The OWASP API Security Top 10 (2023 edition) groups common API weaknesses into ten items. These are the ones that relate to an API returning member data.³

• API1 Broken Object Level Authorization: a handler that takes an ID from the user does not check enough, so another person's data can be reached
• API2 Broken Authentication: a flaw in authentication lets an attacker steal tokens or impersonate other users
• API3 Broken Object Property Level Authorization: fields that should not be returned are returned, or values that should not be changed can be changed
• API4 Unrestricted Resource Consumption: there is no limit on how often or how much can be retrieved, so data can be pulled out in bulk
• API5 Broken Function Level Authorization: the line between administrative and ordinary functions is blurry, and functions that should be off limits can be reached
• API6 Unrestricted Access to Sensitive Business Flows: there is no protection against excessive automated use
• API9 Improper Inventory Management: old versions and test APIs stay exposed because nobody has taken inventory

If you think about the situations in which an API returning member data gets misused, every one of these can be relevant. Which of them applies here has not been disclosed.

Six items for operators to review

Here are six places where an operator of a member data API can look.

1. List the APIs that return member data.

What OWASP calls API9 is a lack of inventory.³ Write down the APIs that return member data: public ones, internal ones, and old versions. Then check each one: who calls it, and for what purpose? An API with no caller is safest closed.

2. Check on the server side whose data may go to whom.

Authentication (who you are) and authorization (what you may do) are different things. Check that, in every route that returns member data, the rules "only the logged-in person's own data is returned" and "administrative functions can be called only by administrators" are enforced. Missing checks of this kind are what API1, API3 and API5 point at.³ Hiding a button on a screen is not a check.

3. Return only the fields that are needed, and store less.

Does a member data API really need to return name, address, phone number, date of birth and password together? Limiting the response to what the screen needs changes the size of the damage if the API is breached. Fields that never need to be returned, like a password, should be left out of the response by design.

The same applies to what you store. Decide how long you keep fax numbers you do not use, or data on members who have left. This overlaps with the thinking about identity documents in our earlier piece, Lessons from Japan's 2026 Breaches (Part 1).

4. Detect and stop bulk retrieval.

What stands out in this disclosure is the scale, 22.5 million. In normal use, one member never retrieves millions of member records. What OWASP lists under API4 and API6 is the lack of limits on how often or how much can be retrieved, and the lack of protection against bulk automated use.³

Set a ceiling on the number of records retrieved per account, per IP and per token. If a large retrieval happens in a short time, stop it automatically and notify someone. Without a defined range of "normal," anomalies do not stand out.

5. Keep logs, and watch them.

About four days passed between the start of the unauthorized access and its confirmation. To shorten that gap, you need API access logs and a way to watch totals and destinations for anomalies. The things to watch are the number of calls to APIs that return member data, how many records are returned at once, and access at unusual times or from unusual places. Logging alone is not enough. Decide who receives the alert and within how many minutes they act.

6. Check how passwords are stored.

In this case, the way passwords were stored is not described in either the notice or the FAQ. As general background, OWASP's Password Storage Cheat Sheet forbids plaintext storage and names Argon2id as the first choice (a minimum guide is 19 MiB of memory, two iterations and parallelism of one). It says fast hashes such as SHA-256 or MD5 are unsuitable for storing passwords.⁴

Check which method your own passwords use. If it is an old one, you can upgrade hashes to a newer method as users log in.

What to do when it happens

However well you prepare, risk does not go to zero. Deciding in advance how to act affects how far the damage spreads. Here are three things to take from this disclosure.

The decision to invalidate every password. Sourcenext says it has invalidated the passwords of all members.¹ At the same time, the password reset site has been busy, and users have been asked to wait before trying. Asking everyone to reset is effective. But whether the system can cope when millions of people come at once cannot be known unless you test it beforehand. Testing the load on the reset flow in advance is worth doing.

Reporting to the Personal Information Protection Commission. The Commission names four types of incident that must be reported: those involving sensitive personal information, those with a risk of financial harm, those with a risk of malicious intent, and those affecting more than 1,000 people. When one applies, you file a preliminary report promptly, generally within about three to five days as a guide, and a final report within 30 days (60 days where malicious intent is suspected).⁵ Sourcenext confirmed the incident on 13 October and filed its report on 15 October, which is within that guide, two days after confirmation.

The wording of the notice to users. A notice should cover four things: what happened, which information is affected, what users should do, and where to ask questions. Besides asking for a password reset, Sourcenext asks users to change reused passwords on other services as well.¹ When passwords may have leaked, harm to the person's other services is the main source of secondary damage. Prepare to include that sentence in your own notices.

What to tell users and staff

Apart from notices to your members, tell your own staff the same things.

Many employees register with outside services using their company email address. If a leak happens at one of those services and the password is reused, it can chain into your internal systems. Do not reuse a company account's password elsewhere. Use a password manager. Turn on multi-factor authentication. Writing these three into internal rules reduces the impact when another company has a breach.

After a leak is announced, fraudulent emails that imitate the company that announced it can arrive. Sourcenext also asks people not to open links in emails or SMS messages they do not recognize.¹ Remind staff of the rule: check official announcements through the company's own site.

Summary

What the Sourcenext case lets us confirm is this: an API that returns member data was misused, about four days passed between the start and the confirmation, and up to about 22.52 million records may have been taken. The substance of the cause has not yet been disclosed.

Even so, the items an operator with a member data API should review are clear. An inventory of APIs, server-side authorization, narrowing the fields returned, detection of bulk retrieval, log monitoring, and the way passwords are stored. And the steps for reporting and notifying when it happens.

I think the biggest difference comes from the time to detection. You cannot make defense perfect, but you can shorten, by design, the time it takes to notice something is wrong. This week, start by listing the APIs that return member data. If you want to talk through internal reviews or training, please reach out through the consultation form for WARP SECURITY.

References

Footnotes

1. Apology and notice regarding customer information leakage through unauthorized access to our site (Japanese) — Sourcenext — 15 October 2026 ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Frequently asked questions about the information leak (Japanese) — Sourcenext — 15 October 2026 ↩ ↩²

3. OWASP API Security Top 10 2023 — OWASP ↩ ↩² ↩³ ↩⁴

4. Password Storage Cheat Sheet — OWASP Cheat Sheet Series ↩

5. Responding to leaks and useful materials (Japanese) — Personal Information Protection Commission ↩