Studio No-Code Breach: Form Data, API Keys and the Decryption Key

Studio, the Japanese no-code website builder, says an intruder abused a flaw in its service on 30 September and 1 October 2026 and could read every customer's data, including the key that decrypts stored secrets. If you build on Studio, rotate connected API keys, webhooks, proxy keys and page passwords, and review your form data duties.

This post walks through what Studio and the organisations downstream of it have published so far, from Japan's Digital Agency to city governments and listed companies. It covers the minute level timeline, the exact data and credential types in scope, why "encrypted" did not help this time, the rotation order Studio recommends for each credential, how Japan's breach reporting rules apply to form owners, and what any team that relies on a hosted site builder can take from it. Every fact comes from the linked notices or is labelled as reporting.

What happened, in short

Studio published its first notice on 16 October 2026 and opened a dedicated incident portal on 18 October. The portal was last updated on 20 October at 12:30 JST when we fetched it. Studio's own description of the event is short. A third party exploited a vulnerability in "some features" of Studio, reached the cloud environment Studio uses, and put data inside that environment in a state where it could be retrieved from outside. That state lasted until Studio closed the access route on 14 October.

Studio has not named the feature, the type of vulnerability, the entry route or the attacker. It has not confirmed that data was actually taken. It says it is proceeding as though it was. In its words, the data is treated as "取得されたものとみなして" (regarded as having been obtained).

Three points make this incident heavier than a typical form leak:

1. The scope is every customer. Studio says all registered customers may be affected, not a subset of projects.
2. Secrets were in scope, not only content. Customers had pasted third party API keys, Google Sheets credentials, custom proxy keys and webhook URLs into Studio settings. Those are now treated as exposed.
3. The decryption key went with the data. Studio encrypted form submissions and several credential types, but says the key needed to decrypt them was read in the same unauthorised access. So the encrypted fields count as exposed too.

Studio also says the credentials the intruder obtained carried write permission. Studio invalidated them and reviewed their activity logs, and says it found no record of customer data being changed or deleted. An outside specialist firm is being arranged to investigate the root cause; no completion date has been given.

Timeline, to the minute where published

Times are Japan Standard Time (JST, UTC+9) with UTC alongside where a time was published. Dates without a time are as the source gives them.

Two gaps stand out. The intrusion ended on 1 October but was confirmed on 13 October, twelve days later. And customers learned about it on 16 October, two days after the fix. Studio has not explained how the access was discovered.

The Digital Agency, and why one vendor reached so many public bodies

The Digital Agency's 22 October release explains that Studio provided a service the agency used for part of its website operations. Studio notified the agency on 16 October. The agency lists inquiry form submissions received between May 2021 and March 2023, plus Studio account records, as possibly leaked:

The five form categories add up to 13,323. The agency did not publish a combined figure, and English language coverage rounded the number to "up to 13,000". Each figure is an upper bound while the scope is still being checked. The agency says names and emails were included only where people chose to enter them, and that no secondary damage had been confirmed when it published.

Local governments followed the same pattern. They rarely contracted with Studio directly. A prefecture's museum used it through its designated manager. A city's convention centre used it through the foundation that runs the venue. A ward's contest form was built by a contractor. That chain is why the tally kept growing for a week: each organisation had to find out whether someone working for it had built something on Studio.

Who is affected

Studio's position is simple: every registered customer may be affected, and the final per feature counts will come later. Downstream organisations have published their own figures. The table below lists only figures we read in each organisation's own notice.

piyolog, a long running Japanese incident tracker, counted 98 organisations that had announced impact or an investigation as of 20 October: 17 local governments (including Saitama Prefecture, Kyoto City, Gifu Prefecture, Fukuoka City, Niigata City and Wakayama City), 5 listed companies (Link-U Group, LiNKX, and US, Green Energy & Company and Schoo), 57 other companies and organisations (including Raksul, Luup, TVer and Omron) and 19 sole proprietors and small businesses. piyolog did not add up record counts, because organisations reported in different units: submissions, people or responses.

Two numbers that circulated widely are not in the table. Japanese reporting attributes 21,368 form submissions to Luup and 6,412 to Raksul. We could not read either company's own notice, so we leave those figures as reported, not confirmed.

Technical details

There is no CVE, no named vulnerable component and no published indicator of compromise for this incident. Studio has said nothing about the vulnerability class, the affected feature or the attacker's infrastructure, and it is withholding those details while the investigation is arranged. What defenders can work with is the precise inventory of what was in scope, the dates that bound log searches, and the identifiers that separate real Studio mail from phishing.

Incident identifiers and windows

Data in scope for every registered customer

The encrypted items Studio lists as readable because the key was also read are: form submissions, API keys and tokens, Google Sheets credentials, proxy keys, reCAPTCHA configuration and webhook URLs. The Fukuoka Convention Center's notice repeats the point in plain terms: submissions were stored encrypted, but the key needed to decrypt them was read in the same unauthorised access.

Credentials: what each one grants and who can kill it

Identifiers for spotting real Studio messages

Studio says legitimate mail comes from @studio.design, @studio.site or addresses listed in its email help article. Its incident emails never ask for passwords or credentials through links, and it does not ask for passwords or card details by phone. The login URL to check is app.studio.design. The no login support form lives at studiodesign.notion.site. Logged in users can open the help icon, then Messages, start a conversation and choose the topic for inquiries about the unauthorised access. Replies come on weekdays between 10:00 and 18:00 JST.

Do not confuse it with Studio's February 2026 report

Studio published a separate incident report on 20 February 2026. In that case, public CMS API responses included the email address, username and avatar URL of the Studio user who last edited a CMS item, from 13 December 2024 to 17 February 2026. A fix went out at 21:10 JST on 17 February and the CDN cache was purged at 21:21. Studio has not linked that issue to the October intrusion, and neither do we. We mention it only so that searches and SBOM style records do not merge the two.

How it works, in plain language

A hosted site builder is a multi tenant application. Thousands of customers design pages, collect form responses and connect other services from one shared platform. To make the connections work, customers paste secrets into the builder: a key for a headless CMS so a page can pull articles, a Google authorisation so form responses land in a sheet, a webhook so a new submission posts to chat, a proxy key so the builder trusts a customer's own reverse proxy.

The builder has to use those secrets on the customer's behalf, so it has to be able to decrypt them. That is the uncomfortable truth of any integration platform. Encryption at rest protects against someone who steals a disk or a database backup. It does not protect against someone who reaches the running environment that holds both the ciphertext and the key, or the credentials that can ask for the key.

Studio's notice says the second thing happened. The intruder reached an environment where the data and its decryption key were both readable, with credentials that could also write. Studio has not said how. It might have been a server side request flaw, an exposed internal endpoint, a misconfigured storage permission or something else entirely. We do not know, and guessing would not help anyone rotate a key.

What matters for customers is the consequence. A builder breach is not only a content leak. It is a leak of every downstream credential that customers trusted the builder to hold. One flaw in one vendor turns into many small exposures at many other vendors, each of which has to be closed by a different team at a different provider. That is a supply chain incident, even though no package was poisoned and no build was tampered with.

What to do now: detection and remediation, step by step

The steps below follow Studio's own guidance, in the order it recommends, with checks you can run yourself. Work through them for every Studio project, including projects built for you by agencies and contractors.

1. Find every Studio project you depend on

Edogawa City learned from its contractor four days after Studio's notice. Start by listing every site and form that might run on Studio, whoever built it.

# Look for Studio references in your public pages (a heuristic, not proof)
for site in www.example.jp campaign.example.jp; do
  echo "== $site"
  curl -s "https://$site" | grep -oE 'studio\.(design|site)[^"'\'' ]*' | sort -u | head -5
done

# Check where each hostname points; compare with the target in Studio's custom domain help
dig +short CNAME campaign.example.jp

# Search your repositories and docs for Studio links and embeds
git grep -n -E 'studio\.(design|site)' -- . ':!*.lock'

Then ask procurement, marketing and every agency you work with one direct question: "Did you build or run anything for us on Studio, and who holds the project owner login?" Studio sent its feature specific emails to project owners. If the owner is a contractor or a former employee, nobody on your side may have seen them.

2. Check the inbox that received Studio's email

Nagasaki City's release shows how easy this is to miss. Studio's email arrived at 11:04 on 16 October and sat unread until 20:30 on 18 October, after staff learned of the incident from the news. That is common: vendor mail lands in a shared mailbox or a personal inbox that nobody watches for security notices.

Search every mailbox that could own a Studio project for mail from @studio.design and @studio.site dated 16 October onward. The feature specific emails tell you which of your projects used API integrations, password protected pages, forms, the custom proxy and webhooks. In Gmail or Google Workspace search, for example:

from:(studio.design OR studio.site) after:2026/10/15

3. Rotate third party API keys in the right order

Studio is explicit that revoking first can break your site. Its order is:

1. Issue a new key or token at each connected service.
2. Update Studio: for Data Connect API, use the connection panel in the design editor; for the API integration (Beta) feature, edit the header key in the API settings.
3. Revoke the old key at the issuing service.

Then review each service's usage or audit history from 30 September onward for calls you do not recognise, and report anything odd to that service. Make each new key as narrow as the provider allows. A site that only reads published articles does not need a key that can write or delete them.

4. Reset the Google Sheets connection

Studio renewed its side on 14 October, but your Google account still lists Studio as a connected app. Studio's steps:

1. Disconnect the Sheets link in Studio's project settings.
2. Remove Studio's access in your Google account at myaccount.google.com/linkedapps. Google's help page notes that once access is removed, the app can no longer reach your account.
3. Reconnect if you still need Sheets. A new sheet is created.

Watch the side effects. Removing access stops sheet updates for every Studio project that used the same Google account. While disconnected, responses go to Studio's dashboard if "save to Studio" is on, or only to the notification email address if it is off, so check that address first. Workspace admins may need to approve the reconnection.

Then open each sheet's version history and look at 30 September to 14 October for edits you did not make. Workspace administrators can also review OAuth activity for the Studio app in the Admin console under Reporting, then Audit and investigation, then OAuth log events.

5. Replace the custom proxy key

If you serve a Studio site through your own reverse proxy or CDN using Studio's custom proxy feature:

1. Replace the key on your proxy or CDN. Studio says the site stays up during the change.
2. Confirm the site renders correctly.
3. Send Studio a proxy key revocation request through its contact form with your Studio subdomain. Do not include the key itself.

Studio changed its plan here. It first intended to revoke old keys automatically once it saw the new one; it now waits for your notice, and asks you to send one even if you already switched. The deadline is 30 days from the 16 October email.

To find where the old key lives without printing it to your terminal, search by a short prefix and list file names only:

# List config files that still contain the old proxy key (prints paths, not values)
OLD_PREFIX='first-8-chars-of-old-key'
grep -rIl -F "$OLD_PREFIX" /etc/nginx /etc/caddy /etc/haproxy 2>/dev/null
# Also check your CDN configuration as code and deployment variables
git grep -l -F "$OLD_PREFIX"

6. Replace webhook URLs

1. Create a new URL at the destination. For a Slack Incoming Webhook, create a new one for the channel.
2. In Studio, go to Home, then Project settings, scroll to Webhook, enter the new URL and run a test send.
3. Disable the old URL at the destination.

If you no longer use webhooks, clear the URL in Studio and still disable the old one. Look for unexpected notifications since 30 September, and do not open links inside suspicious ones. You can confirm a new Slack webhook works with a plain test post:

curl -s -X POST -H 'Content-type: application/json' \
  --data '{"text":"Studio webhook rotation test"}' "$NEW_SLACK_WEBHOOK_URL"

7. reCAPTCHA v3, page passwords and preview links

Studio does not require a reCAPTCHA v3 secret rotation, because the secret alone cannot read form data. If you see failures or unusual usage and decide to rotate, create the new key with your public domain and preview.studio.site, update Home, then Apps, then Google reCAPTCHA v3 in Studio, test on live preview and on the public site, and only then delete the old key. Update any other sites that share the same key.

Change the password on every password protected page and send the new one to the people who need it. Delete every issued live preview URL and issue a new one only if you still need to share an unpublished page.

8. Studio account passwords

Change your Studio password if you sign in with email and password. If you only ever used Google or Facebook sign in, Studio says no action is needed; if you once set a password, reset it from the login screen. Change the same password anywhere you reused it.

9. Embedded external forms

Standard embed codes for third party forms contain only public URLs, but if you pasted any secret, token or API key into embed code inside Studio, rotate it with that provider.

10. Decide on reporting and notification

This is the step most site owners outside Japan have never had to think about, and it is covered in its own section below. Studio's guidance asks three questions: did you use the forms for business or organisational activity (sole proprietors and nonprofits included), did responses include personal data such as names, contact details or free text, and could this incident affect those responses? Studio's reading is that notification may be required even if only one person is affected.

11. Reduce what is stored, then prepare for phishing

Several organisations deleted their stored inquiry data from Studio after exporting what they needed: Todoker and Nagasaki City both say they did, and Nagasaki City also removed the form from its campaign site. Studio's scope includes trashed submissions and responses hidden by plan limits, which many owners did not know were still stored. Review retention settings and turn off storage you do not need.

Finally, warn the people who filled in your forms. Their names, emails and messages are exactly what a convincing phishing email needs. You can check the sending domain policy for Studio's mail before you write guidance for your own users:

dig +short TXT _dmarc.studio.design
dig +short TXT studio.design | grep -i spf

Japan's reporting rules for form owners

Every organisation that collected personal data through a Studio form is, in Japanese law, the business handling that data. Studio is the service provider. So the reporting duty under the Act on the Protection of Personal Information (APPI) sits with the form owner, which is why the Digital Agency, prefectures, cities and companies all published their own notices.

The PPC's guidance lists four categories of private sector leaks that must be reported:

The third category matters here. Studio describes unauthorised access by a third party, which falls under the unauthorised purpose category regardless of how many people are involved. That is consistent with Studio's comment that a single affected person may be enough.

The PPC's timing targets are a preliminary report promptly, with 3 to 5 days from discovery as the guide, and a final report within 30 days, or 60 days for the unauthorised purpose category. Studio's handling adds a twist. On 17 October it asked customers to hold individual reports at the commission's request. On 20 October, after consulting the PPC, it set out two options:

• Individual report. You report yourself, at any time. Reports already filed stand, and you can switch to the joint route later without filing your own final report.
• Joint report. Studio compiles and submits the report with you. Studio will announce the application method and deadline. For this incident only, a joint report filed by the agreed method will not be treated as late even if it misses the preliminary report window.

The joint route covers only the report to the PPC. It does not cover notifying the people whose data you hold. That decision stays with each form owner. Studio's guidance says a public announcement may substitute if you cannot reach people directly, and links a press release template. It also suggests that owners point their users to the site user section of its incident page for background.

If you are outside Japan but collected data from people in Japan through a Studio form, take local advice. The questions are the same everywhere: who is the controller, what was exposed, and what does your regulator expect and when.

What changed since the first reports

• Scope of encryption. The 16 October notice already said encrypted items could be exposed because the decryption keys were read. Downstream notices, such as the Fukuoka Convention Center's, now quote this directly to their own users.
• Key rotation. On 17 October Studio switched the encryption key for form submissions and external API keys and replaced credentials used for customer data, payments and login. Older data is being re-encrypted. Studio is clear that rotation cannot protect data already taken.
• Proxy key process. The plan to revoke old proxy keys automatically was replaced by a request based process with a 30 day deadline.
• reCAPTCHA guidance. Added on 18 October: rotation is optional, with a safe order if you choose to do it.
• PPC reporting. The 17 October hold on individual reports was lifted on 20 October and a joint reporting route was added.
• Downstream disclosures. From a handful on 16 October to 98 organisations by 20 October in piyolog's count, then the Digital Agency on 22 October.

Open questions

• Which feature, and what kind of flaw? Studio has not said. Without that, no other platform can check whether it shares the weakness.
• How was it found? The confirmation came twelve days after the window closed. Studio has not said whether an alert, a log review or an outside report triggered it.
• Was data actually taken? Studio has not confirmed exfiltration. It is treating the data as taken, which is the right posture for customers too.
• Final counts. Studio says per feature counts will follow. Until then, every customer should assume its own data is in scope.
• Root cause and prevention. The outside investigation was still being arranged at the last update, with no date for findings or prevention measures.
• Secondary harm. Studio is still checking for misuse of logins or data. Downstream organisations, including the Digital Agency, report none confirmed so far.

What would have helped

Nobody outside Studio can say what would have stopped this specific intrusion, because the flaw has not been described. What the incident does show clearly is how one platform's exposure spread to its customers, and that has lessons for both sides.

Practices any team can use

If you build sites or collect data on a hosted builder:

1. Keep a vendor list that includes what you pasted into each vendor. Not just "we use Studio" but "this project holds a read key for our CMS, a Sheets connection under this Google account, and a webhook into this channel". On a breach day that list is your rotation plan.
2. Include contractors' work. Edogawa City and the Saitama museum both learned through intermediaries. Contracts should require agencies to tell you which platforms hold your data and to forward vendor security notices the same day.
3. Route vendor security mail to a watched address. Make the project owner a shared, monitored mailbox, not one person. Nagasaki City's two day gap came from a single unread message.
4. Give integrations the narrowest key the provider offers. A read only, single space key for a CMS limits what a leaked key can do. Expiring tokens are better than static ones where the provider supports them.
5. Store less. Turn off "save to Studio" style storage when responses already go to email or another system, empty the trash, and set a retention period. Submissions from 2021 do not need to sit in a site builder in 2026.
6. Treat webhook URLs as secrets. Anyone who knows one can post to your channel.
7. Practise the rotation. Studio's "new key first, revoke last" order is easy to follow when you have done it once before.
8. Know your reporting duties before you need them. Form owners in Japan had to decide quickly between individual and joint reporting, and whether to notify people directly.

If you run a platform that holds customers' secrets:

1. Separate the key from the data. Keep encryption keys in a dedicated key service and make every decrypt a logged call with tenant context, so an attacker who reaches application storage does not automatically get readable secrets, and so you can tell each customer exactly which values were decrypted.
2. Split read and write credentials. Studio's notice says the stolen credentials could write. Service accounts that only need to read should not be able to.
3. Make revocation possible on your side. Studio cannot revoke third party API keys its customers pasted in. Where the downstream service supports it, OAuth style connections with platform side revocation are easier to kill in bulk than pasted static keys.
4. Notify by project, with the exact credential list. Studio's per feature emails are a good model. Sending them to more than one address per organisation would close the Nagasaki style gap.
5. Shorten detection. Twelve days between the end of access and confirmation is a long time for credentials to sit in someone else's hands.

Where Safeguard fits

Be clear about the limits first. This incident happened inside a SaaS vendor's cloud environment. Safeguard does not run inside Studio or any other site builder, does not hold or rotate the keys you pasted into it, and cannot tell you whether your form data was read. We do not claim it would have prevented or detected this breach.

Where Safeguard does help is on your side of the line:

• A vendor and risk register. Safeguard's compliance suite (GA) includes Vendors and Risks views, so the list of platforms that hold your data, and what each one holds, lives in one place with owners attached rather than in someone's memory. After an incident like this, the first question is which projects use the affected vendor; a maintained register answers it in minutes.
• Knowing what you build and ship. SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version. Many teams run their own reverse proxy, form handlers or webhook receivers next to a builder; those you build yourself are in scope.
• Approved changes during rotation week. Rotating a proxy key in your CDN configuration, moving a hard coded token in an embed to an environment variable, or updating a webhook receiver are small, careful edits. The Safeguard CLI's assistant can make them and run commands with your approval, and /permissions offers Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec runs in CI. The desktop and phone apps can send work to a computer running the CLI and approve each command.
• Policies and gates. Policies evaluated in the platform at build, CI and release keep known vulnerable components out of the services you run yourself.

Zero-Day Discovery and Gold

There is no CVE here and no known vulnerable open source package. Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, issues findings as SGZ advisories before they reach public CVE databases, and covers seven package ecosystems. A SaaS vendor's private cloud environment is outside what it looks at, and we make no claim that it found anything related to this incident.

Gold Open Source (gold.safeguard.sh) is free CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh) supplies hardened, Sigstore signed components and container images held to zero exploitable critical or high CVEs with SLSA L3 or higher provenance. Neither has a record tied to this incident. The habit they support still applies to the parts you own: if you rebuild a proxy or a form handler while rotating keys, rebuild it from patched, signed components rather than whatever image was cached.

Common mistakes

• Revoking the old key first. Studio warns that revoking before updating Studio can take your site down. New key, update, then revoke.
• Deleting the old reCAPTCHA key first. Same problem, same fix. And remember other sites that share the key.
• Assuming encrypted means safe. Studio says the decryption key was read too. Treat every encrypted field in its list as plaintext.
• Forgetting the side effects of unlinking Google. Removing Studio's access stops Sheets updates for every Studio project on that Google account, not just the one you meant.
• Missing stored data you thought was gone. Trashed submissions that were not permanently deleted, test submissions from live preview and responses hidden by plan limits are all in scope.
• Looking only at your own Studio account. Contractor built sites and forms run by designated managers are still your data and possibly your reporting duty.
• Assuming fewer than 1,000 people means no PPC report. Unauthorised access is its own reporting category under the PPC's guidance.
• Reading the joint report as covering notification. It covers only the report to the PPC.
• Skipping the proxy revocation request because you already switched. Studio asks for the notice anyway, within 30 days of its email.
• Pasting the old proxy key into the support form. Studio asks for your subdomain, not the key.
• Trusting a link in a "Studio" email. Go to app.studio.design directly. Studio's incident mail does not ask for credentials through links.

FAQ

What is the Studio breach?

Studio Inc., which runs the no-code website builder at studio.design, disclosed on 16 October 2026 that a third party exploited a flaw in part of its service between 30 September and 1 October, reached its cloud environment and could retrieve data there until Studio's fix on 14 October. Studio treats all registered customers' data as possibly taken.

Was the data actually stolen?

Studio has not confirmed exfiltration. It says it is proceeding as if the data was obtained, and customers should do the same. Downstream organisations, including the Digital Agency, say no secondary damage has been confirmed so far.

Why does it matter that the decryption key was read?

Studio encrypted form submissions and several credential types. It says the key to decrypt them was read in the same unauthorised access, so encryption gives no protection for that data in this incident. Any value in its encrypted list should be treated as readable.

I only use Studio to publish a simple page. Do I need to do anything?

Change your Studio password if you use one, delete live preview URLs, and watch for phishing. If your project has forms, API integrations, Google Sheets, webhooks, a custom proxy or password protected pages, follow the steps for each.

Which credentials does Studio rotate for me, and which do I have to rotate?

Studio renewed its Google Sheets connection keys, switched the encryption key, and replaced credentials it uses for customer data, payments and login. It revokes old proxy keys after your request. It cannot revoke third party API keys and tokens, webhook URLs or reCAPTCHA keys; those are controlled by the issuing services, and you have to rotate them.

What did the Digital Agency lose?

The agency lists inquiry form records from May 2021 to March 2023 in five categories with a combined maximum of 13,323 records, plus 35 Studio account records of staff and contractors. Fields include names, email addresses and inquiry content, and for some categories phone numbers, affiliations and shipping addresses.

How many organisations are affected?

Studio says every registered customer may be affected and has not published a number. piyolog counted 98 organisations that had announced impact or an investigation as of 20 October, including 17 local governments and 5 listed companies.

Do I have to report to Japan's Personal Information Protection Commission?

If you collected personal data through Studio forms for business or organisational purposes, probably. Unauthorised access is a reporting category regardless of the number of people. You can report yourself or join Studio's joint report, which will not be treated as late if filed by the agreed method. Notifying the affected people is a separate decision that stays with you.

Is Studio safe to use now?

Studio says the vulnerability is fixed, the access route is closed, the stolen credentials are invalid and the encryption key has been replaced. The outside root cause investigation has not reported findings. Whether to keep using the service is a vendor risk decision; whatever you decide, rotate everything you connected and store less in it.

Fix it without waiting for upstream

Studio's breach is not a dependency vulnerability, and nothing below rotates a key you pasted into a site builder. But the proxies, form handlers and webhook receivers you run next to a builder are code you ship, and a rotation week is a good moment to make sure they are current too.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows Studio, this breach or any customer's data, and none of them rotates a credential at a third party service for you.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with your approval, prints a summary and pushes nothing. For the Studio incident, you would open the CLI in the repository that holds your reverse proxy or CDN configuration and ask it to find every file that references the old proxy key by name, switch them to read the new key from an environment variable, and run your config tests. Every edit and command waits for your approval.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a folder choice, and Approve or Deny on each command and file edit, ending with the upgrade done and tests passing. Here you would pick the folder for a webhook receiver or form handler that sits next to your Studio site, ask it to point at the new webhook URL or move a hard coded token into configuration, and approve each change yourself before you deploy.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session: work sent to a computer running the CLI, and the command approved on the phone with Allow once, Allow for turn or Deny. Rotation after a builder breach is spread across many small systems and often many people; this lets the person who owns each one approve each scripted step from wherever they are, without granting open ended permission.

Click through it at your own pace, or open it full screen.

To try it on your own systems, download Safeguard and read the CLI documentation. For related reading, see the Railway preliminary report on CI credentials and AI key theft, are environment variables on hosting platforms safe for secrets?, what the IDCF Cloud ransomware incident teaches about third party risk and October 2026 security incidents and what would have helped.

Quick check

Sources

• Studio: Unauthorised access incident portal (Japanese) (primary)
• Studio: First notice on the unauthorised access, 16 October 2026 (Japanese) (primary)
• Studio: Notice to customers using the form feature (Japanese) (primary)
• Studio: Security incident report, February 2026 (Japanese) (primary)
• Digital Agency: Possible leak of personal information due to unauthorised access at Studio Inc. (Japanese) (primary)
• Saitama Prefecture: Possible personal data leak following unauthorised access at Studio Inc. (Japanese) (primary)
• Fukuoka City and Fukuoka Convention Center: Possible leak of personal data (Japanese, PDF) (primary)
• Nagasaki City: News release on a possible personal data leak (Japanese, PDF) (primary)
• Edogawa City: Press release, 21 October 2026 (Japanese) (primary)
• Link-U Group: Timely disclosure, 16 October 2026, via Nikkei (Japanese) (primary, title and time only)
• Todoker: Notice on the Studio unauthorised access (Japanese) (primary)
• FoundingBase: Notice on the Studio unauthorised access (Japanese) (primary)
• Fuller: Apology and request regarding the Studio unauthorised access (Japanese) (primary, title only)
• Simpleform: Possible leak of inquiry information via Studio (Japanese) (primary, title only)
• Personal Information Protection Commission: Responding to leaks (Japanese) (primary)
• Google Account Help: Remove third party access from your Google Account (linked apps)
• piyolog: Summary of the Studio unauthorised access, 20 October 2026 (Japanese)
• Internet Watch: Digital Agency report on the Studio incident (Japanese)
• SB Creative Business+IT: Report on the Digital Agency announcement (Japanese)
• Tokyo Reporter: Digital Agency admits up to 13,000 personal records leaked in cyberattack

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.