製品 Lemma API証明の発行・検証の基盤Trust402エージェントに任せ、取引するSeal鍵を渡さない、エージェント時代のサインイン
ユースケース 製造・基幹インフラ検査記録アシュアランス金融・FinTech取引先レコード検証自治体・公共証明書レス手続き医療・ヘルスケア有資格者アシュアランス調達・サプライチェーン仕入先資格モニタリングメディア・コンテンツコンテンツ真正性サービス・小売グループ横断アイデンティティAI導入(業種横断)AI実行ガバナンス開発者・エージェント運用エージェント権限統制 ▸ 業界別ソリューション索引を見る
料金
リソース Critical BriefAI×信頼の最前線ブログ考え方と実装の記録ドキュメントAPI と仕様書検証センター検証・発行の実数運営会社FRAME00, Inc.お問い合わせ導入・取材のご相談用語集言葉の定義FAQよくある質問
始める ↗ EN
No. 110 Critical Brief · 規制属性証明

ソースネクスト:会員情報取得 API が悪用され、最大 2,252 万件の会員情報が取得された可能性がある(ソースネクスト発表)

取得の量と用途を、呼び出しのたびに確かめる層が無い

最大 2,252万件
流出した可能性がある会員情報(確定の件数ではない)
10-09→10-13
取得の開始(10 時ごろ)から不正アクセスの確認(9 時ごろ)まで約 4 日
09:00→13:36
10 月 13 日、確認から封じ込めの完了まで
事案日2026-10-09
公開2026-10-20
発行Lemma Critical Team
目次
  1. 01TL;DR
  2. 02何が起きたか
  3. 03時系列 — 公表と対応
  4. 04なぜ止まらなかったか
  5. 05対策するには
  6. 06Sources

TL;DR

  1. 01何が起きたか

    2026 年 10 月 9 日 10 時ごろから、ソースネクストの会員情報システムに第三者が不正にアクセスし、会員情報取得 API を使って登録情報を取得した。最大 22,519,960 件の会員情報が外部に流出した可能性があると、同社が 10 月 15 日に公表した。含まれうる項目は、メールアドレス、パスワード、氏名、住所、電話番号、生年月日などで、クレジットカード情報は対象のシステムに保管されていない。

  2. 02なぜ見分けられないか

    公表から読む限り、使われたのは、会員情報を返すという API の正規の機能である。認証をどう通ったか、どの脆弱性が使われたかは公表されていない。取得の開始から確認まで、約 4 日が空いた。

  3. 03欠けていた層

    確認してからの対応は速かった。同社は 10 月 13 日 9 時ごろに不正アクセスを確認し、同日 13 時 36 分までに封じ込めを完了している。効かなかったのは、会員情報取得 API の呼び出しが、正規の主体・用途・量の範囲内かを、取得のたびに確かめる層である。

何が起きたか

システム
会員情報を管理するシステム。ソースネクストの各サービスの会員が対象で、10 月 13 日 13 時 36 分時点の登録者が範囲とされる。
アクセスの性質
第三者が、会員情報取得 API を使って登録情報を取得した(公式告知による)。公式の FAQ は「管理するサーバーへの不正アクセス」と記し、API の記述はない。認証をどう通ったか、どの脆弱性が使われたかは、公表されていない。
規模
最大 22,519,960 件。流出した可能性であって、確定の件数ではない。全項目がすべての会員にあるわけではない。
含まれうる項目
メールアドレス、パスワード、氏名(カナを含む)、住所、性別、電話番号、FAX 番号、生年月日、会社名、役職、部署、利用サービス・登録日・ログイン日などのシステム固有情報。
含まれない項目
クレジットカード情報(対象のシステムに保管なし)。
確認されていないこと
第三者による悪用の有無。パスワードの保管形式(ハッシュ化の有無)は、公表されていない。

用語メモ
API — システム同士がデータをやり取りするための窓口。会員情報取得 API は、呼び出されると会員の登録情報を返す。
封じ込め — 不正なアクセスを遮断し、被害がそれ以上広がらないようにすること。
パスワードリスト攻撃 — 流出したメールアドレスとパスワードの組み合わせを、別のサービスのログインに使い回して試す攻撃。

図表 1公表された範囲で見た、経過の連鎖

取り返しがつかなくなった実行は ② の取得。その呼び出しが誰によって、何のために、どれだけの量で行われているかが、取得の時点で確かめられた形跡は公表されていない。① にどう到達したかも公表されていない。

ソースネクスト
1
会員情報を返す API が、第三者に使える状態にあった

公表から読む限り。到達の方法は非公表。

第三者
2
10 月 9 日 10 時ごろから、その API で登録情報を取得する

最大 22,519,960 件が流出した可能性。

ソースネクスト
3
10 月 13 日 9 時ごろに確認し、13 時 36 分までに封じ込める

外部からの不正な通信を遮断するなど。

ソースネクスト
4
10 月 15 日に公表し、パスワードの再設定を求める

個人情報保護委員会へ報告。

時系列 — 公表と対応

  • 10:00 ごろ、不正アクセスが始まる(その後の調査で判明した時点)。
  • 09:00 ごろ、ソースネクストが不正アクセスを確認。13:36 までに封じ込めを完了。
  • 公表。個人情報保護委員会へ報告。ログイン時にパスワードの再設定を求める措置。
  • 所轄警察署へ相談(FAQ による)。

本件の事実は、ソースネクストの公式告知と FAQ に拠る。「4 日」は開始(10 月 9 日 10 時ごろ)と確認(10 月 13 日 9 時ごろ)の差で、確認の契機は公表されていない。外部のフォレンジック調査が進行中であり、手口、使われた脆弱性、取得の実際の件数は、今後の発表で変わりうる。同社は 2023 年にも、サイトのシステムの一部の脆弱性を突いた不正アクセスで、決済のアプリケーションが改ざんされ、約 12 万人分の個人情報(うちクレジットカード情報 112,132 件)が漏えいした可能性があると公表している(同社の 2023-02-14 の公式告知)。

公表後の対応

  • パスワードの無効化: 流出の対象に含まれるパスワードを順次無効にし、ログイン時に再設定を求めている(FAQ)。
  • 脆弱性の修正: 対象システムの脆弱性を修正し、他の脆弱性の有無を調査している。
  • 対象者への案内: 登録メールアドレスへの通知と、専用の問い合わせ窓口。
  • 注意喚起: 同じパスワードを使っている他のサービスでも変更し、なりすましのメール・SMS・電話に注意するよう求めている。

なぜ止まらなかったか

この事案の失敗は、第三者が会員情報取得 API に届いたことだけではない。公表から読む限り、API が会員情報を返すという正規の機能が、呼び出す主体・用途・量の対応を確かめられないまま、約 4 日にわたって使われたことにある。

この事案の核心
API が会員情報を返せることと、この呼び出しが許されることは、別々の事実である。

確認してからの対応は速かった。同社は不正アクセスを確認し、当日のうちに封じ込めた。ただし、確認は取得の開始から約 4 日後である。効かなかったのは、その手前である。API が「会員情報を返す」ことと、その呼び出しが「許された主体が、許された用途で、許された量を取る」ことは別の事実であり、後者を呼び出しの直前に確かめる層が、公表された範囲では見当たらない。会員 2,000 万件超という規模が、約 4 日の間に取得されうる状態が、そのまま残っていた。

図表 2検出と証明の落差

証明は呼び出しが実行される前に働き、検出は不正アクセスに気づいた後に働く。今回、その間は約 4 日あった。

証明の層 · 今回なし取得の前に、呼び出しが許可の範囲内かを確かめる
落差取得は通っている。
まだ誰も気づいていない
検出の層 · 効いた不正アクセスに気づき、封じ込める
STEP 1
API が呼び出される
STEP 2
登録情報が返される
STEP 3
約 4 日後に確認する
STEP 4
同日中に封じ込める

不正アクセスに気づくことと、呼び出しが許されていると確かめることの間にある隔たりが、本 Brief の言う検出と証明の落差である。

対応は、遮断、脆弱性の修正、パスワードの無効化、調査である。これらは必要だが、いずれも取得が行われた後に働く。取得されたパスワードの無効化は、取得された情報の価値を下げるためのものであり、取得の時点を守るものではない。

同じ構造は、これまでの Brief にも現れている。デンマーク CPR では、正規の照会権限による取得が、量と用途の確認なしに約 880 万人分に及んだ。McHire/Paradox.ai では、採用 AI の API から 6,400 万件にアクセスできた。いずれも、取得の経路が機能として存在するため、実行の直前に独立した確認が置かれていない。

対策するには

侵入の経路が公表されていなくても、API が誰に、何のために、どれだけ返すかは、組織の側で決めて確かめられる。会員情報を返す API は、呼び出しが通れば、その機能どおりに情報を返す。呼び出せる相手と用途を決め、一度に、また一定の時間に返せる量に上限を置き、超える取得は実行の前に止める。そうしておけば、経路がどこであっても、取られる量は上限で止まり、取られた範囲も後から言える。

注意したい業界・業務

業界サービス・小売
ソフトウェアやオンラインショップなど、多数の会員をメールアドレスとパスワードで管理するサービス。会員の数だけ、流出したときの影響が大きい。
業務照会・参照
会員情報を API や管理画面から引き出す業務。呼び出しが通るかどうかだけで、何件取れるかが決まっていると、正規の機能のまま大量の取得が通る。

同じ穴は、会員を持つ多くのサービスにある。API の入口は守っていても、通った呼び出しが何件を、何のために取っているかを、その場で見ている組織は多くない。

いまの対策で埋まるか

対策今回理由
API の認証(呼び出し元の鍵・トークン)一部呼び出せる相手を絞る。ただ、今回認証をどう通ったかは公表されておらず、通った呼び出しが何件を取るかは見ない。
侵入の検知と遮断一部確認から同日中に封じ込めた。ただ、確認は取得の開始から約 4 日後で、その間に取られた分は戻らない。
パスワードの無効化と再設定一部取られたパスワードでのログインは防ぐ。同じパスワードを使い回した、ほかのサービスには及ばない。
脆弱性の修正一部今回の穴からの再侵入は防ぐ。別の経路から届いた呼び出しが何件を取るかは見ない。
対策必要になるもの
  1. 呼び出せる相手と用途を、付与の時点で決めて記録する。会員情報を返す API ごとに、誰が、何のために、どの範囲の会員を引けるかを決める。決めた内容を、呼び出しのたびに照合できる形で残す。
  2. 量と対象に上限を置き、超える取得は実行の前に止める。 1 回の呼び出し、一定の時間に返せる件数と、対象にできる会員の範囲を決める。超える呼び出しは、確かめられるまで保留にする。
  3. 誰の何を取ったかを、呼び出す側とは別に残す。どの許可に基づいて、誰の何が返されたかを、呼び出す側の操作とは別の記録として残す。取られた後に、範囲を自分たちの記録で言えるようにする。
点検点検チェックリスト

会員情報を返す API について、組織で確かめる 3 項目

  • 会員情報を返す API を一覧で言えるか。それぞれ、誰が何のために呼び出すかが決まっているか。
  • 1 回の呼び出し、1 日の呼び出しで返せる件数に上限があるか。超えたとき、誰に知らせが届き、取得を止められるか。
  • 取得された会員の範囲を、API を呼び出した側の記録に頼らずに言えるか。

注:正規の主体が範囲内で目的外に使う場合や、上限の内側で少しずつ取られる場合は、この仕組みでも通ってしまう。また、上限を置くと、正規の一括処理も止まったり遅れたりする。今回は手口と使われた脆弱性が公表されていない。続報で判明すれば、この Brief を改訂する。

Sources

  1. 一次・企業公式ソースネクスト「当社サイトへの不正アクセスによるお客様情報流出のお詫びとお知らせ」2026-10-15 · sourcenext.com/support/i/2026/1015_info
  2. 一次・企業公式ソースネクスト「情報漏洩に関するよくあるご質問」ページに日付の記載なし。10 月 16 日の警察への相談を済んだこととして記している。sourcenext.com/support/i/2026/1015_1
  3. 一次・企業公式ソースネクスト「弊社が運営する『ソースネクストオンラインショップ』への不正アクセスによる個人情報漏えいに関するお詫びとお知らせ」2023-02-14、過去の事案 · sourcenext.com/support/i/2023/0214_info

本件は、当事者(ソースネクスト)の公式発表のみを一次とし、独立した第三者による検証や、英語の外部報道は確認できていない。手口と使われた脆弱性は非公表である。公式告知は「会員情報取得 API」、FAQ は「サーバーへの不正アクセス」と記し、表記が一致しない。日本の報道・ブログは出典に含めていない。

参照: 事後の検知が証明にならない論点は「AI時代のサイバー防衛に残された、最後の層」。Pillar の整理は規制属性の証明。

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。

この Brief を引用する

Lemma Critical Team. (2026).
"ソースネクスト:会員情報取得 API が悪用され、最大 2,252 万件の会員情報が取得された可能性がある(ソースネクスト発表) — 取得の量と用途を、呼び出しのたびに確かめる層が無い".
Lemma Critical Brief No.110. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/110-sourcenext-member-api-22m-records/
Lemma

確かめられないものを、
業務に入れない。

Lemma は、データや AI の実行に暗号技術で証明を付け、受け取った側が発行者に問い合わせることなく真正性を確認できるようにします。検出はそのままに、その前段へ一層を足す構成です。