When your website builder holds your API keys: the STUDIO breach

Published 2026-10-19

On 16 October 2026, STUDIO (studio.design), the no-code website builder widely used in Japan, published a notice of unauthorized access, updated on 18 October. A third party exploited a vulnerability in one of STUDIO's features and got into its cloud environment. The access confirmed so far ran from 30 September to 1 October 2026 (JST). STUDIO found it on 13 October and closed the entry point on 13–14 October. It hasn't confirmed that data was taken, but it is proceeding as if it was, and it has reported the incident to Japan's Personal Information Protection Commission.

STUDIO has more than 900,000 users, according to ITmedia. Most of them will read this as a password leak. For many, the bigger problem is their API keys.

What may have been exposed

• Account data: username, email address and hashed password.
• Design Editor and CMS content, form submissions and Live Preview URLs.
• Third-party API keys and tokens registered in API integrations (Data Connect and the API Connect beta).
• Google Sheets integration credentials, custom proxy keys, reCAPTCHA v3 settings and webhook notification URLs.
• Passwords for password-protected pages (hashed).

Some of these were stored encrypted, but the key needed to decrypt them was also accessed, so STUDIO says they may have been readable. STUDIO updated the Google Sheets integration key on 14 October and replaced the encryption key for form submissions and API keys on 17 October. Payment data is not on the list.

Why this is worse than a password leak

A website builder that pulls in content from other services has to hold the keys to them. If your STUDIO site reads articles from microCMS, calls OpenAI or works with Google through Data Connect, the key for each of those services was sitting in STUDIO. Whoever has a copy can use it against that service directly, without going near STUDIO.

Changing your STUDIO password does nothing for those keys. Each one has to be rotated at its own vendor: create a new key there, paste it into STUDIO, then revoke the old one. And the old key rarely lives only in STUDIO. The same value is often in a .env file, on a server or in a script on someone's laptop. Each of those copies needs the new key before the old one is revoked, or something else stops working.

What to do now

STUDIO asks customers to do the following. For most sites, the third step is where the work is.

1. Change your STUDIO password if you sign in with email, and change it anywhere else you used the same password.
2. Delete Live Preview URLs and issue new ones.
3. Rotate every third-party API key and token you saved in STUDIO. Create the new key at the vendor, paste it into STUDIO, update every other place that uses the same key, then revoke the old one. Check each vendor's logs and billing from 30 September for use you don't recognise.
4. Change the passwords of password-protected pages.
5. Google Sheets: stop the sync (Stop Sync), remove STUDIO from the linked apps in your Google account, and set the integration up again.
6. Custom proxy: switch to the new proxy key and tell STUDIO within 30 days of its 16 October email.
7. Change your webhook notification URLs.
8. Treat any request for your STUDIO password as phishing.

How FrontierStack helps

FrontierStack can't change anything inside STUDIO, but in its next update it tells you which of your sites are affected and keeps the job from being forgotten.

• It finds the sites built with STUDIO. Domain Health reads the generator tag on each home page, so a site built with STUDIO shows STUDIO as its host. Wix, Webflow and Framer are recognised the same way. When the builder has had a recent breach, the domain is marked "breached builder".
• It keeps the checklist in front of you. A banner on the Sites pane lists the affected domains with the vendor's steps as a checklist, and your progress is saved. A Security alert stays on until you mark the breach as dealt with.
• It reaches your iPhone. The alert goes to your paired iPhone through FrontierStack's push relay as a dedicated vendor-breach notification. The notification carries no content: no domain or key names leave the Mac.
• It answers "am I affected?" The AI Administrator has a read-only tool for vendor breaches, so you can ask which of your sites are involved.
• It hands over to KeyRotate. Check keys in KeyRotate… opens KeyRotate on that breach.
• It doesn't wait for an app update. New breaches arrive as advisories signed by Enfour and checked against a key built into the app.

STUDIO also has its own pane in FrontierStack. It watches STUDIO's public status page (Hosted Websites, Editor, Dashboard, Live Preview and Store) without any credentials and raises an alert when there is an incident. See STUDIO on a Mac.

How KeyRotate helps

KeyRotate keeps your API keys and knows which files and servers use each one. The next KeyRotate update adds the part this breach exposed: keys pasted by hand into a web service.

• Record where a key was pasted. Each key can list the web services you pasted it into: STUDIO, Wix, Webflow, Framer, Bubble, Zapier, Make, n8n Cloud, Vercel, Netlify and Retool. After a rotation, KeyRotate reminds you to paste the new key there.
• See what is still exposed. When one of those services is breached, every key whose value hasn't been replaced since the breach was contained is marked "Exposed in a vendor breach" at the top of Needs attention. Adding a key to KeyRotate after the breach doesn't count as replacing it.
• Rotate in one pass. A card on the Overview asks which of your keys you saved in STUDIO. Rotate exposed keys… then, after a single Touch ID, creates a new key for every exposed key whose vendor's API can issue one, and marks the files that use them (.env files, configs, servers) for update. Keys that can't be created this way get a link to the vendor's console.
• Old keys are left alone. KeyRotate never revokes an old key automatically, because STUDIO still holds it until you paste in the new one. You revoke it once your site works with the new key.
• Reminders until it's done. While a key stays exposed, KeyRotate sends a notification every three days, also to your own ntfy or Gotify server if you use one. STUDIO's other steps are a checklist on the same card.

There are limits. Neither app can write a key into STUDIO; that step is yours. KeyRotate can't know which keys were in STUDIO until you tick them. And not every vendor's API can create keys, so some rotations still mean a visit to the vendor's console. See what KeyRotate does.

The general lesson

Every service you paste a key into is another place that key can leak from. Three habits make the next breach smaller:

• Keep an inventory of where keys are pasted. Not just which keys you have, but which site builders, automation tools and hosting dashboards hold a copy. When one of them is breached, the list of keys to rotate is already written.
• Prefer scoped, restricted keys. A key that can only read one CMS, or only call one API with a spending limit, is worth much less to whoever copies it. Give a website builder a key made for that site, not the one your back office uses.
• Rotate on a schedule. A key that is replaced every few months has a short useful life once it leaks, and a rotation you already practise is one you can do quickly when it suddenly becomes urgent.

Further reading: why STUDIO users were hit harder than most (Matthew Ketchum, LinkedIn) and a write-up of the breach on Substack.