ベーシック「ferret One」への不正アクセス（顧客リード・問い合わせ情報等16,970件閲覧・取得）
公表日
株式会社ベーシックの提供する「ferret One」が不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。外部の攻撃者だけでなく、内部の人が権限を超えて行う場合もあります。日本では「不正アクセス禁止法」で禁止されています。公表文の「不正アクセス」は手口の名前ではなく、どう侵入されたかは別に書かれます。を受け、顧客のリード・問い合わせ情報16,970件やログイン用メールアドレス等4,317件が閲覧・取得された。
対象者は？
ferret Oneの導入企業（ログイン用メールアドレスやサイト名4,317件）および顧客3社（問い合わせ等の個人情報16,970件）。パスワードやクレジットカード情報は含まれない。
影響を受けた顧客には個別連絡および管理画面・電子メールでの通知が行われているため、案内を確認する。
いますぐできること
- 案内を受け取った場合は、ferret Oneの案内に従い2段階認証の設定やパスワードの確認を行う。
- 不審な問い合わせやメールの受信に注意する。
何が起きたのか
2026年10月13日から14日にかけて、攻撃者がferret Oneの社内向け管理機能に不正なアカウントを作成しました。その後、10月19日に複数の弱点を悪用してベーシック社および顧客のアカウント計6件に不正ログインし、非公開ページや顧客が管理する問い合わせ情報などを閲覧・取得しました。10月26日に同社が事象を把握し、アカウントの削除や脆弱性の修正を行いました。
なぜ起きたのか・なぜ広がったのか
社内向けのバッチ処理管理画面に不正にアカウントが作れてしまう不備があったこと、さらに複数の脆弱性を組み合わせて不正ログインやページ情報へのアクセスを許してしまったことが原因です。
いまの状況2026-11-04 時点
悪用された脆弱性は2026年10月30日までにすべて修正され、全利用者に2段階認証が有効化されました。パスワードや決済情報の流出、および二次被害は確認されていません。
企業として考えたいこと
社内向けの運用・管理画面がインターネットから直接アクセス可能になっていたり、誰でもアカウントを作れるような設定不備共有範囲やアクセス権の設定を誤り、本来は見えてはいけない情報が、他の人やインターネットから見える状態になってしまうことです。攻撃がなくても漏えいが起きます。クラウドの共有リンクや「全員に公開」の設定で起きやすい事故です。が放置されていませんか？
技術的な要約
株式会社ベーシックが提供するマーケティングプラットフォーム「ferret One」において、内部管理機能の不備および複数の脆弱性を悪用した第三者による不正アクセスが発生した。攻撃者は社内向けバッチ処理管理画面に不正アカウントを作成した上で、同社および顧客のアカウント計6件に不正ログインし、非公開ページや顧客管理情報にアクセスした。これにより、導入企業のログイン用メールアドレス・サイト名4,317件と、顧客3社が管理していたリード・問い合わせ情報計16,970件が閲覧または取得された。同社は不正アカウントの削除、アクセス経路の遮断、脆弱性の修正を完了し、全利用者の2段階認証有効化などの対策を実施した。
攻撃の分類
- 侵入口
- 管理画面/API公表で確認社内向けのバッチ処理管理画面（内部管理機能）の不備を突かれ、第三者により不正にアカウントが作成された。
- 脆弱性
- CVE 非公表公表で確認ferret One 内部管理機能・バッチ処理管理画面社内向けバッチ処理管理画面におけるアカウント不正作成の不備、および不正ログイン・ページ情報アクセスに関する複数の脆弱性。CVE番号は非公表。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- なし 確認された不正アクセスの経路遮断および緊急対策が実施され、ferret Oneは引き続き利用可能であった。他サービスへの影響もない。
- データ
- 確定上限 21,287確定 21,287件メール氏名取引先情報業務データその他ferret One利用者のログイン用メールアドレスおよびサイト名4,317件、ならびに顧客3社が管理していたリード情報および問い合わせ情報（氏名、連絡先等）16,970件（顧客1社の16,968件と別顧客2社の各1件）。別途、顧客4社の非公開ページ情報（個人情報は含まず）も閲覧・取得された。パスワードやクレジットカード情報は含まれない。
- 波及先
- 4 社
- リード情報および問い合わせ情報16,968件が閲覧・取得された顧客1社
- 問い合わせ情報が各1件閲覧・取得された顧客2社
- 非公開ページ情報が閲覧・取得された顧客4社（上記3社を含む）
- 金銭影響
- 2026年12月期の業績に与える影響は軽微と見込んでいる。
- サプライチェーン
- ベーシックが提供するマーケティングプラットフォーム「ferret One」が侵害され、同サービスを利用していた導入企業複数社の管理データ（リード情報、問い合わせ情報、非公開ページ情報）が第三者に閲覧・取得された。
時系列
- 2026-10-13
- 2026-10-16
- 2026-10-19 10:03
- 2026-10-21
- 2026-10-26
- 2026-10-27
- 2026-10-28
- 2026-10-29脆弱性の調査過程において、第三者によるページ情報への不正アクセスを確認3
- 2026-10-30
- 2026-11-04
技術解説
内部管理機能への不正アカウント作成と脆弱性の悪用経緯 事実
2026年10月13日から14日にかけて、第三者が「ferret One」の社内向けバッチ処理管理画面に不正にアカウントを作成した。その後、10月16日および19日に一部顧客サイトの非公開ページ情報が不正に取得され、10月19日の10時3分から11時20分頃にかけて、複数の脆弱性を組み合わせて悪用することでベーシックおよび顧客1社の計6アカウントに不正ログインが行われた。この不正ログインにより、利用者のログイン用メールアドレス・サイト名4,317件や、顧客3社が管理していたリード・問い合わせ情報計16,970件（顧客1社16,968件、別顧客2社各1件）が閲覧・取得された。また、顧客4社の非公開ページ情報も閲覧・取得されたが、個人情報は含まれていない。ログイン用パスワードやクレジットカード情報の流出および二次被害は確認されていない。
社内向け内部管理画面の公開性と権限管理の課題 解釈
本事案では、社内向けバッチ処理管理画面という本来は内部運用に限定されるべき管理機能において、外部からのアクセスやアカウントの不正作成を許す不備が存在していたことが攻撃の起点となっている。バッチ処理管理画面のようなバックオフィス向けツールがインターネット経由で到達可能な状態にあったか、十分な認証・認可制御が講じられていなかった可能性がある。また、攻撃者が作成したアカウントを用いて複数の脆弱性を組み合わせ、最終的に顧客アカウントや他社データへ横断的にアクセス可能となっていたことから、管理機能と顧客テナント間の隔離や権限分離の設計に弱点が存在していたと考えられる。内部ツールであってもインターネット境界でのIP制限やゼロトラスト型の多要素認証アクセスを必須とし、不正なアカウント作成を検知・阻止する仕組みが求められる。
検知から初期対応までのタイムラグと多要素認証の即時導入 解釈
ベーシックは10月13日より不審な通信を検知していたものの、正規利用者と判別が困難な不正ログインが行われていたこともあり、事態の把握と対策チームの設置は10月26日となった。侵入から発覚まで約2週間を要した点について、不審な通信のアラートをトリガーとした深掘り調査や、特権的な管理アカウントの作成イベントに対する即時検知・通知体制に改善の余地があったと推察される。一方で、10月26日の事態把握後は迅速にアカウント削除や通信遮断、パスワード初期化、強制ログアウトを行い、翌27日には全利用者を対象とした2段階認証の有効化を断行している。さらに10月30日までに悪用された脆弱性をすべて修正し、11月4日には影響範囲の詳細な調査結果を第二報として開示しており、初動後の封じ込めと情報公開は迅速かつ透明性の高い対応であったと評価できる。
対応
- 封じ込め
- 不正に作成されたアカウントの削除、不正アクセス経路の遮断、不正ログインされたアカウントのパスワード初期化および強制ログアウトを実施した。また、全利用者のログインにおける2段階認証の有効化（必須化）を行い、悪用されたシステム上の不備・脆弱性を2026年10月30日までにすべて修正した。
- 公表の仕方
- 2026年10月27日に第一報を自社サイトおよび適時開示にて公表し、対象顧客への個別連絡や管理画面・電子メールでの周知を実施した。詳細な原因および影響範囲の調査結果を取りまとめ、2026年11月4日に第二報を公表した。
- 当局対応
- 個人情報保護委員会
- 総務省関東総合通信局
- 警察
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 社内向け・バックオフィス用管理機能の外部露出制限と厳格なアクセス制御 | バッチ処理や社内運用向けの管理画面はインターネットへ直接公開せず、VPN、IP制限、あるいはZTNA（ゼロトラスト・ネットワーク・アクセス）を導入して社内ネットワーク限定のアクセス制御を徹底する。 |
| アカウント作成機能における認可・検証処理の徹底 | アカウント作成APIや画面において、適切な特権ロールの検証を行い、不正なパラメータ操作や権限昇格によるアカウント追加を防止するロジックを実装・テストする。 |
| SaaS環境におけるマルチテナント間の厳格なアクセス境界設計 | 顧客データや非公開ページ情報へのアクセス処理において、セッション内の認可情報とリソース所有者のテナントIDの突合をフレームワーク層で強制し、他テナントのデータ閲覧・取得を防ぐ。 |
| 特権アカウント作成および重要操作のリアルタイム検知とアラート通知 | 内部管理システムでの新規アカウント作成、特権ロールの付与、大量データの参照・エクスポートを監査ログに記録し、SIEM等と連携して管理者に即時アラートを送信する監視体制を構築する。 |
自組織などでの確認項目
- 自社の社内向け管理ツールやバッチ処理画面が、意図せず外部インターネットからアクセス可能な状態になっていないか。
- 管理者アカウントや内部利用アカウントの新規作成が行われた際、セキュリティ担当者や運用管理者に即時通知される仕組みがあるか。
- SaaSや自社サービスにおいて、管理機能やAPIの脆弱性を悪用されてテナントを越えたデータアクセスが発生しないよう、認可チェックが適切に実装されているか。
未解明点
- 社内向けバッチ処理管理画面で第三者によるアカウント不正作成を可能にした具体的な技術的不備（未認証APIの露出、パラメータ改ざん、ロジック不備など）の詳細は公表されていない。
出典
- 1株式会社ベーシック2026-10-27公式本文確認済
- 2株式会社ベーシック2026-11-04公式本文確認済
- 3株式会社ベーシック2026-11-04公式本文確認済
- 4情報漏洩まとめ.site2026-11-04報道本文確認済
- 5セキュリティ対策Lab（合同会社ロケットボーイズ）2026-11-04報道本文確認済
- 6日本インタビュ新聞社2026-11-04報道本文確認済
- 7株式会社ベーシック2026-10-27公式本文確認済