Part 9 of a series on Japan’s cybersecurity blind spot. Start with the overview, Japan cyberattacks in 2026: what the breach wave reveals, or read the previous part, Doing something isn’t the same as fixing it.

Most companies think of their website as a brochure. A nice one, maybe, with good fonts and a contact form. Nothing anyone would bother stealing.

On 16 October, Studio told its customers otherwise. Studio (Studio株式会社, sold internationally as Studio.Design) is one of Japan’s most popular no-code website builders, with more than 900,000 users, most of them startups and small businesses. Its first notice says an attacker used a vulnerability in one of its features to get into its cloud environment on 30 September and 1 October. The data inside stayed reachable from outside until 14 October.

Studio says the information of every registered customer may have leaked. That covers accounts and hashed passwords, site content, and everything visitors typed into forms. It also covers the API keys and tokens customers had connected to other services, Google Sheets credentials, proxy keys, webhook URLs, and the passwords for password-protected pages.

Most of that was encrypted. It didn’t matter. The key needed to decrypt it was read in the same attack.

To be fair to Studio, its disclosure is clearer than most I’ve read this autumn. It has an English version and an incident portal with a long FAQ that says what it knows, what it doesn’t, and what each customer has to do. But the shape of this breach is worth studying, because almost every small company in Japan has one like it waiting.

What people are saying

The reaction in Japanese has been loud, and it splits into a few camps.

The first is plain alarm at the scope. On Hatena Bookmark, where ITmedia’s report was bookmarked 78 times, readers singled out the API keys rather than the personal data, because keys can open servers and run up bills. One summed it up as encryption that failed because the decryption key went too, “a no-code nightmare.”

The second is web agencies and freelancers. Many built client sites on Studio, and their feeds are now full of incident notes, client-by-client checklists, and replacement forms. Some are using the moment to move clients to other platforms. Others point out, correctly, that WordPress sites get breached all the time too.

The third is confusion over who reports what. On 16 October Studio told form customers they might need to report to Japan’s Personal Information Protection Commission (PPC). On 17 October, at the PPC’s request, it asked them to hold those reports while it works out a joint filing. Some had already filed. Entrepreneur Kensuu asked publicly whether his company had to notify everyone who had ever used its form, including people who had sent spam or threats.

The fourth, a minority, is praise for the disclosure itself. Several people said Studio’s FAQ was the clearest breach explanation they’d seen this year, and contrasted it with companies that still won’t say how passwords were stored.

All four camps are reacting to real things. None of them quite gets to the part that matters most for the companies affected.

A contact form is a database

Nobody thinks of a contact form as data collection. It is. Every name, phone number, company and free-text message gets stored somewhere, and on Studio, responses stayed on the platform unless someone went in and deleted them.

Scooter-sharing company Luup reported 21,368 form submissions going back to February 2022, including submissions to forms it had since moved to other systems. The Luup app itself wasn’t touched. What leaked was years of old enquiries nobody needed anymore and nobody had cleared out.

I wrote about this in Part 5: data you no longer need is pure liability. It earns you nothing and costs you everything when someone else’s system breaks. ShopServe, an e-commerce platform run by E-Store, just reported 23.36 million people affected across 7,858 shops, including shops that had already left. PFU stopped using it in October 2025. Its customers’ data was still there.

The keys open other doors

Form data is bad. Credentials are worse, because they don’t stay inside the breach.

If you connected a headless CMS, a spreadsheet or a chat channel to your Studio site, you handed Studio a key to that system. Studio can’t revoke those keys, because it didn’t issue them. Every customer has to go to each connected service, issue a new key, switch it over, kill the old one, and check the logs back to 30 September. A chat webhook URL is often all it takes to post messages into a company channel. A spreadsheet credential may reach whatever that sheet holds.

The slow part of rotation isn’t issuing the new key. It’s finding every place the old one was pasted: the site builder, a .env file on a server, a cron job, a colleague’s laptop. Miss one and the old key stays alive, or something breaks the moment you revoke it. For keys that live on Macs and servers, KeyRotate, a Mac app from Enfour, the Tokyo company behind FrontierStack, does that part for you. It keeps keys in the macOS Keychain, gets a replacement straight from vendors whose APIs can issue one, checks the new key works before saving it, and updates every config file that used the old one. It deliberately leaves the old key valid until you’ve confirmed nothing still uses it, then reminds you to revoke it. No customer-side tool would have stopped the Studio intrusion. What a tool like this shortens is the cleanup afterwards, which is where most companies lose days.

Then there’s the encryption. Encryption that lives next to its own key is a locked door with the key taped to it. It looks like security in an audit. It isn’t security in a breach.

Read access was the good news

Studio’s FAQ adds one detail most coverage missed. The credentials the attacker got included write permission. Studio says it has invalidated them and found no record of any changes or deletions. I believe them, and that’s the good outcome.

Now think about the other outcome. A platform that can edit hundreds of thousands of sites can also change a form’s destination, or add a convincing login page, under each customer’s own brand and domain. Nothing suggests that happened here. But that’s the real size of the risk when you hand one platform your website, your forms and your keys, and it belongs in the decision before you sign up, not after.

Nobody filled in a form on Studio

Here’s what makes this kind of breach so slow to reach the people affected. Nobody who filled in those forms knew Studio existed. They wrote to a scooter company, a printing service, a museum.

A low timber building with a planted green roof at the end of a gravel path, surrounded by trees, the entrance to Saitama Midori no Mori Museum
Saitama Midori no Mori Museum, photographed in 2008. Its event and enquiry forms ran on Studio, and 162 records may have leaked. Photo: Nyao148, Wikimedia Commons, CC BY-SA 3.0.

Saitama Prefecture found out from the private company that runs its nature museum, which found out from Studio. The City of Kyoto found out from a foundation that runs two culture programs for it. Studio emailed the foundation at 10:41. The foundation told the city at 13:20. Every link in that chain is a delay, and every delay is time a phishing email can get there first.

The PPC reporting pause makes the same point from the other side. Telling the people affected isn’t on hold, but you can see how quickly responsibility gets spread thin when one vendor sits under thousands of brands.

The fastest fix was the right one

Calil runs the website for Japan’s bookstore stock information project. It got Studio’s email at 10:42. By 11:29 it had deleted every stored form response and stopped taking new ones. By 11:54 the site was running somewhere else. By 13:40 all 48 affected people had an email.

Three hours. Not because Calil had a bigger budget or a fancier firewall, but because it knew exactly what was stored, where, and why. In Part 8 I asked whether a response would have stopped what actually happened. Calil’s answer matched the failure: the exposure was stored responses, so it deleted them, and now there’s nothing left there to leak.

This isn’t a Studio problem

It would be easy to read this and decide the answer is “don’t use Studio.” Moving platforms doesn’t fix anything if you bring the same habits with you. A survey of about 5,300 cloud services published this month found that 45% don’t offer customers multi-factor authentication, 35% let staff into their own admin consoles with just a password, and only 53% let customers see their own access logs. Those are the vendors’ own answers, so the reality is unlikely to be better.

Every small company in Japan now runs on a stack like this: a site builder, a form tool, a newsletter service, a CRM, a booking system, a few spreadsheets, all wired together with keys someone set up years ago. Nobody has a list. That’s the real exposure, and it was there before Studio and it’ll be there after.

What to do this week

  • If you’re on Studio, follow its per-feature emails today. Rotate every external API key and token, re-link Google Sheets after removing Studio’s access in your Google account, replace webhook URLs, change protected-page passwords, and delete live preview URLs.
  • Check the connected services’ logs back to 30 September. Look for logins, key use, and spending you don’t recognize.
  • Find out where your forms store responses. If they’re already forwarded to email or a CRM, switch off storage in the builder.
  • Delete old submissions you don’t need. Set a retention period and put it in the calendar.
  • Decide how you’ll notify the people who wrote to you. The PPC report is on hold. Notifying the people affected isn’t.
  • List every service your website talks to, and every key or login it holds for something else. Give each key the narrowest permission that works, an expiry date, and a spending limit where the service offers one. Keep a record of where each key is used, so the next rotation takes minutes, not days.
  • Turn on multi-factor authentication everywhere it’s offered, and ask vendors who don’t offer it why not.

If you want to know what’s exposed

The list above is the one almost nobody has written down. My external exposure check looks at up to three of your domains the way an outsider would, using only what anyone on the internet can already see: email authentication, DNS, your website platform and versions, public login pages, and certificates. No login attempts and no probing. You get a written report ranking what to fix first within five business days, and a 30-minute debrief. If you’d rather start on your own, the Domain Exposure Check gives you a free outline in a few minutes. If the bigger question is which vendors hold what, the Diagnostics review maps that. The disclosed incidents, listed by supplier, are on the Japan supply chain cyberattacks map.

Sources