SourceNext API Breach Turns 22.5 Million Records Into Password Risk

Japanese software vendor SourceNext says a third party abused a member-information retrieval API from about 10:00 on October 9 until the company contained the access at 13:36 on October 13. The potentially exposed population is 22,519,960 records. Depending on each registration, fields may include an email address, password, name, address, phone and fax numbers, date of birth, employer details, job title, department, subscribed services, registration date, and login date.

The disclosure does not say whether passwords were plaintext, encrypted, or stored as password hashes, and it does not publish the vulnerability class or the number of unique people. That uncertainty is a reason for precise containment, not speculation. SourceNext has reset affected passwords, says it fixed the system weakness, and is notifying users. Customers should reset through a directly opened official site, replace any reused password beginning with the associated email account, enable stronger authentication where available, and expect phishing that combines the leaked identity fields with knowledge of SourceNext products.

SourceNext's October 15 notice says unauthorized access began at about 10:00 on October 9. The company detected access to the system that manages member information at about 09:00 on October 13, blocked the external source, and completed containment by 13:36. It says monitoring has not found further unauthorized access after that response.

The company attributes the data retrieval to improper use of a member-information API. That is more specific than a generic server breach, but it is not a complete root-cause account. SourceNext has not said whether the actor bypassed authentication, stole a credential, exploited an authorization flaw, reached a legacy endpoint, or combined several weaknesses. It also has not published request volumes, source infrastructure, or a forensic timeline of each field accessed.

The FAQ says the underlying system vulnerability has been fixed, leaked passwords have been reset, and the service is currently safe to use. It also says a search for other weaknesses has begun and an independent security investigation is being prepared. Those steps support containment, but the public record remains an interim disclosure until the cause, access scope, and control changes are documented in more detail.

SourceNext gives a maximum affected count of 22,519,960 records. It does not describe that number as 22.5 million verified unique people, and it does not explain whether one customer can appear more than once across products or historical registrations. Reporting should preserve the company's unit: records potentially affected.

The possible fields are extensive: email address, password, name in standard and kana forms, postal address, sex, telephone and fax numbers, date of birth, company, job title, department, and system-specific identifiers such as subscribed service, registration date, and login date. SourceNext explicitly says the list combines every possible field and that actual fields vary with each customer's registration.

This distinction affects response. A user with only an email address and account password exposed faces a different fraud pattern from a business customer whose company, title, department, phone number, product subscriptions, and login history may be linked. Notifications should identify the individual's actual exposed fields when the investigation can support that precision.

SourceNext lists passwords among the potentially exposed fields and is forcing resets. It does not say whether those values were plaintext, reversibly encrypted, or represented by hashes, nor does it identify a hash function, salt strategy, or work factor. It would be inaccurate to convert that silence into a claim that the company stored readable passwords.

The correct user posture is still to retire the old password. A salted, slow password hash can resist offline guessing better than a fast or unsalted hash, but the user cannot assess that protection from the notice. SourceNext's reset protects the SourceNext account only. If the same email and password combination was used elsewhere, those other services will continue to accept it until each password is changed.

Start with the email account tied to SourceNext because email often controls password recovery for everything else. Then change any reused credential on financial, shopping, cloud, social, and work systems, using a different generated password for every service. Enable multifactor authentication or passkeys where supported, review recent sessions and security alerts, and avoid entering a replacement password through a link in an unexpected message.

SourceNext says credit-card information was not stored in the affected system and was not part of the leak. Its purchase guide says card data is entered directly on a payment processor's site rather than held by SourceNext. On the present evidence, customers do not need to replace a payment card solely because of this incident, and the company's FAQ says a card stop or reissue is unnecessary for that reason.

A separate support notice says personal information associated with Super Security for Business, including contract or purchase accounts and product accounts, was not leaked in this event. That does not clear every SourceNext service or every field for every person. It establishes one documented exclusion that administrators of that product can preserve while they assess whether staff also held ordinary SourceNext member accounts.

These boundaries are operationally useful. Incident response should distinguish the compromised membership system, the external payment processor, product-specific account stores, and the devices where SourceNext software runs. The current notice supports a member-data and credential response. It does not support a claim that payment cards, installed applications, update channels, or customer endpoints were compromised.

An email address alone supports broad spam. The disclosed combination can support messages that look like account, license, subscription, billing, support, or workplace notices. A phisher may know a customer's name, company, department, product subscription, registration date, or recent login date and use those correct details to make a false request feel routine.

SourceNext warns about suspicious email, SMS, phone calls, and postal mail. Users should open the known official site or app independently, not follow a breach-themed reset link. A caller who knows a date of birth or product name has demonstrated access to data, not authority. Do not provide a one-time code, install remote-support software, approve an MFA prompt, move funds, or disclose a new password in response to an inbound contact.

Organizations should brief help desks and finance teams about the exact exposed field types. Watch for password-spraying and credential-stuffing attempts against staff email, VPN, SaaS, and consumer accounts. Where a work address or employer field was registered, correlate authentication failures and reset requests beginning October 9 without assuming that every event shares the same cause.

The largest unanswered questions are technical: the vulnerability class, how the API was reached, what authorization checks failed, whether credentials were involved, the actual query and response history, the password-storage format, the count of unique people, and whether the actor obtained every returned record or only a subset. SourceNext also has not reported a threat actor, ransom demand, public data posting, or confirmed downstream account abuse.

A useful final report would separate verified extraction from potential exposure, publish the investigation window and log coverage, explain how duplicates were counted, describe authentication and authorization changes, and state how sessions, API credentials, and customer passwords were invalidated. It should also explain why detection occurred after several days of API use and what rate, volume, or behavior monitoring now covers the retrieval path.

For other service operators, the immediate lesson is concrete: inventory every API that can return membership data, enforce object- and field-level authorization, limit bulk retrieval, alert on unusual enumeration and export volume, minimize retained profile fields, store passwords with a modern salted password hashing scheme, and keep payment data outside general account stores. The data a service never collects or cannot bulk-return is data an attacker cannot extract through one membership endpoint.