2026.10.06 セキュリティ

焼肉きんぐの不正アクセスと1,078万件の会員情報｜全件規模の流出を防ぐAPIとログの点検

焼肉チェーン「焼肉きんぐ」を運営する物語コーポレーションは2026年10月5日、焼肉きんぐ公式アプリの会員管理システムが第三者から不正アクセスを受け、会員情報が漏えいしたと公表しました。漏えいした件数は1,078万8,963件で、アプリのユーザー登録数1,080万8,784件のほぼすべてにあたります。本記事で整理するのは、公式発表に記載された経緯と漏えいした項目です。そのうえで、会員アプリを運営する側が「会員のほぼ全件がまとめて外に出る」事態を自社で防げるかを確かめる手順を、手元で動くPythonスクリプトとSQLで示します。

まとめ：焼肉きんぐ公式アプリの不正アクセスで公表された事実と運営側の点検

確定しているのは次の事実です。2026年10月2日に会員管理システムへの不正アクセスを確認し、通信の遮断と防御措置を実施しました。翌3日に会員情報の漏えいを確認し、5日に公表しています。漏えいしたのは会員番号、氏名（アプリ登録名）、メールアドレス、電話番号の4項目です。ログインパスワード、生年月日、性別、郵便番号、保有ポイントを含む店舗利用履歴は漏えいしておらず、クレジットカード等の決済情報は同社が保持していません。

原因と不正アクセスが可能になった経緯は、公表時点で調査中とされています。したがって本記事は原因を断定しません。それでも、登録数の99.8%という件数は、1件ずつ狙われたのではなく全件に近い量がまとめて取得されたことを示します。会員アプリを運営する側は、1回の呼び出しで返す件数と項目に上限があるか、1つの認証情報が会員全体の何%を取得したかを数えられるか、の2点をまず確かめてください。

項目	公表されている内容
不正アクセスの確認	2026年10月2日（金）
漏えいの確認	2026年10月3日（土）
公表	2026年10月5日
漏えい件数	1,078万8,963件
アプリ登録数	1,080万8,784件
漏えいした項目	会員番号、氏名、メール、電話番号
原因	調査中

公式発表を時系列で確認する｜10月2日の検知から10月5日の公表までの3日間

10月2日の不正アクセス確認と通信遮断から10月3日の漏えい確認まで

物語コーポレーションの公式発表（2026年10月5日）によると、10月2日（金）に焼肉きんぐ公式アプリの会員管理システムで第三者からの不正アクセスが確認されました。同社は確認後に通信を遮断し、防御措置を取っています。それでも翌10月3日（土）に、会員情報が漏えいしたことを確認しました。

検知から漏えいの確認までは1日、公表までは3日です。遮断の時点ですでに取得が終わっていたのか、遮断までの間に取得が進んだのかは、発表からは読み取れません。公表時点で、漏えいした情報が不特定多数に公開された事実や不正利用された事実は確認されていないとしています。

アプリは防御措置を講じたうえで提供継続・他ブランドのアプリも同じ措置

焼肉きんぐ公式アプリは、外部からの不正アクセスに対する防御措置を講じたうえで、サービスの提供を続けています。同社が運営する丸源ラーメンなど他ブランドの公式アプリにも同様の措置を取り、こちらで情報漏えい等の事実はないと説明しました。

サーバーへの接続を止めて新規入会や会員情報の変更を止めたセイコーマートの不正アクセスと57万人の会員情報の事案とは、対応の形が異なります。複数ブランドで同じ会員基盤やアプリの作りを共有している場合、1ブランドの事故を受けて全ブランドへ同じ措置を広げる判断は、運営側の手順として参考になります。

原因は調査中・個人情報保護委員会への報告と警察への被害届を進めている

原因と不正アクセスが可能となった経緯は、詳細を調査中です。発表は、第三者による不正アクセスによるものと確認している、という表現にとどまります。今後は開発会社と関係会社の協力を得て、セキュリティ対策と監視体制を強化するとしています。

同社は個人情報保護委員会への報告と警察への被害届の提出も進めています。個人情報保護委員会の「漏えい等の対応とお役立ち資料」には、不正アクセスによる漏えいの報告の記載例も載っています。民間事業者が報告する段取りは個人情報保護委員会への報告義務で整理しました。

1,078万件はほぼ全会員分｜漏えいした4項目と漏えいしなかった項目の境目

登録数1,080万8,784件の99.8%という件数が示す取得のされ方

漏えい件数を登録数で割ると99.8%で、差は1万9,821件です。アプリの会員のほぼ全員分が出たことになります。特定の会員を1件ずつ狙った取得では、この割合にはなりません。会員管理システムの中から、全件に近い量をまとめて取り出せる経路がどこかにあったと考えるのが自然です。

その経路がAPIなのか、管理画面なのか、データベースそのものなのかは公表されていません。ただし運営側の点検として問うべきことは共通しています。1つの経路から1回で何件まで取り出せるか、そして全件に近い量が取り出されたときに誰が気付けるか、の2つです。

会員番号・氏名・メール・電話番号の4項目と対象外になった生年月日や利用履歴

漏えいしたのは、会員番号、氏名（アプリ登録名）、メールアドレス、電話番号の4項目です。氏名はアプリに登録した名前で、本名とは限りません。一方で、ログインパスワード、生年月日、性別、郵便番号、保有ポイントを含む店舗利用履歴は漏えいしていないと明記されました。

なぜこの4項目だけが出たのかは説明されていません。運営側の設計として言えるのは、1つの経路から読める項目が少なければ、その経路が破られたときに出る項目も少なくなるということです。会員管理の項目と保管の考え方は会員管理システムとはで解説しています。

会員とアプリ利用者が今やること｜身に覚えのないSMSとメールのリンクを開かない

同社は、漏えいした情報がなりすましメールやフィッシング詐欺に悪用されるおそれがあるとして、不審なメール、SMS、電話に注意するよう呼びかけています。身に覚えのないリンクや添付ファイルは開かないでください。同社からパスワードやクレジットカード情報を尋ねることはないとも明言しています。

電話番号とメールアドレスがそろって出ているため、焼肉きんぐやクーポンを装ったSMSが届く可能性があります。クーポンやポイントの確認は、届いたリンクからではなく、インストール済みのアプリを自分で開いて行ってください。問い合わせ先は公式アプリ専用コールセンター（0120-795-775、土日祝日を含む10時〜18時）です。

一覧APIの件数上限と返却項目を確かめる｜OWASP API3とAPI4で点検する手順

API3:2023の画面に必要な最小限の返却項目とAPI4:2023の件数制限

全件規模の取得を許す実装として、まず疑うべきは会員の一覧や検索を返すAPIです。OWASP API Security Top 10 2023のAPI3（Broken Object Property Level Authorization）は、to_json()のような汎用の変換でオブジェクトをそのまま返すのを避け、返す項目を個別に選ぶよう求めています。返すデータ構造は、そのエンドポイントの業務要件に必要な最小限に保つ、という考え方です。

件数の側はAPI4:2023（Unrestricted Resource Consumption）が扱います。応答に含めるレコード数を決めるクエリパラメータについて、明記されているのはサーバー側で検証するという要件です。limit=100000のような値をそのまま受け付けると、1回の呼び出しで会員表の全件が返ります。10項目の全体はOWASP API Security Top 10 2023の全10項目で解説しています。

標準ライブラリで動く一覧APIチェックスクリプトと検証用APIでの実行結果

自社の会員一覧APIが、過大なlimitを受け付けて全件を返さないか、画面に要らない項目を返していないかを確かめるスクリプトです。Python 3の標準ライブラリだけで動きます。MAX_ITEMSとALLOWEDは自社の画面の仕様に合わせて書き換えてください。本番の会員データではなく、検証環境に対して実行します。list_api_check.pyとして保存します。

import json, sys, urllib.request

URL, TOKEN = sys.argv[1], sys.argv[2]
MAX_ITEMS = 50                        # 一覧APIが1回で返してよい件数の上限
ALLOWED = {"member_no", "name"}       # 画面に必要な項目だけを許可する

req = urllib.request.Request(URL + "?limit=100000",
                             headers={"Authorization": "Bearer " + TOKEN})
with urllib.request.urlopen(req, timeout=30) as r:
    items = json.load(r)["items"]

extra = sorted({k for it in items for k in it} - ALLOWED)
ng = 0
if len(items) > MAX_ITEMS:
    ng += 1
    print(f"NG 件数上限: limit=100000で{len(items)}件返った（上限{MAX_ITEMS}）")
else:
    print(f"OK 件数上限: {len(items)}件で打ち切られた")
if extra:
    ng += 1
    print(f"NG 返却項目: 許可外の項目 {extra}")
else:
    print("OK 返却項目: 許可した項目だけ")
sys.exit(1 if ng else 0)

2026年10月6日に、手元で立てた検証用のモックAPIに対して実行した結果です。会員5,000件を持たせ、8771番はlimitをそのまま受け付けて全項目を返す不備ありの版、8772番は件数を50件で打ち切り会員番号と名前だけを返す修正版です。

$ python list_api_check.py http://127.0.0.1:8771/members tokenA
NG 件数上限: limit=100000で5000件返った（上限50）
NG 返却項目: 許可外の項目 ['birth', 'email', 'password_hash', 'tel']

$ python list_api_check.py http://127.0.0.1:8772/members tokenA
OK 件数上限: 50件で打ち切られた
OK 返却項目: 許可した項目だけ

NGが1つでもあれば終了コード1を返すため、CIに組み込んでデプロイのたびに回せます。一覧の件数を絞っても、ページ送りを繰り返せば全件に届くという問題は残ったままです。そこで次の章のログによる検知と、1つの認証情報あたりの呼び出し回数の上限を組み合わせます。上限の方式と429応答の設計はAPIレート制限（レートリミット）とはにまとめています。

全件に近い取得に気付くログ設計｜1つの認証情報が返した会員数を数えるSQL

1時間に会員全体の何%を返したかを認証情報ごとに数えるSQLとサンプルログでの出力

件数上限があっても、1つの認証情報がページを送り続ければ全件に届きます。気付くための手がかりは、応答で返した行数です。APIのアクセスログに、呼び出した認証情報、時刻、エンドポイント、返した行数を記録しておけば、次のSQLで会員全体に対する割合を出せます（SQLiteの構文です）。

SELECT a.principal,
       strftime('%Y-%m-%d %H:00', a.ts) AS hour,
       COUNT(*) AS requests,
       SUM(a.rows_returned) AS rows_out,
       ROUND(100.0 * SUM(a.rows_returned) / (SELECT COUNT(*) FROM members), 1) AS pct_of_members
FROM api_access a
GROUP BY a.principal, hour
HAVING rows_out > 1000 OR pct_of_members >= 1
ORDER BY rows_out DESC;

会員1万人の表と、架空のサンプルログで2026年10月6日に実行しました。一般の会員300人が自分の情報を3回ずつ参照し、管理画面の担当者が検索結果を6回表示し、ある会員の認証情報が一覧APIを200回めくったという想定です。

member:9001 | 2026-10-01 10:00 | 200 | 10000 | 100.0
staff:tanaka | 2026-10-01 10:00 | 6 | 300 | 3.0

一般の会員は1行も出力されません。一覧を200回めくった認証情報は、1時間で会員全体の100.0%を返したことが1行で分かります。管理画面の担当者も3.0%で引っかかっているため、しきい値は利用者の種別ごとに分けた設定が必要です。見るべきログの種類と攻撃痕跡の調べ方は不正アクセスのログ確認・解析方法が参考になります。

しきい値を利用者の種別ごとに決めて遮断と影響範囲の確定につなげる手順

一般の会員は自分の情報しか見ないため、しきい値は低く置けます。管理画面の担当者や連携先のシステムは業務で多くの行を扱うので、通常の最大値を測ってから決めます。運用を組む際の手順は、次に示すとおりです。

通常の1週間分のログで、種別ごとに1時間あたりの返却行数の最大値を測る
会員はその最大値を、担当者と連携先はその2倍を目安に通知のしきい値にする
通知を受けた認証情報は失効させ、同じ接続元からの新しい発行を一時止める
止めた認証情報が返した会員番号の範囲を残し、漏えい件数の確定に使う

4つ目が抜けていると、事故のあとで漏えい件数を確定するまでに時間がかかります。返した行数を記録しておけば、どの会員の情報が何件出たかを後から数えられます。全件規模の流出が起きた別の事例として、Gyazoの不正アクセスと2,362万件の流出も合わせて読んでください。

電話番号とメールアドレスの漏えい後に来るSMSとメールのフィッシングへの備え

運営側が先に決めておく公式の連絡手段とSMSにリンクを入れない方針

会員の電話番号とメールアドレスが出たあと、攻撃者はそのブランドを装ったSMSやメールを送ってきます。会員が本物と偽物を見分ける手がかりは、運営側が事前に決めた連絡の約束だけです。たとえば「当社はSMSにログイン用のリンクを入れない」「重要なお知らせはアプリ内のお知らせ欄にも必ず載せる」と決めて公表しておけば、それに外れる連絡を会員が自分で疑えます。

フィッシングの最新の手口と報告件数はフィッシング対策協議会が公開しています。偽サイトを見つけたときの報告先も、同協議会のサイトで確認可能です。攻撃が成立する仕組みと実装者向けの対策はフィッシング詐欺とはで解説しています。

自社ドメインを騙るメールを受信側で止めるDMARCのp=rejectを確認する

メールの側では、自社のドメインを差出人に使った偽のメールを受信側で止められるかを確かめます。仕組みはDMARCで、2026年5月にRFC 9989として標準化され、従来のRFC 7489を置き換えました。自社ドメインのDMARCレコードは次のコマンドで確認できます。

nslookup -type=TXT _dmarc.example.jp

返ってきたレコードのpの値がnoneなら、なりすましメールは受信側で止まりません。quarantineなら迷惑メールに振り分けられ、rejectなら受信を拒否されます。RFC 9989ではpctタグが廃止され、t=yを付けると受信側は1段階弱いポリシーで扱う点にも注意してください。p=rejectへ上げる手順はDMARCの仕組みとnone・quarantine・rejectの差にまとめています。

会員アプリの一覧APIを今すぐ点検すべき事業者と後回しでよい事業者の判断基準

会員数が数十万件を超え一覧や検索のAPIを持つアプリの事業者の対応

自社のアプリやWebサービスが会員の一覧や検索を返すAPIを持ち、会員数が数十万件を超えるなら、list_api_check.pyに相当する点検を今週中に回してください。アプリが呼ぶAPIだけでなく、管理画面や連携先のシステムが呼ぶAPIも対象に含めます。一覧APIで返す項目と件数が絞られているか、ページ送りの回数に上限があるか、返した行数がログに残るかの3点を確かめます。

複数のブランドや店舗で会員基盤を共有している場合は、とくに優先度が高いと考えます。1つの経路が破られたとき、全ブランドの会員が同時に影響を受けるためです。委託先や外部の仕組みに会員データが残る構図は大和証券の不正アクセスと約11万人分の口座番号でも扱っています。

会員管理を外部のSaaSに任せて一覧APIを持たない小規模アプリで過剰になる場面

会員情報を自社のサーバーに持たず、認証と会員管理を外部のSaaSに任せている小規模なアプリでは、自前で検知SQLを組む運用は過剰です。その場合は、SaaS側の管理者アカウントに多要素認証が掛かっているか、会員の一括エクスポートを誰が実行できるかを確かめれば足ります。

判断に迷うのは、どのAPIや管理画面から会員表の全件に届くのかを社内で把握できていない場合です。会員データへの経路と、返却項目・件数上限・認可の実装を第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、一覧APIから全件を取り出せないかを含めて点検できます。

よくある質問

焼肉きんぐの不正アクセスについて、会員とアプリを運営する担当者から出やすい質問をまとめました。

焼肉きんぐ公式アプリの会員は全員が対象ですか？

ほぼ全員です。公式発表によると、アプリのユーザー登録数1,080万8,784件のうち、漏えいした件数は1,078万8,963件で、割合にすると99.8%にあたります。どの会員が対象外なのかは発表で示されていません。自分が対象かどうかは、公式アプリ専用コールセンター（0120-795-775）で確認してください。

パスワードやクレジットカード情報は漏れていますか？

同社は、アプリのログインパスワードは漏えいしていないと説明しています。クレジットカード等の決済情報はもともと保持していません。生年月日、性別、郵便番号、保有ポイントを含む店舗利用履歴も漏えいしていないとされています。漏えいしたのは会員番号、氏名（アプリ登録名）、メールアドレス、電話番号の4項目です。

不正アクセスの原因や手法は公表されていますか？

公表されていません。発表は、原因と不正アクセスが可能となった経緯について詳細な調査を進めているとし、第三者による不正アクセスによるものと確認している段階です。開発会社と関係会社の協力を得てセキュリティ対策と監視体制を強化するとしており、原因の続報は今後の発表を待つ必要があります。

丸源ラーメンなど他ブランドのアプリも影響を受けていますか？

同社は、他ブランドの公式アプリでは情報漏えい等の事実はないと説明しています。そのうえで、焼肉きんぐ公式アプリと同様の防御措置を他ブランドのアプリにも講じました。焼肉きんぐ公式アプリ自体も、防御措置を講じたうえでサービスの提供を続けています。

自社の会員アプリで同じことが起きないか、何から確かめればよいですか？

最初に、会員の一覧や検索を返すAPIと管理画面の一覧を作ります。次に、検証環境で過大なlimitを渡し、件数が打ち切られるか、画面に要らない項目が返らないかを確かめてください。最後に、1つの認証情報が1時間に会員全体の何%を返したかをログから数えられる状態にします。本記事のスクリプトとSQLはその出発点として使えます。