Three holes in one company, plus old data that was kept instead of deleted

At a glance

In October 2026, Adventure, Inc. (株式会社アドベンチャー), the company behind the Japanese travel booking site skyticket, disclosed one data breach in three separate reports. The skyticket data breach had three different entry points, and the first report alone said about 14.64 million records of customer data had leaked. The second and third reports came because the same intrusion had also reached old data: card payment records that should have been deleted years ago, and a database backup that was no longer needed but was kept instead of deleted. If your company keeps old data without cleaning it up, this case is about you too.

When

• The holes were open: bus booking completion page, August 3 to October 1, 2026 / business management system, September 20 (found September 28) / company servers, October 2 to 4 (found October 5).
• Reports: first on October 9, second on October 16, third on October 28 (stock exchange filing) and October 30 (posted on the website).

Who

• Company: Adventure, Inc., listed on the Tokyo Stock Exchange Growth market (code 6030).
• Service: skyticket, a site for comparing and booking flights, hotels, rental cars, highway buses and ferries.

What leaked and how much (the units differ, so I do not add them up)

• Route 1, company servers, first report: about 14.64 million records of customers who registered or entered their details (name, date of birth, email, phone, address and more). About 4.13 million of those records included a login password in hashed form (scrambled so the original text cannot be read directly).
• Route 1, second report: card number, cardholder name and expiry date from old membership fee payment logs, for up to 6,140 people.
• Route 1, third report: from a backup that was never deleted, 32,341 records of refund bank accounts leaked (sending to the outside was confirmed). Partial card data, about 936,000 records (about 414,000 people), and travel insurance data, about 118,000 records (about 119,000 people), are a "possible leak."
• Route 2, business management system: name, phone, refund bank account and more, 17,780 records (duplicates included; other records are still being counted).
• Route 3, bus booking completion page: about 12,000 bookings (the number of people, including travel companions, was not disclosed).
• Actual misuse: an unauthorized login to one member's account. That is the only misuse the company says it confirmed. The line "no secondary damage confirmed" appears only in the first and second reports; the third report has no such item.

Why (official statements only)

• Route 1: some admin functions were misused, and from there other servers and cloud data were accessed. Credentials taken at that time (information that works like a key to a server) were then used to read the backup.
• Route 2: a vulnerability (a security weakness) in the business management system was exploited.
• Route 3: the booking completion page could be viewed without logging in, and a third party viewed it by automated means.
• How the admin functions were misused, and how the credentials were obtained, has not been disclosed.

Where things stand now (as of November 4)

• The announcements have been corrected twice. The first report's "card data did not leak" was corrected in the second report. The second report's "Benefit Station IDs and passwords leaked" was corrected in the website version of the third report.
• An external forensic investigation (an outside specialist's investigation of the intrusion) was still "being prepared" at the time of the third report. All three reports say the effect on earnings is "under close review."
• No new notice has been posted since the third report.

If you have used skyticket (details below in "What should skyticket users check?")

• Change your skyticket password, and change it on any other service where you use the same password.
• Check your card statements for charges you do not recognize.
• The company said its notices come from info@skyticket.com and do not include links asking you to enter a password. It also asked users to watch for contact from people pretending to be bus operators.

What to check in your own company today

1. Data that should be deleted: old payment records, unused database backups and copies left on servers or in the cloud.
2. Admin screens: who can get in and from where, and whether keys to other servers or cloud services are stored inside.
3. Pages that open without login: booking, order and receipt pages that show someone else's data to anyone who has the URL.
4. Encryption: whether the fields you decided to encrypt (bank accounts, names) really are encrypted, and whether the keys sit in the same place.
5. Announcements and inquiries: do not say "this did not leak" before the investigation is done, and make sure your email and phone desks can handle a flood of questions.

What happened, and why were there three reports?

Here is the order of events.

• February 2017 to June 2018: records (logs) of card payments for the paid membership "skyticket Premium (skyticketプレミアム)" built up on the company's servers. In this period, the company kept card data on its own servers.
• July 2018: the company switched to a method that does not keep card data in-house. It deleted the card data, but it did not delete the membership fee payment logs.
• May 2021 to May 2024: a database backup that was later read held payment, refund bank account and travel insurance data from this period. The company kept this backup in the cloud after it was no longer needed, instead of deleting it.
• August 3, 2026: the highway bus booking completion page became viewable without login. A third party viewed it by automated means.
• September 20: a vulnerability in the business management system was exploited. It was found on September 28.
• October 1: the bus page problem was found and fixed the same day.
• October 2 to 4: some admin functions were misused, and from there other servers and cloud data were accessed. On October 3, the old Premium fee logs were taken. It was found on October 5.
• October 7, around 6 p.m.: the company stopped payments with saved cards and the card-saving function.
• October 8, around 7 p.m.: it began sending notice emails to affected customers (notice¹).
• October 9: first report (website², TDnet filing³).
• October 16: second report. It corrected the first report's "no card data leaked" (website⁴, TDnet filing⁵).
• October 28: third report filed on TDnet, the Tokyo Stock Exchange's timely disclosure system (TDnet filing⁶).
• October 30: third report posted on the skyticket site and the company site (website⁷).

So the three reports were not three attacks. The first report covered all three entry points. The second and third reports added damage from the same October intrusion on route 1, as the company found more old data that had been read: payment logs in the second report, and the backup in the third.

There is also the unauthorized login to one member's account. The first report lists it under route 2 (the business management system), but the login date it gives (September 9) is earlier than the route 2 date (September 20). I could not find any notice or article that explains how the two dates fit. So I have left this login out of the timeline above.

What were the three entry points?

It was not one break-in. Three different doors were open, separately.

• Route 1, company servers (October 2 to 4): the biggest hole. Some admin functions were misused, and from there the attacker got into other servers and the cloud. One admin function became the door to other servers and cloud data.
• Route 2, business management system (September 20): a vulnerability in a system used by staff was exploited.
• Route 3, bus booking completion page (August 3 to October 1): less a break-in than a page that was simply open. The page you see after you finish a booking could be viewed without login, and it was viewed by automated means for about two months.

The method used to misuse the admin functions has not been disclosed (first report²).

What data was leaked?

The units differ: records, people and bookings. I keep each one as the company gave it, and I do not add them up.

Route 1, first report (first report²)

• About 14.64 million records of customers who registered or entered their details: name (including the spelling on the passport), date of birth, email, phone number, postal code and address, and the payer name used for bank transfers.
• About 4.13 million of those records: member login passwords in hashed form.
• The company said it confirmed that passport numbers did not leak.

Route 1, second report (second report⁴)

• Up to 6,140 people, from 2017–2018 Premium fee logs: card number, cardholder name and expiry date (for some, only the card number). Security codes were not included.
• The logs were encrypted, but the information used for the encryption was taken too.

Route 1, third report (third report⁷)

• 32,341 records of refund bank accounts (leaked; sending to the outside was confirmed): bank name, account type, account number and account holder name in katakana. The company said these records did not include names in kanji, addresses, email, phone, account PINs, or online banking IDs and passwords.
• About 936,000 records (about 414,000 people) of some card-paying customers ("possible leak"): cardholder name, a partly masked card number (last 4 digits, or first 6 plus last 4), and browser information. In 12 of these records, the full card number was stored, because the customer had typed the card number into the cardholder name field.
• About 118,000 records (about 119,000 people) of travel insurance ("possible leak"): names (in katakana), dates of birth and gender of policyholders and insured persons. For policyholders, also mobile number, email, member ID and booking details (flight number, travel date, route, trip price).
• For the card and insurance data, no trace of sending to the outside was found, but the company could not rule it out, so it announced them as a "possible leak."

Route 2 (first report²)

• 17,780 records (duplicates included; other records are still being counted): name, phone number, refund bank account (bank name, branch name, account type, account number, account holder) and more. Some also included email and date of birth (68 records) or address (18 records).
• On passport numbers, the company said a leak "has not been confirmed at this point" and that it was still checking. The second and third reports gave no update.

Route 3 (first report²)

• About 12,000 bookings: booker's name (in katakana), age, gender, date of birth (if registered), email, phone, member ID, device type, payment method and amount, booking date and time, bus details (date and time, boarding and drop-off points, bus operator, service number, the operator's booking number), and companions' names, ages and genders.

Who was affected?

Customers

• Customers who registered or entered details on skyticket: about 14.64 million records, of which about 4.13 million also included a hashed password.
• Customers who registered a refund bank account: 17,780 records via route 2, and 32,341 records via the route 1 backup. These come from different routes and different periods, and the company has not said whether they overlap.
• One member whose account was logged into without permission.
• Highway bus users and their companions: about 12,000 bookings.
• 2017–2018 Premium members: card data for up to 6,140 people.
• Some card-paying customers from 2021–2024: about 414,000 people (about 936,000 records), including 12 records with the full card number.
• Travel insurance policyholders and insured persons from 2023–2024: about 119,000 people (about 118,000 records). Insured persons were travel companions and may not be skyticket customers themselves.

Business partners

• Bus operators (names not disclosed): the operators' booking numbers were viewed, and the company warned users about contact from people pretending to be bus operators (first report²). I could not find a notice from any bus operator.
• Payment processor and card companies (names not disclosed): they received reports and were asked to monitor for fraudulent use.
• The insurer behind the travel insurance (name not disclosed): it received a report (third report⁷).
• Benefit One, Inc. (株式会社ベネフィット・ワン): skyticket reported the case to it. However, Benefit One's news list⁸ had no notice about skyticket as of November 4. Benefit One's October 28 notice (PDF⁹) concerns a different contractor and is a separate case.

Why were the announcements corrected twice?

Correction 1: card data. The first report said card data did not leak because the payment processor holds it. The second report corrected this: card data had remained in old membership fee logs (second report, TDnet filing⁵). Anything that quotes only the first report is now wrong on this point.

Correction 2: Benefit Station. The second report said member IDs, names and passwords for "Benefit Station (ベネフィット・ステーション)," a perk for Premium members, had leaked. The website version of the third report corrected this: they were member IDs and names that skyticket had set internally for Premium, not Benefit Station IDs or passwords (third report⁷). Articles that quote only the second report carry the uncorrected version.

The same third report differs by version. The TDnet version (October 28) and the website version (October 30) differ in more than the date. On how bank account holders would be notified, the TDnet version says the data could not be linked to contact details, so a public notice would take the place of individual notices. The website version says emails would go out in turn to customers whose contact details could be confirmed. The Benefit Station correction appears only in the website version (third report, TDnet filing⁶, third report, website⁷). In the second report too, the request to card companies to monitor for fraud appears only in the TDnet version.

The lesson, as I see it, is clear. If you say "this did not leak" before the investigation is done, a correction will follow.

Why do news reports give different numbers?

• Totals: some headlines on the skyticket data leak used a simple sum of the numbers from routes 1, 2 and 3. Route 2 includes duplicates and route 3 counts bookings, so the sum does not mean anything. The company did not announce a total, and neither does this article.
• Rounding: for the second report's "up to 6,140 people," NHK wrote "just over 6,000 people" (report¹⁰), and INTERNET Watch's headline said "about 6,000 records" (report¹¹). And 6,140 is a ceiling, not a confirmed count.
• Records vs. people: in the third report, cards are about 936,000 records for about 414,000 people, while insurance is the other way around, about 118,000 records for about 119,000 people. The company has not explained the difference.
• Third report date: TDnet October 28, TRAICY's report October 29 (report¹²), the website October 30. The date depends on where you looked.
• Before corrections: articles that quote only the first or second report carry pre-correction content (ITmedia's report¹³ covered the correction at the second report stage).

Why did an old backup that was never deleted matter so much?

This is the core of the case. There was one intrusion on route 1, but the damage was announced three times. The reason was old data that was still there.

Second report: old payment logs. In July 2018, the company switched to not keeping card data in-house, and it deleted the card data. But the payment logs (change history) for Premium fees from February 2017 to June 2018 were kept. These logs were taken on October 3, and on October 15 the company found they contained card data. The logs were encrypted, but the information used for the encryption was taken with them (second report⁴). It is like keeping the lock and the key in the same drawer.

Third report: a database backup that was never deleted. In the company's words, it had "kept a copy (backup) of a database taken in the past in the cloud, without deleting it after it was no longer needed" (過去に取得したデータベースの複製（バックアップ）を、不要となった後も削除せずにクラウド上に保管しておりました). Credentials taken in the October 2 to 4 intrusion were used to read part of this backup. As a result, 32,341 records of refund bank accounts are confirmed as leaked, and partial card data, about 936,000 records (about 414,000 people), and travel insurance data, about 118,000 records (about 119,000 people), are a possible leak. The company also admitted that "the bank account information and the name fields for travel insurance should have been stored encrypted, but were stored without encryption" (銀行口座情報及び旅行保険のお名前の項目は、本来暗号化して保存すべきものでしたが、暗号化されずに保存されておりました) (third report⁷).

My reading is that this comes down to poor management of kept data, especially backup data. It was left alone because "we don't use it." But those old records still held customers' personal data as it was: card numbers, refund bank accounts, names. Data does not lose its security value as it gets older. Once it is taken, data from years ago becomes damage today. I see this as the most important lesson of this case.

Is a company in Japan required to delete data it no longer uses? Article 22 of Japan's privacy law, the Act on the Protection of Personal Information (APPI), says a business must "endeavor to" delete personal data without delay once it no longer needs to use it (e-Gov law search¹⁴). In the way the law is written, that is an effort obligation, not a strict duty.

My view: an effort obligation is not a reason to keep data. In this case, the damage in both the second and third reports came from data that stayed after it was no longer needed. If it had been deleted, there would have been nothing there to read.

How did the company respond?

• It closed the routes of entry and took measures against the vulnerabilities. It fixed the bus page on October 1.
• Around 6 p.m. on October 7, it stopped payments with saved cards and the card-saving function. It said this was to stop fraudulent purchases with saved cards if a member account was taken over.
• From October 8, it sent notice emails from info@skyticket.com, and said those emails do not include links asking you to enter a password (notice¹).
• It asked members to change their password, and to change it anywhere else they use the same one.
• A flood of inquiries caused a mail server outage; the company announced recovery on October 10 (notice¹⁵). On October 13, it opened a dedicated phone line (03-5224-8859, weekdays 10 a.m. to 6 p.m. Japan time) (notice¹⁶).
• For the backup, it removed the credentials' access rights so the backup can no longer be read, and it plans to delete the backup after the investigation.
• For the card data (about 414,000 people), the records cannot be linked to contact details, so there is no individual notice; a public notice takes its place. Notices to travel insurance policyholders will be sent "at a later date."
• It reported to the PPC (Japan's Personal Information Protection Commission, the privacy regulator), and from the second report on, it also wrote that it reported to "relevant authorities." No notice mentions a report to the police.
• An external forensic investigation was "being prepared" at the time of the third report.
• None of the three reports mentions compensation or any payment. Instead, the company warned users not to respond to contact asking for money transfers or fees in the name of compensation (third report⁷).

What should skyticket users check?

Here is the guidance from the company's notices, arranged from the user's side.

1. Change your skyticket password. If you use the same password on other services, change those too.
2. The company said its notice emails come from info@skyticket.com and do not include links asking you to enter a password.
3. Do not respond to contact that offers "compensation" and asks for a money transfer or a fee.
4. As the second report asks, check your card statements for charges you do not recognize. The first report also asked users to watch for contact from people pretending to be bus operators.
5. For questions, use the dedicated phone line opened on October 13 (03-5224-8859, weekdays 10 a.m. to 6 p.m. Japan time).

The website version of the second report also says customers who want their member information deleted can contact info@skyticket.com (second report⁴).

Is skyticket safe to use after the data breach?

People who search "Is skyticket legit" or "Is skyticket safe" want a yes or a no. I will not give one. Here is what is on the record as of November 4, so you can judge for yourself.

• Who runs it: skyticket is run by Adventure, Inc., a company listed on the Tokyo Stock Exchange Growth market (code 6030). The company disclosed this incident itself, in three reports.
• What the company has done: it closed the routes of entry and took measures against the vulnerabilities; fixed the bus page on October 1; stopped saved-card payments and card saving on October 7; removed access to the backup and plans to delete it after the investigation; and reported to the PPC.
• What is still open: the method of the attack has not been disclosed. The external forensic investigation was still being prepared at the time of the third report. The third report has no item on secondary damage. No new notice has been posted since the third report.
• What you can check: the five steps in the previous section.

Was AI used in this attack?

There is no official announcement or news report saying AI was used in this incident. The method of intrusion itself has not been disclosed.

But what people call AI cyber attacks — attackers using AI to find weak points and even build the way in — has already been shown to be possible.

• Anthropic said that in evaluating Claude Mythos Preview, it found thousands of high-severity vulnerabilities in major operating systems and browsers. It has not released this model to the public (Glasswing¹⁷, research¹⁸).
• The security company Wiz said it used AI to find "PHP2Shell," a remote code execution vulnerability in the PHP engine (Wiz¹⁹). Amazon said it had already seen attempts to exploit this vulnerability four days before it was made public (AWS²⁰).
• In the same October, GMO Ierae (GMOイエラエ) announced that ARTEX, an AI penetration testing tool, was found in attack infrastructure aimed at about 20 Japanese companies (GMO Ierae²¹). That announcement does not name the targeted companies and does not mention skyticket.

So I think we should prepare on the assumption that people with bad intent use AI like this. Holes that were "too much trouble for a person to look for," like pages that open without login or admin screens left in place, can be found much faster by a machine.

We live in a world where AI makes security holes easier to find. That means now is the time to speed up our own checks. We cannot leave the speed of finding holes to the attackers alone. Mythos Preview is not public, but I think every company should check whether it has problems, even if only by doing what Glasswing does: using AI to check its own services first.

What does this mean for your business?

Much of the data that left in this case was data the company already considered "not in use." That is why the Adventure Inc. breach is not only a big-company story.

• The data you keep sets the size of the damage. Payment logs that should have been cleaned up in 2018, and a backup that was no longer needed, were still there. Data you do not use today can still be taken if it is kept. Customer data does not lose value because it is old.
• One admin screen can be the door to everything. The attacker went from an admin function into other servers and the cloud, and the keys found there opened the backup too.
• Completion pages need protection too. A booking completion page could be viewed without login for nearly two months.
• Encryption only works if you manage the keys. And you need to check that the fields you decided to encrypt really are encrypted.
• Data customers type into the wrong field gets stored too. 12 records with a card number typed into the cardholder name field stayed as they were.
• Data you cannot link to contact details cannot get an individual notice. About 414,000 people are informed only by a public notice.
• Business partners become victims too. Bus operators, an insurer and a payment processor all received reports, and their names can be used in fake contact.

Here is what I think. Attacks come in, in the end, through the places that touch the outside. In this case, the place that stood open to the outside was a single completion page, shown after a booking is finished. It was a small page, but about 12,000 bookings were exposed through it. Every place that touches the outside, however small, needs a thorough check, with nothing left out.

What happened (based on official announcements)

• February 2017 to June 2018: payment logs for skyticket Premium fees paid by card built up on the company's servers. In July 2018, when the company switched to not keeping card data, it deleted the card data, but these logs were kept. ⁴
• May 2021 to May 2024: a database backup holding payment, refund bank account and travel insurance data from this period was not deleted and stayed in the cloud. ⁷
• August 3 to October 1, 2026: the highway bus booking completion page could be viewed without login and was viewed by a third party by automated means. Found and fixed on October 1. ²
• September 20, 2026: a vulnerability in the business management system was exploited. Found on September 28. ²
• October 2 to 4, 2026: some admin functions were misused, and other servers and cloud data were accessed. Found on October 5. ²
• October 3, 2026: the old Premium fee logs were taken. ⁴
• October 7, 2026, around 6 p.m.: payments with saved cards and the card-saving function were stopped. ²
• October 8, 2026, around 7 p.m.: notice emails to affected customers began (sender: info@skyticket.com). ¹
• October 9, 2026: first report. It announced leaks through three routes and an unauthorized login to one member's account. ²
• October 10, 2026: the company announced recovery from a mail server outage caused by a surge in inquiries. ¹⁵
• October 13, 2026: a dedicated phone line opened. ¹⁶
• October 16, 2026: second report. It corrected the first report's "no card data leaked" and announced a card data leak for up to 6,140 people. ⁴
• October 30, 2026: third report. It announced refund bank account, partial card and travel insurance data from the backup, and corrected the second report's statement about Benefit Station. ⁷ / Company news list²²
• As checked on November 4, 2026: no new notice after the third report on the skyticket notice list or the company news list. skyticket notice list²³ / Company news list²²

Companies that disclosed damage and what leaked

The units differ, so there is no total. The company did not announce a total either.

As of November 4, 2026. Each company's notices may change after this date.