TL;DR
- 01What happened
From around 10:00 JST on 9 October 2026, a third party accessed Sourcenext’s member-information system and retrieved registered data through a member-information API. On 15 October the company said up to 22,519,960 member records may have leaked. Possible fields include email address, password, name, address, phone number and date of birth. Credit card data was not held in the affected system.
- 02Why it was hard to tell
As far as the disclosures show, what was used was the API’s lawful function: returning member information. How authentication was passed and which vulnerability was used are not disclosed. About four days passed between the start of retrieval and confirmation.
- 03The missing layer
Once the access was confirmed, the response was quick. The company confirmed it around 09:00 on 13 October and completed containment by 13:36 that day. What did not work was a layer that checks, per call, whether a member-information API call stays within the right party, purpose and volume.
What happened
- System
- the system that manages member information, covering Sourcenext service members registered as of 13:36 on 13 October.
- Nature of access
- a third party retrieved registered data through a member-information API (official notice). The FAQ instead says “unauthorised access to servers the company manages” and does not mention an API. How authentication was passed and which vulnerability was used are not disclosed.
- Scale
- up to 22,519,960 records, a possible leak, not a confirmed count. Not every field exists for every member.
- Possible fields
- email address, password, name (including kana), address, gender, phone and fax numbers, date of birth, company name, job title, department, and system data such as subscribed services, registration date and last login.
- Not included
- credit card data (not held in the system).
- Not confirmed
- any misuse. How passwords were stored (hashed or not) is not disclosed.
Glossary
API — An interface through which systems exchange data. A member-information API returns a member's registered data when called.
Containment — Cutting off unauthorised access so the damage spreads no further.
Credential stuffing — Trying leaked email-and-password pairs on other services' logins.
The irreversible action was the retrieval at ②. No published account shows that, at each call, anyone checked who was calling, for what, and at what volume. How ① was reached is not disclosed either.
As far as the disclosures show. How it was reached is undisclosed.
Up to 22,519,960 records may have leaked.
Including blocking unauthorised external traffic.
Reported to the Personal Information Protection Commission.
Timeline — disclosure and response
- from about 10:00, unauthorised access began (as established later).
- at about 09:00, Sourcenext confirmed the access; contained by 13:36.
- announced; reported to the Personal Information Protection Commission; password resets required at login.
- police consulted (per the FAQ).
Facts here rest on Sourcenext’s official notice and FAQ. “Four days” is the difference between start (about 10:00 on 9 October) and confirmation (about 09:00 on 13 October); what triggered confirmation is not disclosed. An outside forensic investigation is under way, so the method, the vulnerability and the actual count may change. The company also disclosed a 2023 breach in which unauthorised access through a vulnerability in part of its site’s system led to tampering with a payment application, and personal data of about 120,000 people (including 112,132 credit-card records) may have leaked (official notice of 14 February 2023).
After disclosure
- Password invalidation: passwords within the leak’s scope are being invalidated in turn, with resets required at login (FAQ).
- Fix: the vulnerability in the affected system was fixed; other vulnerabilities are being checked.
- Notification: email to registered addresses and a dedicated contact line.
- Guidance: change reused passwords elsewhere and watch for spoofed email, SMS and calls.
Why it wasn’t stopped
The failure is not only that a third party reached the member-information API. As far as the disclosures show, a lawful function, returning member information, was used for about four days with no check of who was calling, for what, and at what volume.
That an API can return member data and that this call is permitted are different facts.
Once confirmed, the response was quick: the company contained the access the same day. But confirmation came about four days after retrieval began. What failed sits before that. That an API can return member data and that this call is permitted are different facts, and in what has been published nothing checks the latter directly before the call. A store of more than 20 million records stayed retrievable for about four days.
Proof works before a call executes; detection works after the access is noticed. Here, about four days lay between them.
No one has noticed yet
The distance between noticing unauthorised access and confirming that a call is permitted is what this Brief calls the gap between detection and proof.
The response, blocking, fixing, invalidating passwords and investigating, is necessary but works after retrieval. Invalidating passwords lowers the value of what was taken; it does not protect the moment of taking.
The same structure appears in earlier Briefs. In Denmark CPR, lawful access pulled about 8.8 million people’s data with no check of volume or purpose. In McHire/Paradox.ai, a recruiting AI’s API exposed 64 million records. In each, the retrieval route exists as a function, so no independent check sat directly before execution.
How to counter this
Even while the entry route is undisclosed, an organisation can decide, and check, whom an API returns data to, for what, and how much. An API that returns member data does exactly that once a call gets through. Decide who may call it and for what, cap how much it can return per call and per period, and stop retrievals beyond that before they run. Then, whatever the route, what can be taken stops at the cap, and you can say afterwards what was taken.
Industries and operations to watch
- IndustryServices & retail
- software and online-shop services that manage large numbers of members by email and password. The more members, the larger the impact of a leak.
- OperationLookup & data access
- work that pulls member data through APIs or admin screens. If getting through is all that decides how much a call can take, large retrievals pass as normal use of the function.
The same gap exists at most services with members. Many guard the API’s entrance, but few watch, as it happens, how many records a call that got through is taking, and for what.
Do today’s controls close it?
| Control | This case | Why |
|---|---|---|
| API authentication (caller keys and tokens) | Partly | It narrows who can call. How authentication was passed here is undisclosed, and it does not look at how many records a successful call takes. |
| Detecting and blocking the intrusion | Partly | Containment came the same day as confirmation, but confirmation came about four days after retrieval began, and what was taken in between is not recovered. |
| Invalidating and resetting passwords | Partly | It blocks logins with the stolen passwords, not on other services where the same password was reused. |
| Fixing the vulnerability | Partly | It blocks re-entry through this hole. It does not look at how many records a call arriving by another route takes. |
- Decide, at grant, who may call and for what, and record it. For each API that returns member data, decide who may pull which members and for what purpose, and keep that in a form each call can be checked against.
- Cap volume and targets, and stop retrievals beyond them before they run. Set how many records a call, and a period, may return, and which members may be targeted. Hold calls that exceed them until they are checked.
- Record whose data was taken, separately from the caller. Keep which permission each call relied on, and whose data was returned, as a record apart from the caller’s actions, so you can state the scope from your own records afterwards.
Three questions about APIs that return member data
- Can you list the APIs that return member data? For each, is it settled who calls it and for what?
- Is there a cap on how many records one call, and one day of calls, can return? When it is exceeded, who is told, and can retrieval be stopped?
- Can you state which members’ data was taken without relying on the caller’s own records?
Note: this still passes when a legitimate party misuses its access within range, or when data is taken a little at a time under the cap. Caps can also stop or delay legitimate bulk processing. The method and vulnerability used here are undisclosed; this Brief will be revised if a later report discloses them.
Sources
- primary, company noticeSourcenext “Apology and notice on customer information leak from unauthorised access to our site”
- primary, company FAQSourcenext “Frequently asked questions on the information leak”
- primary, company notice, earlier incidentSourcenext “Apology and notice on the 2023 personal-information leak”
Only the parties’ own official notices serve as primary here; no independent third-party verification or English-language outside reporting has been found. The method and vulnerability are undisclosed, and the notice (“member-information API”) and the FAQ (“unauthorised access to servers”) word the access differently. Japanese media and blogs are not used as sources.
References: why after-the-fact detection is not proof is covered in the last layer left in AI-era cyber defense. The pillar view is regulatory attribute proof.