Yellow Hat: Reservation System Breach Exposes 1.8 Million Members

Yellow Hat Ltd. (TSE Prime: 9882) is one of Japan's largest auto parts and car service retailers. It has confirmed that attackers broke into its online work reservation system ("Yellow Hat WEB作業予約システム") and stole personal data belonging to Yellow Hat members. The number has moved over time. The company's first notice on August 28, 2026 said data for up to 1,801,499 people may have leaked. Its second report on October 15, 2026 followed an independent forensic investigation and confirmed the theft of data for 1,797,124 members, as reported by Security Measures Lab and TipRanks' auto-generated newsdesk. The company says no credit card data was involved, because the reservation system did not hold or process card details. No threat actor has been named, and no group has publicly claimed the attack.

What Happened

According to the company's disclosures as relayed by Japanese security outlets, Yellow Hat detected unauthorized access to the reservation platform in August 2026. The exact date is inconsistent. Security Measures Lab notes that the first report gives the detection date as the morning of August 18, while the second report says August 19. The company has not explained the difference.

Yellow Hat's response, as described across the sources:

• August 18 or 19: Unauthorized access detected. The company cut external connections and took the reservation system offline.
• August 28: First disclosure. Yellow Hat said the system had been hit by a malicious program and that data for up to 1,801,499 members may have leaked.
• August to October: A third-party forensic firm analyzed the system and its access logs. Yellow Hat strengthened security, modified the system, and brought it back online after a third party verified the fixes.
• October 15: Second report, filed as a timely disclosure at 15:30 JST. It confirmed that customer data was taken and set the affected count at 1,797,124, which is 4,375 fewer than the first upper estimate. Yellow Hat says it has finished notifying affected customers by web, email, letter and phone, has filed its final report with Japan's Personal Information Protection Commission, and is cooperating with a police investigation.

Yellow Hat says stores run by other group brands use a separate management system, so customers who only used those stores are not affected (ITD).

The company says the cost of responding is not expected to materially affect its financial results (TipRanks).

What Was Taken

Both the record count and the list of exposed data fields changed between the two disclosures.

Record count - 1,801,499: the upper bound for possible exposure in the August 28 first report (ITD, Security Measures Lab, Yusuf Purna on LinkedIn). - 1,797,124: the confirmed number after forensics, in the October 15 second report (Security Measures Lab, TipRanks).

Coverage that rounds this to "about 1.8 million" is citing the first figure, which was an estimate of possible exposure. The confirmed figure is 1,797,124.

Data fields - First report (August 28): name, phone number, email address, membership number. - Second report (October 15): all of the above, plus home address, date of birth, gender, login ID and password. The company says passwords were stored in a form that cannot be reversed.

The password detail creates a real conflict between sources. A LinkedIn analysis written after the first notice (Yusuf Purna, September 2) said passwords, payment card data and vehicle data were not stored in the affected system. The October 15 report, as summarized by Security Measures Lab and TipRanks, lists stored passwords among the leaked items. Yellow Hat says they cannot be recovered and that their exposure poses no risk of account takeover. The company has not disclosed which hashing or storage method it used, so outsiders cannot check that claim. The later forensic finding should be treated as authoritative.

Every source agrees that no credit card data was exposed. Taken together, the confirmed fields (full name, address, date of birth, gender, phone, email and membership ID) are enough for convincing, personalized phishing and phone or SMS fraud.

Why It Matters

This is the second incident in the Yellow Hat group within months. In April 2026, the subsidiary 2rinkan Yellow Hat (a motorcycle retailer) detected unauthorized access to its members-only server on April 20. It first said up to 3,455,754 members could be affected, then confirmed 3,179,454 in a final report on June 19 (Security Diagnosis-san). Combined, the two incidents put the group's confirmed exposure at nearly 5 million member records in 2026. Both companies say the incidents involved separate systems. No public evidence links the attackers or methods, and the sources are explicit that the connection is unknown.

Low-profile systems can hold high-value data. A booking tool for oil changes and tire fitting looks less critical than a payment system. But this one could reach a member database of almost 1.8 million people. Risk depends on what data an application can reach, not on what job it appears to do.

Fraud using reservation data is already happening in Japan. In separate, unrelated incidents, attackers breached the hotel reservation platform TEMAIRAZU. Since September 21, 2026, hotels using it, including UDS Hotels and CREAL Hotels' LACER SUITES KAMAKURA, have reported fake messages sent over WhatsApp, WeChat, SMS and email. The messages urge guests to "confirm" bookings or re-enter card details on fraudulent sites. There is no indication that TEMAIRAZU is connected to Yellow Hat. These cases do show what attackers do with exactly this kind of data, which is names, contact details and booking context. Yellow Hat members should expect fake messages about bookings, vehicle inspections and apologies or compensation offers.

The Attack Technique

Yellow Hat has not publicly disclosed how the attackers got in. The first report described the attack only as a "malicious program" (不正プログラム) targeting the reservation system. The second report says the forensic investigation identified the cause and scope, but the public summaries do not describe the entry point, the vulnerability or the malware.

Facts about the method that the sources do support: - The attacker reached and removed member records connected to the reservation system, not only reservation data. - Logs were detailed enough for investigators to count affected records exactly. - The fix involved system modifications and security hardening, which suggests an application-level weakness rather than only stolen credentials. This is an inference, not a disclosed finding.

For comparison, the 2rinkan incident did have a disclosed method. According to 2rinkan's third report, attackers stole information from inside the company's mobile app. Starting at 04:54 on April 20, they used it to call a personal-data API directly, without going through the app, and pulled data from the customer web server. 2rinkan said it found no signs of a server intrusion. It has not said what was taken from the app or how. Nothing indicates the same technique was used against Yellow Hat.

On attribution: no source attributes the Yellow Hat breach to any group. Recent reporting describes ShinyHunters (UNC6240) using a URL-encoding trick (/%50SEMHUB/ in place of /PSEMHUB/) to get past WAF rules protecting Oracle PeopleSoft servers vulnerable to CVE-2026-35273 (BleepingComputer, citing Mandiant/GTIG). That campaign is mentioned here only because it shows a lesson defenders should apply broadly. Nothing connects it to Yellow Hat, and readers should not infer a link.

What Organizations Should Do

1. Map what each customer-facing application can reach. List every database and table that booking, scheduling and loyalty apps can query. If a reservation tool can read full member profiles including date of birth, address and credentials, reduce that access to what the booking workflow needs.

2. Lock down mobile and partner APIs independently of the client app. The 2rinkan case shows that hiding an API behind a mobile app is not a security control. Require per-user authorization on every call, rate-limit bulk record retrieval, and alert on API traffic that does not come from the expected client.

3. Don't treat WAF rules as a substitute for patching. The ShinyHunters PeopleSoft bypass shows that rules matching raw paths can miss encoded requests. Normalize and decode URLs before applying rules, and patch the underlying flaw rather than relying on blocking.

4. Store credentials with modern, salted, slow hashing, and say which one you use. "Cannot be recovered" only holds if the algorithm is bcrypt, scrypt or Argon2 with a per-user salt. Publishing the method in breach notices helps users and researchers judge the actual risk.

5. Keep logs good enough to count affected records exactly. Yellow Hat could narrow 1,801,499 down to 1,797,124 because it had usable access logs. Keep application and database query logs centrally, out of reach of compromised hosts, for long enough to support forensic investigation.

6. Plan customer anti-fraud messaging before an incident. Once contact data leaks, phishing that uses booking or inspection themes follows quickly, as the TEMAIRAZU-linked hotel scams show. Tell customers in advance which channels you will use to contact them, and that you will never ask for card numbers or membership IDs by SMS or messaging apps.

Sources: Yellow Hat Confirms Large-Scale Data Leak But Sees Limited Financia... | ShinyHunters uses WAF bypass trick in Oracle PeopleSoft attacks | Yellow Hat Data Breach (August 2026): Online Work Reservation Syste... | 🟡 Yellow Hat’s Potential 1.8 Million-Record Exposure: A Customer Pl... | Important Notice Unauthorized Access to the Reservation Management... | Important Notice Apology and Announcement Regarding Unauthorized Ac... | イエローハットの情報漏えい｜２りんかんと予約システム、原因と被害 セキュリティー診断さん | イエローハット、不正アクセスによるサイバー攻撃で179万7,124人分の個人情報漏えいを確認セキュリティニュースのセキュリティ対策Lab