株式会社ベーシックのマーケティングプラットフォーム「ferret One」が第三者の不正アクセスを受け、ログイン用メールアドレスとサイト名4,317件、利用企業3社が管理していた問い合わせ等の個人情報計16,970件が閲覧または取得されました。同社は2026年10月27日に第一報、11月4日に第二報を公表しています。前半では利用企業が確かめる通知と窓口、問い合わせをくれた人への連絡を、後半では社内向けの管理画面と非公開ページをログインなしで触れさせない点検と、遮断した通信とその後のログインを結び付ける検知の実装を整理します。
まとめ：ferret Oneの不正アクセスで閲覧・取得された情報と利用企業が先に行うこと
ベーシックの第二報によると、不正アクセスは3つの経路で行われました。件数と対象を並べると次のとおりです。
| 経路 | 対象 | 件数 |
|---|---|---|
| ①不正ログイン（当社2アカウント） | 利用者のログイン用メールアドレス・サイト名 | 4,317件 |
| ①不正ログイン（利用企業1社2アカウント） | リード情報・問い合わせ情報（氏名・連絡先等） | 16,968件 |
| ②ログイン後の脆弱性の悪用 | 問い合わせ情報（利用企業2社） | 各社1件 |
| ③ログインを伴わない脆弱性の悪用 | 利用企業4社の非公開ページ（個人情報なし） | 4社 |
パスワードとクレジットカード情報など決済に関する情報が閲覧・取得された事実は確認されていません。悪用された不備は10月30日までにすべて修正され、11月4日時点で二次被害は確認されていません。ferret One以外の同社サービスはシステムが分かれているため、影響はないとしています。
利用企業が先に行うことは3つです。10月27日に管理画面とメールで届いた通知を確かめる。個別の報告が来ていない場合でも、ベーシックを装ったメールのURLや添付ファイルを開かない。自社サイトの非公開ページに、公開前の価格や人事情報を置いていなかったかを見直す。開発者は、自社の管理画面と下書きページにログインなしで届く経路が残っていないかを点検します。
ferret Oneの利用企業向け：届いた通知の確かめ方と問い合わせをくれた人への連絡
10月27日に管理画面とメールで届いた通知と、専用フォームによる問い合わせ窓口
ログイン用メールアドレスが閲覧・取得された利用者には、10月27日にferret Oneの管理画面と電子メールで知らせが届いています。経路①と②の3社、経路③を含む4社には、ベーシックが個別に経緯を報告済みです。個別の報告が無ければ、問い合わせ情報やページ情報は対象外と読めます。
問い合わせはferret One 不正アクセス専用お問い合わせフォームで受け付けています。フォームが使えない場合はメール（houmu@basicinc.jp）でも受け付け、返信は平日10時〜18時に順次行うとしています。
パスワードと決済情報が対象外でも、ベーシックを装う不審メールに備える理由
閲覧・取得されたのは、ferret Oneにログインする人のメールアドレスと、そのアカウントのサイト名です。攻撃者はこの組み合わせで「ferret Oneを使っている会社の担当者」を正確に絞り込めます。第二報も、同社や関係先を装った不審なメールへの注意を呼びかけ、URLへのアクセス、添付ファイルの開封、ID・パスワードの入力をしないよう求めています。
不正にログインされたアカウントは、10月26日〜27日にパスワードが初期化され、強制的にログアウトされました。ほかのアカウントのパスワード変更を求める記載は第二報にありません。同じパスワードをほかのサービスで使い回している場合は、そちらを先に替えるのが安全です。
問い合わせ情報の本人に誰が連絡するか、ベーシックと利用企業の協議の進め方
16,968件は利用企業1社のリード情報と問い合わせ情報を、重複を除いて数えた件数です。この1社のサイトから資料請求や問い合わせをした人の氏名と連絡先が含まれます。本人への対応は、ベーシックが「各社と協議のうえ、当社が全面的に協力して進める」としています。
個人データの取扱いを委託している場合、個人情報保護法ガイドライン（通則編）の3-5-3-2は、委託元と委託先の双方に報告と本人通知の義務があり、連名で報告できるとしています。不正アクセスによる漏えいは件数にかかわらず報告対象で、確報は知った日から60日以内です。流れは個人情報保護委員会への報告義務の実務にまとめました。
第二報で判明した3つの経路と、10月13日から10月30日までの時系列の整理
社内向けのバッチ処理管理画面にアカウントが作られてから発見まで13日かかった経緯
第二報の経緯表を、利用企業が状況をつかむ順に並べ直しました。
| 日付 | 出来事 |
|---|---|
| 10/13〜14 | 社内用バッチ処理管理画面に第三者がアカウント作成 |
| 10/16・19 | 一部の利用企業の非公開ページの情報を取得 |
| 10/19 10:03〜11:20頃 | 当社と利用企業1社の計6アカウントへ不正ログイン |
| 10/21〜27 | ログインの試みが続くが、いずれも失敗 |
| 10/26 | 不審通信の調査で発見。不正アカウント削除・経路遮断 |
| 10/27 | 第一報。全利用者のログインで2段階認証を有効化 |
| 10/28 | 不正ログイン修正。個人情報保護委員会・総務省へ速報 |
| 10/29〜30 | ページ情報への不正アクセスを確認し、対応を完了 |
| 11/4 | 第二報で原因と影響範囲を公表 |
入口になったのは、利用企業が触らない社内向けの管理画面でした。外から届く場所にあり、しかもアカウントを作れたことになります。ページ情報の不備は、第一報の後に行った全体点検で見つかりました。最初のアカウント作成から第二報で影響範囲を示すまで、およそ3週間かかっています。
公表文から読み取れる不備の種類と、攻撃手法が非公表のまま残る点
第二報は、複数の不備を「組み合わせて」悪用したと書いています。読み取れるのは3種類です。社内向け管理画面でのアカウント作成。ログイン後に他社の情報まで取れた不備。ログインせずに非公開ページの情報へ届いた不備です。攻撃の手法は、同様の攻撃を防ぐためとして公表されていません。
「ferret One 不正アクセス」で検索すると、2018年の事案の記事も出てきます。こちらは同社が使うクラウド（AWS）のアクセスキーが不正利用されたもので、2019年1月の調査結果で顧客情報の流出の痕跡は確認されなかったとScanNetSecurityが報じています。今回の2026年の事案とは別です。
社内向け管理画面と非公開ページへログインなしで届かせない外形点検の実装
OWASP Top 10:2025のA01・A07での管理画面登録口・非公開ページの点検
ここからは、本件の手法を再現するのではなく、同じ種類の不備を自社で探す方法を示します。OWASP Top 10:2025のA01（アクセス制御の不備）は、未認証の利用者がURLを推測して認証の要るページへ届く「強制ブラウジング」を典型例に挙げ、公開リソース以外は既定で拒否（deny by default）するよう求めています。
ログインなしで届いた非公開ページは、この強制ブラウジングにあたります。社内向けの管理画面でアカウントを作れたのは、そもそも外部から登録口に届いた点と、登録に承認が要らなかった点の2つが重なった状態です。A07（認証の失敗）は、多要素認証が無いか効いていない状態と、ブルートフォースなどの自動化された攻撃をすぐに止めない状態も弱点に挙げています。ログイン後に他社のデータへ届く抜けの止め方は、認可バイパスとIDORをサーバ側で止める実装で解説しました。
管理画面・登録口・下書きページの応答を、Pythonの標準ライブラリだけで点検する例
次のコードは、ログインしていない状態で各URLにアクセスし、見えてはいけないページが200を返したらNGを出します。手元で動かせるよう、抜けを2つ仕込んだ模擬アプリをhttp.serverで同じプロセス内に立てる構成です。302はリダイレクト先をたどらずに記録するので、ログイン画面への転送が返されたことを、そのまま確認できます。
# 外形点検：ログインなしで管理画面・登録口・非公開ページに届くかを確かめる（Python 3.9以上・標準ライブラリのみ）
import threading
import urllib.error
import urllib.request
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
# --- 点検対象の代わりに立てる模擬アプリ（抜けを2つ仕込んである） ---
class DemoApp(BaseHTTPRequestHandler):
def do_GET(self):
public = {"/": 200, "/blog/": 200}
leaky = {"/admin/batch/signup": 200, # 社内用の管理画面に誰でも登録できる
"/pages/draft-1029/": 200} # 非公開ページがログインなしで見える
guarded = {"/admin/": 302, "/pages/draft-1030/": 404}
code = {**public, **leaky, **guarded}.get(self.path, 404)
self.send_response(code)
if code == 302:
self.send_header("Location", "/login")
self.end_headers()
def log_message(self, *args):
pass
srv = ThreadingHTTPServer(("127.0.0.1", 0), DemoApp)
threading.Thread(target=srv.serve_forever, daemon=True).start()
BASE = f"http://127.0.0.1:{srv.server_port}"
# --- 点検本体：ここから下を自社の検証環境のURLに向けて使う ---
class NoRedirect(urllib.request.HTTPRedirectHandler):
def redirect_request(self, *args, **kwargs):
return None # 302をたどらず、ログイン画面へ飛ばされた事実をそのまま記録する
opener = urllib.request.build_opener(NoRedirect)
CHECKS = [ # (パス, 外部から見えてよいか)
("/", True), ("/blog/", True),
("/admin/", False), ("/admin/batch/signup", False),
("/pages/draft-1029/", False), ("/pages/draft-1030/", False),
]
def status(path):
req = urllib.request.Request(BASE + path, headers={"User-Agent": "exposure-check"})
try:
return opener.open(req, timeout=10).status
except urllib.error.HTTPError as e:
return e.code
for path, may_be_public in CHECKS:
code = status(path)
verdict = "NG" if (code == 200 and not may_be_public) else "ok"
print(f"{verdict:2} {code} {path}")
srv.shutdown()Python 3.14.7（Windows）で2026年11月4日に実行した結果です。ferret Oneの画面やURLを再現したものではありません。
ok 200 /
ok 200 /blog/
ok 302 /admin/
NG 200 /admin/batch/signup
NG 200 /pages/draft-1029/
ok 404 /pages/draft-1030/管理画面のトップはログイン画面へ302で逃がしていても、その下の登録口だけ200を返す、という形がNGとして出ます。下書きページも、IDが1つ違うだけで片方は404、片方は200です。点検するURLの一覧は、ルーティング定義（Railsのroutes、Laravelのroute:list など）から機械的に出すと漏れが減ります。本番ではなく、検証環境に向けて実行します。
社内向けの管理画面をnginxのallowとdenyで社内の出口IPに限る設定例
社内の担当者しか使わない管理画面は、アプリの認証の手前で、ネットワークの経路から外します。nginxならngx_http_access_moduleのallowとdenyで、上から順に評価されるルールを書けます。
# 社内向けの管理画面は、社内の出口IPとVPNの出口からだけ通す（nginx）
location /admin/ {
allow 192.0.2.0/24; # 社内の出口IP
allow 198.51.100.10; # VPNの出口
deny all;
proxy_pass http://app_backend;
}アドレスは説明用の範囲です。CDNやロードバランサーの後ろに置いている場合、nginxから見える送信元はCDN側のIPになるため、実際の送信元を取り出す設定を先に済ませます。IP制限は認証の代わりではありません。管理画面のアカウント作成は、外部から呼べる登録口で受け付けず、既存の管理者による招待と承認だけにします。
遮断した不審通信とその後のログイン成功を突き合わせる検知の作り方
遮断ログの送信元IPと6日後の不正ログインを結び付けるPythonの突き合わせ例
第二報は、10月13日以降の外部からの不審な通信を検知していたものの、いずれも防御の仕組みで遮断されていたため、その時点では不正ログインとの関連を把握できなかったと書いています。不正ログインは正規の利用者と見分けにくい手順で行われました。遮断できた通信は「終わった話」として扱われがちです。そこで、遮断した送信元からのログイン成功だけを拾う突き合わせを置きます。
# 遮断した通信の送信元が、その後ログインに成功していないかを突き合わせる（Python 3.9以上・標準ライブラリのみ）
import csv
import io
from datetime import datetime, timedelta
# WAF・IPSの遮断ログ（送信元IPと時刻）
BLOCKED = """ts,src_ip,rule
2026-10-13T02:11:40,203.0.113.7,path-traversal
2026-10-14T03:52:08,203.0.113.7,admin-path-probe
2026-10-15T22:40:19,198.51.100.23,sqli
"""
# アプリのログイン成功ログ（アカウントと送信元IP）
LOGINS = """ts,account,src_ip,mfa
2026-10-18T09:12:44,ops-01,192.0.2.10,yes
2026-10-19T10:03:51,ops-02,203.0.113.7,no
2026-10-19T10:41:02,cust-a-01,203.0.113.7,no
2026-10-19T13:20:15,cust-b-01,192.0.2.55,yes
"""
LOOKBACK = timedelta(days=14) # 遮断から何日以内のログインを疑うか
def rows(text):
for r in csv.DictReader(io.StringIO(text)):
r["ts"] = datetime.fromisoformat(r["ts"])
yield r
first_block = {}
for b in rows(BLOCKED):
first_block.setdefault(b["src_ip"], b)
for login in rows(LOGINS):
b = first_block.get(login["src_ip"])
if b and timedelta(0) <= login["ts"] - b["ts"] <= LOOKBACK:
gap = login["ts"] - b["ts"]
print("ALERT", login["ts"], login["account"], login["src_ip"],
"mfa=" + login["mfa"], "遮断から", gap.days, "日", "(" + b["rule"] + ")")同じ環境での実行結果です。ログの値は説明用に作ったもので、ベーシックの記録ではありません。
ALERT 2026-10-19 10:03:51 ops-02 203.0.113.7 mfa=no 遮断から 6 日 (path-traversal)
ALERT 2026-10-19 10:41:02 cust-a-01 203.0.113.7 mfa=no 遮断から 6 日 (path-traversal)4件のログイン成功のうち、遮断歴のある送信元からの2件だけが出ます。どちらも多要素認証を通っていません。攻撃者が送信元を変えれば外れるため、実運用ではIPに加えて、User-Agentの一致、普段と違う時間帯、管理者権限での初回ログインも照合の条件にします。突き合わせは1日1回のバッチで足ります。ログの集め方はSaaSセキュリティ対策の実装手順のログ監視の章で扱いました。
2段階認証を全員に有効化した10月27日の対応と、ログイン試行回数の制限の置き方
ベーシックは10月27日に利用中の全利用者のログインで2段階認証を有効にし、28日からは新しく登録する利用者も標準で有効にしました。10月26日〜28日には、社内向け管理機能へのアクセス制限と、ログイン試行回数の制限も入れています。10月21日〜27日の試みがすべて失敗したことと合わせると、正しいパスワードだけでは入れない状態に切り替えたのが、侵入を止めた対策だと読めます。
試行回数の制限は、アカウント単位で一律にロックすると、他人のメールアドレスを入力するだけで正規の利用者を締め出せてしまいます。A07が「回数を制限するか、徐々に遅延させる。ただしサービス拒否を生まないよう注意する」と書くのはこのためです。送信元ごとの遅延と、アカウントごとの遅延を組み合わせます。方式の選び方は多要素認証（MFA）の3要素と実装方式、同型の管理画面の不正ログインはFaveConnectの管理画面の不正ログイン対策でも整理しています。
利用企業の判断：ferret Oneを使い続ける条件と、自社サイトで行う追加点検
再発防止策5項目の報告を受け取ってから継続を決める条件と、見送りを考える場面
第二報が予定する再発防止策は5つです。ソースコードの脆弱性診断と再診断、外部の専門家による疑似攻撃での検査、不正通信の検知・遮断の強化、不審なログインの監視強化、外部の専門機関による調査です。継続するかは、このうち疑似攻撃の検査と外部機関の調査の結果を、利用企業として受け取れるかで決めます。修正済みの不備以外に同じ種類の抜けが残っていないかは、そこでしか分かりません。
見送りを考えるのは、問い合わせフォームで機微な情報（健康状態、採用応募者の経歴など）を受けていて、その保管先をferret Oneから外せない場合です。リード情報の保管先を自社のCRMへ移し、ferret Oneには残さない運用に変えられるなら、継続して差し支えありません。MAツールの選び直しを含めて比べる場合は、主要MAツールの公式料金比較と選び方が参考になります。委託先として何を契約で求めるかは委託先管理と個人情報保護法25条の監督義務にまとめました。
自社のWebシステムに残る管理画面の露出を、第三者の診断で確かめる範囲
本件の入口は、利用者が見ることのない社内向けの画面でした。自社でWebシステムを持つ事業者は、運用担当しか知らないバッチ管理・ジョブ監視・CMSのプレビュー機能を一覧にし、外部から届くか、アカウントを作れるか、ログインなしで下書きが見えるかを、上の点検コードと同じ観点で試します。SaaSが破られた同時期の事案として、Studioの不正アクセスとアララの不正アクセスも、利用企業側の作業を整理しています。
管理画面の露出や、ログイン後に他社のデータへ届く認可の抜けを第三者に確かめてもらいたい場合は、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
ferret Oneの不正アクセスについて、利用企業の担当者とフォームから問い合わせた人から出やすい質問をまとめました。
ferret Oneを使っていますが、自社が対象かどうか確かめる方法はありますか？
ログイン用メールアドレスとサイト名が閲覧・取得された利用者には、10月27日にferret Oneの管理画面と電子メールで知らせが届いています。問い合わせ情報や非公開ページの情報が閲覧・取得された4社への対応は、ベーシックによる個別の経緯報告です。不明な点を確かめる窓口として、ベーシックの専用お問い合わせフォームか、houmu@basicinc.jp を利用できます。
ferret Oneのパスワードを変更する必要はありますか？
第二報では、ログイン用パスワードが閲覧・取得された事実は確認されていません。不正にログインされたアカウントは、10月26日〜27日にパスワードが初期化されています。全利用者のログインで2段階認証も有効になりました。ほかのアカウントに変更を求める記載はありませんが、同じパスワードを別のサービスでも使っている場合は、そちらを替えておくと安心です。
ferret Oneで作られたサイトのフォームから問い合わせた人の情報は漏れましたか？
閲覧・取得が確認されたのは、利用企業3社が管理していた問い合わせ等の個人情報計16,970件です。内訳は1社のリード情報と問い合わせ情報16,968件と、2社の各1件です。この3社以外の利用企業が管理する情報について、閲覧・取得された事実は確認されていません。本人への対応は、ベーシックと各社が協議して進めます。
ferret Oneは今も使えますか？
第二報には、サービスを止めたという記載はありません。悪用された不備は10月30日までにすべて修正され、全利用者のログインで2段階認証が有効になっています。ベーシックは、本件による業績への影響を軽微と見込んでいます。
ferret Oneの不正アクセスの原因は何ですか？
ベーシックのシステムにあった複数の脆弱性を、第三者が組み合わせて悪用したことが原因です。社内向けのバッチ処理管理画面へのアカウント作成、不正ログイン後の脆弱性の悪用、ログインを伴わない非公開ページへのアクセスの3つが確認されています。攻撃の手法は、同様の攻撃を防ぐためとして公表されていません。
関連記事
- FaveConnect不正アクセス：11万7,392件の対象確認と管理画面の不正ログイン対策：管理画面への不正ログインを止める実装
- 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：ログイン後に他社のデータへ届く抜けの止め方
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：レート制限と認可をAPI全体に入れる手順
- Studio不正アクセスで全顧客の情報流出か｜連名報告の受付とAPIキー・Webhook URLを今日替える手順：Web制作SaaSが破られた同時期の事案
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：委託元と委託先の報告の分担
