When you buy from a small shop, your email lives in the platform behind it, and no one will tell you which shop leaked it. That is the ShopServe story: E-store's final report on 16 October puts the breach at about 23,356,000 people across 7,858 shops. I run AliasFleet, an email-alias service giving each site its own forwarding address, so a leak names its source.
Picture the checkout: a shop you like, a name you trust, a page that looks like theirs. Your details flow into ShopServe, the system behind the shop's orders, memberships, and mailings. One flaw there put thousands of shops' customers into a single file, and neither the shop nor the notice can tell you which shop your data came through.
The August number was never the final number
The 2 August second report counted 8,853,839 records. October counts about 23,356,000 people. Set those two figures side by side and they look like a correction. They are not the same kind of number.
August counted records, so one buyer registered twice counted twice. October counts people, after E-store tried to merge duplicates by matching records, across a wider confirmed scope. The outside forensic investigation ran from August into October, and the confirmed scope grew as it went, which is where the rest of the gap comes from: counting people instead of records explains part of it, finding more damage explains the rest.
That is the normal shape of breach news: the first figure describes what the company could see in week one, while the last describes what months of digging turned up. If you bought from a ShopServe shop and wrote the breach off in August, October is the report to act on.
What the final report settles
The final report is E-store's own notice, published 16 October: E-store final report. The same evening brought coverage from Asahi Shimbun, NHK, and TV Asahi (ANN). No screenshot of the notice is embedded: it is a Japanese-language page and a real, tightly cropped capture was not obtainable in this pipeline.
| Settled | Still open |
|---|---|
| The disclosure: final report on 16 October 2026, after first reports on 1 and 2 August | Which application or flaw the attacker used, and how they found it |
| The window: 21 May to 1 August 2026; attacker traffic cut off on 1 August, with nothing getting through after that | When inside that window data first left, and how much left in each stretch |
| The method: an attacker used an application flaw on E-store servers, ran a malicious program, and pushed stored database records out | Who ran it; no attribution offered |
| The scale: about 23,356,000 people, across 7,858 shops past and present | Which shops, store by store; no per-shop list exists |
| No second way in found, no backdoor program found | Whether the file appears in public later |
| No confirmed concrete secondary harm as of the final report; forensic work found no dark-web outflow as of publication | Whether harm shows up later; both are as-of findings |
The people total covers buyers, shop operators, and affiliates together. E-store matched records to collapse duplicates where it could. The total stays approximate, because duplicates that fell short of the matching bar could not be stripped out.
What left the building, and what did not
The file reads like a checkout drawer tipped onto the floor.
Buyer and delivery records: names, addresses, phone numbers, fax numbers, email addresses, workplaces, plus whatever the buyer typed into free-form boxes. Anything typed into an extra field at checkout sits in the file too.
Member records, email-magazine subscribers included: member IDs and encrypted passwords. E-store's view is that working out the passwords is unlikely, and that the file holds nothing tying a login to a particular store, so it rates misuse and unauthorised member-page entry unlikely for now. Treat that as the company's reading, not a promise.
Partial card records, about 2,096,900 people: cardholder name, first 6 and last 4 digits, expiry date. E-store never stored full card numbers or security codes, so those were never in the file. On its own, the partial set cannot finish a payment, but that misses the point: the first 6 digits name the card issuer, and the last 4, plus a name and an expiry, let a stranger sound like your card company on the phone. Partial card data is a prop for impersonation, not a way to pay, and impersonation is how it gets used.
And one item from August got cleared, which almost never happens. The second August report listed store mail-system logins, FTP logins, and bank transfer account details as leaked, but the final investigation says those items were not leaked, and E-store struck them from the leak scope. If August coverage left you worrying about a shop's FTP login, the final report says that part did not happen.
E-store says it will never ask for card details to be typed in again, a fresh payment, or a password by email or SMS over this incident. A message asking for any of those is not from E-store, however much of your real data it quotes back at you.
The part that should worry shop owners
Store and affiliate records deserve their own section, because the notice goes quiet at exactly the wrong moment.
Leaked: ShopServe admin login IDs and passwords. Payment-slip shop details: sales manager name, shop name, postcode, address, phone, fax. Affiliate sign-up records: email addresses and passwords.
Here is the gap: the notice calls member passwords encrypted, yet says nothing of the kind about store admin or affiliate passwords, so do not fill that silence in yourself. Any shop operator should work on the basis that the admin login is exposed, and change it.
E-store says it fixed the flaw, cut off the attacker, reset credentials, and tightened sign-in on admin screens, including two-factor or two-step options. It filed reports with the Personal Information Protection Commission and the Kanto Bureau of Telecommunications, and consulted the police. Individual notices to buyers, shops, and affiliates are complete. Buyers whose contact details could not be confirmed fall under the public notice and the contact window, which is also the route E-store offers for store-name checks.
What to do after the ShopServe breach
If you bought from a ShopServe shop, expect phishing built on leaked email addresses to follow. Your moves:
- Plan for impersonation, not for a mystery charge. The likeliest abuse is a call or message that already knows your name, your address, and part of your card number, then asks you to supply the rest. Someone reading your own details back to you has proved they hold the file. They have proved nothing else.
- Never type card details or passwords into a page reached from an email or SMS about this breach. E-store says it will never ask. Your card company will not ask that way either.
- Read your card statements for charges you do not recognise. Ring the number printed on the back of the card if anything looks wrong. Partial card data cannot finish a payment by itself, but it can make a scam call persuasive enough to collect the rest.
- Change any password you reused. If a shop-account password matches one you use somewhere else, change it there now. Member passwords were encrypted, but reuse turns one leak into logins elsewhere.
- Switch on two-factor authentication on your email. Names, addresses, and phone numbers feed account-recovery tricks. Two-factor is the step a caller cannot talk past.
- Check Have I Been Pwned once this incident is listed, and follow the breach-response order of operations.
If you run a ShopServe shop:
- Treat the admin login as exposed. Change it, and switch on the stronger admin sign-in E-store added, two-factor or two-step.
- Look through admin login history and shop settings for changes you did not make. The notice found no backdoor, but a leaked admin login stays live until it is changed.
- Tell your customers yourself, in your own words, through your own channels, because impersonation messages will arrive wearing your shop's name. A short note saying you will never ask for card details by email gives buyers something real to measure the fakes against.
A different address for every shop
The email address is the one field in this file you could have made traceable. Give each shop its own email alias, forwarding to your real inbox, and the picture changes. A message arrives on the alias for one shop, and you know which shop it escaped from. That is the leak-tracing mechanism doing its job. Shut the alias down and the impersonation channel closes while your real inbox stays untouched. The set-up guide takes about two minutes.
Aliases cannot pull back the name, address, or phone number in the file. Those fields are gone, and no tool fetches them back. What an alias takes back is the one field the attacker needs to reach you, plus the one field that says where the leak started.
Three things to watch
First, whether the dataset turns up in public. E-store's forensic work found no outflow onto the dark web as of publication. If that changes, a contained incident becomes a circulating one, and the phishing wave gets far worse.
Second, whether reports of secondary harm start coming in. None were confirmed as of the final report. Fields like these take weeks to turn into fraud. A quiet October proves nothing about December.
Third, whether the same shape shows up again: one shared backend, thousands of shopfronts, victims who cannot name the shop. ShopServe is the largest version of that shape so far, at 23.35 million people and 7,858 shops. It will not be the last. The answer for the next one matches the answer for this one: give every shop a different address, so the leak names itself.
Top comments (0)