TL;DR
- 01何が起きたか
2026 年 9 月 30 日から 10 月 1 日にかけて、ノーコード Web 制作サービス「Studio」を運営する Studio 株式会社のクラウド環境に、第三者が一部機能の脆弱性を突いて侵入した。流出した可能性があるのは、全登録ユーザーのアカウント情報（ハッシュ化パスワードを含む）、フォームの送信内容、外部サービスの API キーやトークンなどで、暗号化データの復号に必要な鍵も、同じ不正アクセスで読み出された。Studio は 10 月 16 日に第一報を公表し、10 月 18 日に更新した。
- 02なぜ預けた側に見えないか
暗号化して保存していても、それを開く鍵が同じ環境から読み出されれば、中身は守られない。Studio は「取得された事実は確認できていないが、取得されたものとみなして対応する」としている。下流では、Link-U Group、ラクスルなど、Studio で自社サイトを運営する企業の問い合わせ・フォーム情報に波及した。預けた側には、何が読まれたかを自ら確かめる記録が無い。影響件数は、Studio が続報で公表するとしている。
- 03欠けていた層
確認してからの対応は速かった。Studio は 10 月 13 日に社内調査で侵入を確認し、13〜14 日に脆弱性を修正している。ただし、確認は不正アクセス（9 月 30 日〜10 月 1 日）から 12〜13 日後である。効かなかったのは、預けられたデータ、鍵、外部連携の資格情報が、読み出される時点で「許された主体・範囲か」を確かめる層である。
何が起きたか
- サービス
- Studio（ノーコードの Web サイト制作プラットフォーム）。利用企業は、サイトのデザイン、CMS のコンテンツ、フォームの送信内容、外部サービスとの連携設定を Studio のクラウドに預けている。
- アクセスの性質
- 第三者が Studio の一部機能の脆弱性を突き、クラウド環境にアクセスして、外部からデータを取得できる状態にあった（Studio の公表）。脆弱性の種別と入口は、公表されていない。
- 期間
- 現時点で確認された不正アクセスは 2026 年 9 月 30 日から 10 月 1 日（JST）。Studio は、この状態が 10 月 14 日に対処するまで続いたと説明している。
- 対象となりうる情報
- 全登録ユーザーのユーザー名、メールアドレス、ハッシュ化パスワード。デザインエディタと CMS の内容、フォームの送信内容（ゴミ箱内、テスト送信、プラン上限超過分を含む。添付ファイルはファイル名のみ）。reCAPTCHA v3 の設定、Webhook URL、ライブプレビュー URL。外部サービスの API キーとトークン、パスワード保護ページのパスワード、Google Sheets 連携の資格情報、カスタムプロキシのキー。Studio AI の早期アクセス申込者（2022 年 12 月〜2023 年 8 月）のメールアドレス、ユーザー名、推定の国（アカウントを持たない人を含む）。
- 鍵の読み出し
- 暗号化されたデータの復号に必要な鍵が、同じ不正アクセスで読み出された。このため、フォームの送信内容、外部サービスの API キーとトークン、Google Sheets 連携の資格情報、カスタムプロキシのキー、reCAPTCHA v3 の設定、Webhook URL は、暗号化して保存していたものも内容を知られた可能性がある（Studio）。
- 確認されていないこと
- データの実際の取得、改ざん、削除。二次被害は調査中。影響を受けるユーザー数と件数は、未公表。
用語メモ
復号鍵 — 暗号化したデータを元に戻すための鍵。鍵を持つ者は、暗号化して保存したデータの中身を読める。
API キー・トークン — 外部のサービスに、自分の代わりに接続するための文字列。持っている者は、そのサービスに正規の連携として接続できる。
Webhook URL — フォームの送信などが起きたときに、通知を送る先の URL。知られると、通知先に偽の通知を送られることがある。
取り返しがつかなくなったのは ② と ③。預けたデータと、それを開く鍵が、同じ環境から読み出せる状態にあった。② の入口は公表されていない。
暗号化して保存されていたものもある。
9 月 30 日〜10 月 1 日。入口は非公表。
暗号化していたものも、内容を知られた可能性がある。
10 月 13 日に確認、13〜14 日に修正。
読み出しの時点で、誰の権限で、どの範囲が読まれたかを、預けた側が確かめる手段は示されていない。
時系列 — 公表と対応
- 10-01 にかけて不正アクセス（現時点で確認された期間）。
- Studio が社内調査で侵入を確認。
- 10-14 にかけて脆弱性を修正し、侵入経路を遮断。
- 外部から取得できる状態が終了。Google Sheets 連携の鍵を更新。
- 第一報を公表。影響を受けうるユーザーにメールで通知。Link-U Group（適時開示）、ラクスルなど、利用企業が同日以降に告知。
- 暗号鍵を新しい鍵に切り替え。フォームのユーザー向けに個人情報保護委員会への報告を案内。
- 更新を公表。Google Sheets とカスタムプロキシの手順を更新し、reCAPTCHA v3 の扱い（シークレットキーの一律の差し替えは求めない）を追記。
本件の事実は、Studio の公式告知（2026-10-16 第一報、10-18 更新）と、利用企業の公式発表に拠る。侵入の入口（どの機能のどの脆弱性か）、実際に取得されたデータ、外部の調査機関の結論は、公表されていない。「12〜13 日後」は、確認された不正アクセスの期間（9 月 30 日〜10 月 1 日）と社内調査での確認日（10 月 13 日）の差であり、確認の契機は公表されていない。
利用企業への波及
- Link-U Group: 企業サイトの問い合わせフォームで収集した個人情報 7,663 件（2026-10-16 時点）。流出は確認していないが、可能性を否定できない。グループのサービスは影響なしとしている。
- ラクスル: Web サイトのフォームの送信 6,412 件（2024-06-03〜2026-10-15）。氏名、組織名、電話番号、メールアドレス、問い合わせ内容など。会員情報、注文情報、決済情報は対象外。件数は、個人の数と一致しない可能性がある。
公表後の対応
- 鍵と資格情報の入れ替え: 暗号鍵を 10 月 17 日に新しい鍵に切り替え、以前に保存したデータの再暗号化を進めている。第三者が取得した、データを書き換えられる権限を含む認証情報を無効化し、その認証情報による操作の記録に、デザインエディタや CMS の内容の変更・削除が無いことを確認している（10 月 18 日時点）。
- 利用者への依頼: Studio のパスワード変更（Google・Facebook のみでログインする場合は不要）、再利用パスワードの変更、ライブプレビュー URL の削除（必要なら再発行）。機能ごとに個別のメールで、API 連携のキーの切り替え、パスワード保護ページのパスワード変更、Google Sheets の再連携、カスタムプロキシのキーの差し替え、Webhook の通知先 URL の切り替えを案内している。
- 報告と調査: 個人情報保護委員会などへの報告を進めている。外部の専門機関による調査を手配中。
なぜ止まらなかったか
この事案の失敗は、利用企業の管理の誤りではない。多数の企業が、サイトのデータ、フォームの送信内容、外部連携の資格情報を 1 つの委託先 SaaS の環境に預け、その環境が一度侵害されると、預けた側の誰も、何が読まれたかを確かめる手段を持たないことにある。
暗号化したデータを開く鍵が、データと同じ環境から読み出せた。
検出と証明の落差は、ここにある。確認してからの対応は速かった。Studio は侵入を確認し、2 日以内に脆弱性を修正した。ただし、確認は不正アクセスから 12〜13 日後である。効かなかったのは、その手前である。「データが暗号化されている」ことと、「そのデータを開く鍵が、データと同じ環境から読み出せない」ことは別の事実であり、本件では鍵も同じ侵入で読み出された。暗号化は、鍵が同じ環境にある限り、読み出しの権限を持つ者に対しては取得を止めない。
Studio の「取得されたとみなして対応する」という判断は、誠実である。ただし、その結果、預けた側は、何が取得されたのかを確認できないまま、全件を対象に、パスワードの変更、鍵の入れ替え、通知を行うことになる。Studio 自身が取得の有無を確認できておらず、Link-U は「漏えいの可能性を否定できない」、ラクスルは「漏えいした可能性がある」と書くにとどまる。預けた側には、何が読まれたかを自ら確かめる記録が無い。
同じ構造は、これまでの Brief にも現れている。Sumsub では、識別ベンダーの支援環境が 18 か月、気づかれなかった。Salesloft Drift では、1 つの連携の OAuth トークンが盗まれ、700 超の Salesforce 環境が参照された。いずれも、預けた側から見えない委託先の環境で、読み出しの時点に独立した確認が置かれていない。
「暗号化した」と「その鍵が読み出せない」は、別々の事実である。前者は保存の時点に記録され、後者は読み出しのたびに確かめなければならない。
対策するには
委託先の環境で何が読まれたかは、いまの仕組みでは預けた側から確かめられない。だから、預けていた鍵や資格情報は読まれた前提で入れ替え、次は、読まれても範囲を言える預け方を求める。利用企業の側ですぐできるのは、Studio の案内に沿って、預けていた API キー、Webhook の通知先、パスワード保護ページのパスワードなどを入れ替えることと、フォームで集めた個人情報について自社の影響を確かめることである。委託先の側では、鍵をデータと同じ環境から読み出せないようにし、読み出しの記録を預けた側から見える形で残すことが要る。
注意したい業界・業務
- 業界SaaS・委託先
- Web 制作、フォーム、CMS など、多数の企業のデータと外部連携の資格情報を 1 つの環境に預かるサービス。一度の侵害が、預けた企業すべてに及ぶ。
- 業界自社サイトを SaaS で運営する企業
- 問い合わせフォームの個人情報が SaaS の側に保存されている。今回の Link-U Group やラクスルのように、自社が侵害されていなくても、告知と報告の主体になる。
- 業務照会・参照
- 預けたデータや鍵が読み出される操作。誰の権限でどの範囲が読まれたかが、預けた側から見えない。
- 業務外部サービスとの連携
- API キーやトークン、Webhook の通知先を SaaS に登録する設定。登録した資格情報が、SaaS の侵害でそのまま外に出うる。
同じ穴は、Web 制作に限らず、データと連携の資格情報を外部のサービスに預ける多くの組織にある。預けたものが読まれたかどうかは、ふつう委託先の調査を待つしかない。
いまの対策で埋まるか
| 対策 | 今回 | 理由 |
|---|---|---|
| 保存データの暗号化 | 一部 | 復号に必要な鍵が同じ侵入で読み出されたため、暗号化して保存していたものも内容を知られた可能性がある（Studio）。 |
| パスワードのハッシュ化 | 一部 | パスワードそのものは保存していない。ただ、Studio は再利用しているパスワードの変更を求めている。 |
| 侵入の確認後の修正と鍵の入れ替え | 一部 | 13〜14 日に脆弱性を修正し、17 日に鍵を切り替えた。確認までの 12〜13 日と、すでに読まれた可能性のあるものは戻らない。 |
| 利用企業のアカウントの多要素認証（MFA） | 関係しない | 公表では、侵入は Studio の一部機能の脆弱性を突いたもので、利用企業のアカウントへのログインは経路として挙がっていない。 |
- 鍵を、データと同じ環境から読み出せないようにする。暗号文を持つ環境が、復号に必要な鍵を単独で読み出せない形にする。鍵の読み出しは、データの読み出しとは別の許可として扱う。
- 読み出しのたびに、許された主体と範囲かを確かめる。データ、鍵、外部連携の資格情報の読み出しを、許可の範囲と照合してから通し、確かめられないものは止める。
- 誰の何が読まれたかを、預けた側から見える記録に残す。どの許可に基づいて読み出されたかを、委託先の操作とは別の記録として残し、預けた側が後から確かめられるようにする。そうすれば、「取得されたとみなす」以外の答えを出せる。
SaaS に預けているものについて、利用企業で確かめる 3 項目
- 委託先が侵害されたとき、API キー、トークン、Webhook の通知先、連携の資格情報のどれから入れ替えるかが決まっているか。
- フォームで集めた個人情報が、どの SaaS に、いつからいつまで残っているか。ゴミ箱やテスト送信の分も含めて言えるか。
- 委託先の侵害で自社が告知と報告の主体になったとき、件数と期間を自社で出せるか。
注：鍵とデータを分け、読み出しを確かめても、許された主体の認証情報そのものが奪われた場合や、許可の範囲が広すぎる場合は通ってしまう。また、今回は侵入の入口が公表されていない。続報で判明すれば、この Brief を改訂する。
Sources
- 一次・企業公式Studio 株式会社「【重要】不正アクセスによる情報流出に関するお詫びとお願い」
- 一次・企業の適時開示Link-U Group「Studio 株式会社で発生した不正アクセスに伴う個人情報漏えいの可能性に関するお知らせ」
- 一次・企業公式ラクスル「当社が利用するクラウドサービスにおける不正アクセスに関するお知らせ」
本件は、当事者（Studio）と、利用企業の公式発表のみを一次とし、独立した第三者による検証や、英語の外部報道は確認できていない。Studio は更新を続けており、影響件数、取得の有無、原因は、続報で変わりうる。Link-U とラクスルは利用企業の立場で、自社の影響を述べている。日本の報道・ブログは出典に含めていない。
参照: 事後の検知が証明にならない論点は「AI時代のサイバー防衛に残された、最後の層」。