RideOn Express says up to 6.5 million Gin no Sara records may have leaked, and waiting for proof that any of it left its servers hands attackers the weeks when phishing works best. I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. Kamatora and Sushi Joto sit in scope beside it. A delivery signup holds a full identity record, and the gap between may have leaked and confirmed stolen is where victims must act.
What RideOn Express confirmed
Three outlets carried the 13 October disclosure: Jiji Press, the Japan Times and Asia Daily, which worked from the company's incident notices and its filing. The shape of the story:
| Confirmed | Still unconfirmed |
|---|---|
| RideOn itself announced the possible exposure on 13 October, in its second incident notice | Whether any personal information actually escaped the affected environment |
| Unauthorised access picked up from 5 October; failure on some servers early on 7 October | How attackers got into the servers |
| Roughly 6.5 million records at risk at most, across the three brands' official websites and apps | How much of that 6.5 million, if any, an attacker could actually see |
| Fields at risk: names, addresses, phone numbers, email addresses, gender, dates of birth, password hashes, order histories, Deli Point membership IDs | Whether the dataset will appear in public or be traded |
| Family and delivery-contact details may be swept in where customers typed them in | Whether the stored password hashes stand up to guessing attacks; the hashing method stays undisclosed |
| Zero credit card data: the company says it keeps no card information | Who the attacker was, or whether anyone demanded a ransom |
| Ordering through the official sites and apps still suspended at disclosure, no reopening date; menu browsing and store search still worked | Any recovery timetable or date for the investigation to finish |
| Report filed with Japan's Personal Information Protection Commission and with police | Any specific technical security changes the company will make |
| No confirmed secondary harm from misuse at disclosure |
Handle the 6.5 million figure with care every time it shows up. It caps the records that could be affected, not a tally of stolen records or distinct people. One customer can hold several records. A delivery contact who never opened an account can still appear in the file, because the account holder typed in their name and address. RideOn spoke before the investigation could establish a leak or its scope. Right call. And the reason every number in this story still carries the word may.
The first notice was not the breach notice. On 8 October the company warned of a service interruption. The breach warning arrived five days later, on 13 October, after its emergency response team decided to tell potentially affected customers rather than wait for confirmation of theft. Phone, store takeaway, Demae-can and Uber Eats ordering kept running from 8 October, and customers who ordered only through those channels fall outside the stated scope.
Two ransomware stories, one wrong merge
Two ransomware stories ran in the same week. Do not merge them.
RideOn's version: the company picked up unauthorised access to servers it used from 5 October. On 7 October some servers failed, the server operator reported a ransomware attack, and RideOn stopped its systems and set up an emergency response team the same day. The ransomware struck the operator, on the company's account. RideOn has not named it.
The other version: a ransomware incident at IDC Frontier's IDCF Cloud service knocked out part of its East Japan Region 1 platform at about 3:40 a.m. on 7 October and hit 495 companies and organisations. IDC Frontier said pulling data back in the affected zone would be difficult. That language echoes RideOn's third incident notice, which likewise warned that retrieving or restoring entrusted data would be difficult.
Matching timing. Matching wording. Neither proves a shared incident. Asia Daily puts it plainly: RideOn has not identified its server operator, and the parallels do not establish that RideOn was on IDCF Cloud. Same day, 13 October, brought a separate JR Tokai disclosure: about 15,000 e-commerce users whose data may have leaked through fraudulent access at IDC Frontier. That one is attributed to IDC Frontier. RideOn's is not. Blaming RideOn's breach on a vendor it has never named would let the real operator stay unnamed.
This matters beyond pedantry. If the ransomware hit the operator's infrastructure, the questions are what the operator could see, how long the exposure lasted, and whether data was copied before the systems went down. Ransomware locks systems. A leak moves data out. Proof of the first does not prove the second.
Why may have leaked still means act now
Picture the message. It names the sushi set you actually ordered, to the address you actually use, from a sender that looks like the brand. It reads like a receipt. That is what this file makes possible: names plus addresses plus phones plus dates of birth, with order history on top. Delivery-contact details widen it to family members who never signed up.
The password hashes are not a clean bill of health. The company describes them as encrypted and unreadable in stored form. A hash is not the password written out. That distinction does real work. But hashes fall to guessing, and the company has not said which hashing method it used or what else protects those values. If the password you used for Gin no Sara matches one you use anywhere else, change it there now. The hash buys time, not safety.
No confirmed misuse is a snapshot, not a verdict. At disclosure, RideOn had found no secondary harm. Breach data rarely gets used the day it is taken. It gets sorted, matched against other breaches, and used weeks later. Act in the unconfirmed window and you are ready when the impersonation wave arrives. Wait, and you spend that window doing nothing.
One genuine piece of relief: no credit card data sits in scope, because the company says it holds no card information. Direct card fraud drops off the list. Phishing, impersonation calls, and account-recovery attacks built from the rest of the file stay on it.
RideOn warned customers about suspicious calls and emails, especially messages asking for a password. A genuine company message will not ask you to hand one over. Treat any that does as the breach talking.
What Gin no Sara customers should do now
- Expect messages that quote your real orders. A delivery confirmation, a refund notice, a problem with your order text that names the right items and the right address is the likeliest abuse of this file. Treat every message about this breach as suspect until you verify it through a channel you chose.
- Ignore links in messages about this breach. Reach the company's own site by typing the address yourself, or ring the customer consultation line on 0120-782-272 (10 a.m. to 8 p.m. daily through 15 November, then weekdays). The company says it will send apologies and guidance in stages, with no completion date, so a genuine message is plausible, which is exactly what makes the forged ones hard to spot.
- Change the account password if you reused it anywhere. What is at risk is a hash, not the password itself, but reuse turns a hash from one breach into access on another site. Change it everywhere it matches, starting with your email.
- Switch on two-factor authentication on your email. Leaked names, numbers and dates of birth are the raw material of account-recovery flows. Two-factor authentication is the part an attacker cannot talk their way past with your own details.
- Warn the people whose details you entered. If you put a family member's name or a delivery contact's address into an order, they sit in the at-risk set without ever creating an account. Tell them to expect calls and messages that know their name.
- Check Have I Been Pwned once the incident is listed, and walk the breach-response order of operations.
One address per delivery app
The email address you registered with Gin no Sara is the one field in this at-risk file you could have made expendable. A unique email alias for the delivery signup, forwarding to your real inbox, changes the impersonation maths completely.
Every message on that alias comes from the delivery brand or the attacker. No third option. A refund notice quoting your real order, on an address no one but Gin no Sara ever had, that links to a login page has given itself away: the real brand would never need to email you for data it already holds. The leak-tracing mechanism works exactly this way: a message lands on the Gin no Sara alias and you know at once which company it escaped from. Kill the alias and the whole channel dies while your real inbox stays clean. The set-up guide takes about two minutes.
Delivery apps are the loyalty programme problem with a hungrier data model. You sign up for dinner, the app sits on your phone for years, and it quietly turns into an identity record: your name, address, phone, birthday, and a log of what you eat and when. Demae-can, Uber Eats or telephone-only customers fall outside the stated scope: the fewer places holding your real address, the fewer breach notices with your name on them. The same week brought Lawson's 2.15 million-member breach and Daiichi Kosho's 8.72 million karaoke records. The pattern is not one careless company. It is every signup form holding more than it needs.
What to watch in the investigation
Three things. First, whether RideOn upgrades may have leaked to confirmed exfiltration, and names the number actually taken plus the operator involved. Second, whether the dataset appears in public, and whether impersonation messages quoting real orders show up at scale. Third: one event, or two that overlapped?
Gaps stay wide. No breakdown of the 6.5 million by brand, registration date, or record type. No earliest registration date, no hashing method, no recovery timetable, no date for the investigation to finish, no specific technical security changes announced. No attacker ID, no ransom demand confirmed. The financial impact on the group is still being assessed. Japan is in the middle of a wave of unauthorised-access disclosures, and NHK cites Macnica figures showing cases exploiting website and app vulnerabilities rose from a monthly average of six in the first half of the year to 23 a month since July. The investigation continues. The phishing window opened first.
Top comments (0)