Key takeaways

  • Studio (Studio株式会社), a Tokyo company whose no-code website builder is used for the corporate sites of many Japanese startups and small businesses, says attackers exploited a vulnerability to reach its cloud environment on September 30 and October 1, 2026. Data there could be retrieved from outside until October 14.
  • Studio has not confirmed that data was taken, but is treating it as taken. It says the data of all registered customers may have leaked. ITmedia puts Studio's user base at more than 900,000.
  • That includes far more than accounts: submissions to forms on its customers' websites, API keys and tokens for other services such as headless CMSs, Google Sheets connection credentials, proxy keys and webhook URLs. Most were encrypted, but the decryption key was read in the same attack.
  • Customers are now disclosing one by one. Scooter-sharing company Luup reported 21,368 form submissions, Link-U Group 7,663 and printing platform Raksul 6,412. Saitama Prefecture and the City of Kyoto have reported smaller numbers through contractors.
  • Each customer that collected personal data through a Studio form may have its own duty to report to Japan's privacy regulator, the Personal Information Protection Commission (PPC). At the PPC's request, Studio has asked them to hold those reports while it discusses filing one joint report for all of them. Notifying the people affected is not on hold.

What happened#

Studio's first report, published on October 16 and updated twice since, describes the attack this way: a third party abused a vulnerability in part of Studio's features to get into the cloud environment Studio uses, and left the data there retrievable from outside.

Date (JST) Event
Sep 30 – Oct 1 Unauthorized access, the period confirmed so far
Oct 13 Studio finds the access in an internal investigation
Oct 13 – 14 Vulnerability fixed and route closed. All users are logged out at about 02:30 on October 14
Oct 16 Public notice; individual emails to customers by feature
Oct 17 Encryption key replaced. Form customers asked to hold their PPC reports
Oct 18 Incident portal and FAQ published; first report updated

Studio has not said which feature was vulnerable or how the data was reached. It says the credentials the attacker obtained included write permissions; these have been invalidated, and its operation logs show no changes or deletions of customer data. An outside forensic firm is being arranged.

What may have leaked#

For all registered customers:
Accounts User names, email addresses, hashed passwords
Site content Design editor and CMS content, including password-protected pages
Form submissions Everything visitors sent through forms on customers' sites and that was stored on Studio, including responses in the trash and test submissions. File names of attachments, but not the files
Credentials API keys and tokens for external services registered in Studio's API integrations; Google Sheets integration credentials; custom proxy keys; passwords of password-protected pages (hashed)
Other Live preview URLs, reCAPTCHA v3 settings, webhook URLs
Early-access list Email, user name and country of people who applied for early access to Studio AI between December 2022 and August 2023, including some without a Studio account

Studio stored form submissions, API keys, Sheets credentials, proxy keys and webhook URLs encrypted. But it says the key needed to decrypt them was read in the same attack, so their contents "may be known". It has not given a count of customers or records for any category.

The customers: one breach, many notices#

Studio sites usually show the customer's brand, not Studio's. The people who filled in a contact form will hear about this, if at all, from the company they wrote to. Those notices began on October 16. These are the ones we could confirm in primary sources by October 19:

Organization What was on Studio Count
Luup (LUUP scooter and bike sharing) Old website forms: requests to install parking ports (2022–2024), questions about the revised Road Traffic Act (2023–2025), inquiries about its Unimo vehicle. Names, contact details, addresses, companies 21,368 submissions
Link-U Group Inquiries through the corporate sites of the group and its subsidiaries 7,663
Raksul (printing and logistics platform) Inquiry, quote, document request and seminar forms on its service information sites, June 2024 – October 2026. Names, organizations, contact details, budgets 6,412 submissions
Fuller (app developer) Forms on its Japanese and English corporate sites, September 2024 – October 2026 5,948 + 20 (English)
Saitama Prefecture Event applications and inquiries for a prefectural museum, collected by the museum's designated manager, a private company 162
Minaminihon Broadcasting (MBC) Workshop applications, event and program inquiries 38
City of Kyoto Inquiries to two culture programs the city entrusts to a foundation 33
Kufu Company group Five group companies are checking Not given

Three things stand out.

  • Counts are submissions, not people. Luup and Raksul both say so. One person can appear several times.
  • Old forms were still there. Luup's list goes back to 2022, and includes forms it no longer runs on Studio. Responses stay on Studio until someone deletes them. Studio says responses fully deleted before September 30 were not exposed, and neither were responses sent while "save results to Studio" was switched off.
  • The chain can be long. Saitama Prefecture learned of it from the private company that runs its museum, which learned of it from Studio. Kyoto's data was held by a foundation running programs for the city.

None of these companies' own services were affected. Raksul, for example, says its printing site's members, orders and payments are not involved. The exposed data is what people typed into forms.

Reporting: the PPC asks for a pause#

Under Japan's privacy law, a breach caused by unauthorized access must be reported to the PPC and notified to the people affected, whatever the number of people, if personal data leaked or may have leaked. When the data was held by a contractor, both the client and the contractor are responsible, and they can file a joint report. We explain these rules in Japan's data breach notification rules.

On October 16, Studio told its form customers that, as the businesses that collected the data, they may need to report to the PPC and notify the people concerned. On October 17, it sent a second message: at the PPC's request, customers planning to report should hold their individual reports. Studio plans to discuss with the PPC whether it can collect them into one report filed jointly in the names of Studio and its customers. How the legal deadlines apply while reports are on hold will be confirmed with the PPC.

Studio stresses that only the PPC report is on hold. Notifying individuals is still for each customer to decide. Its portal gives customers a three-point checklist, citing the PPC's guidelines: was the form used for business, did responses contain personal data, and could they be affected. It reminds them that for unauthorized access there is no minimum number, so even one person may need to be notified. It also offers a template for a public notice.

The keys#

This is the third disclosure in a week in which encryption failed because the key was taken too, after SourceNext's member passwords and skyticket's old payment logs. Studio replaced its encryption key on October 17 and is re-encrypting older data. As it notes, that does not protect anything taken before.

The credentials matter more than the content in one respect: they open other systems.

  • API keys and tokens for external services, such as headless CMSs, were registered in Studio to pull content into sites. Studio cannot revoke them, because they were issued by those services. Customers have to issue new keys, switch Studio over, revoke the old ones, and check for unexpected use since September 30.
  • Google Sheets connections, used to send form responses to a spreadsheet: Studio replaced the connection key on October 14, but says the credentials and sheet IDs may have leaked, so a third party could have viewed or edited linked sheets until then. Viewing leaves no trace in a sheet's version history.
  • Proxy keys for customers serving Studio sites through their own reverse proxy or CDN: Studio has issued new ones, and disables each old key only after the customer confirms the switch, within 30 days.
  • Webhook URLs, such as Slack incoming webhooks, let anyone who knows them post messages to the customer's channel.

What we don't know yet#

Studio has not said:

  • Which feature was vulnerable, and how the attacker reached the data and the key
  • How many customers, form submissions and credentials are affected
  • Whether any stolen credentials have been used, on Studio or on the services they connect to
  • Whether the PPC will accept a joint report, and what happens to customers who already filed

Our analysis#

The contact form is part of the supply chain#

Most companies would not list their website contact form as a store of personal data. On Studio, it was one: every submission, for as long as nobody deleted it, sat in the website builder's cloud. Luup's oldest exposed form dates from 2022. In our view, this is the same lesson as in our analysis of app breaches and data minimization: data you have stopped using is still data you hold. Studio's own scoping makes the point. Responses that were fully deleted before the attack, or never saved because storage was switched off and they were forwarded by email instead, are outside this breach.

A third party moves the defense, not the responsibility#

Using a hosted website builder instead of running your own web server is often the right call for a small team: patching, hosting and defending the platform become the vendor's job. This breach shows the other side. When the vendor is breached, every customer is breached at once, learns about it from the vendor, and still carries the legal duty for the data its visitors sent. Saitama Prefecture and Kyoto show how far that duty can sit from the system that failed, two contracts away. We made this point about supply chain risk in our data minimization analysis, and Studio is a clear case: the question to ask a provider is not only how it protects your data, but what it holds, for how long, and what happens to your customers if it is breached.

Keys kept next to the data#

Encrypting form submissions and API keys was the right thing to do. Keeping the key where the same attacker could read it undid it. In our view, the pattern across SourceNext, skyticket and Studio is that encryption at rest is often designed against someone stealing a disk or a database dump, not against an attacker who gets into the running environment, where the application must be able to decrypt. Protecting against that needs the key held separately, in a key management service with its own access controls and logs, and an attacker who reaches the data store should not automatically reach the key.

A joint report is a sensible answer to a platform breach#

If every Studio customer with a form filed its own report, the PPC would receive a large number of near-identical reports about one incident, each based on what Studio told them. In our view, the PPC asking for a pause and a joint report is a practical response, and it may become a model for future breaches at shared platforms like ShopServe or i-ask. The risk is that notifying the people affected slows down while customers wait. Studio is right to say clearly that this part is not on hold.

What this means for readers#

  • If your company uses Studio: follow the per-feature emails sent on October 16. Rotate external API keys, re-link Google Sheets and remove Studio's access in the Google account first, swap proxy keys and confirm, replace webhook URLs, and change the passwords of protected pages. Check the connected services' logs from September 30.
  • If you collected personal data through Studio forms: decide on notifying the people who wrote to you; do not wait for the PPC report question to be settled. Then delete responses you no longer need.
  • Whatever builder you use: find out where your website forms store submissions, for how long, and who can delete them. If submissions are forwarded to email or a CRM anyway, consider turning off storage in the builder.
  • Treat third-party credentials as part of the vendor's risk. An API key you give a SaaS provider is only as safe as that provider. Give it the narrowest permissions the integration needs, so that a leak does not open more than it must.
  • If you sent an inquiry to a Japanese company recently, expect notices from companies you may not associate with Studio, and be wary of follow-up emails that ask you to click or log in.

Japanese terms at a glance#

Japanese Romaji Meaning
ノーコード nō kōdo No-code (building without programming)
フォームの送信内容 fōmu no sōshin naiyō Form submissions
復号に必要な鍵 fukugō ni hitsuyō na kagi The key needed to decrypt
連名で報告 renmei de hōkoku Joint report (filed in several names)
報告の保留 hōkoku no horyū Holding (pausing) a report
本人への通知 honnin e no tsūchi Notifying the person affected
指定管理者 shitei kanrisha Designated manager (private operator of a public facility)