バーガーキングを国内で運営するビーケー・ジャパンは2026年10月15日、バーガーキング公式アプリの会員情報を管理するシステムが第三者から不正アクセスを受け、公式アプリ会員の情報が外部に漏えいしたと公表しました。対象は約1,118万件で、会員ID、氏名、生年月日、電話番号など10項目です。本記事では、まず会員の側が確かめたい「届いた案内は本物か」「パスワードを変えるべきか」「どこに問い合わせるか」に公式発表の文言で答えます。後半では、会員アプリを運営する側が、不正アクセスの期間をログから割り出す方法と、初日に気付くための仕組みを、手元で動かしたSQLとPythonで示します。
まとめ：バーガーキング公式アプリの不正アクセスで公表された事実と会員がやること
確定しているのは次の事実です。2026年10月2日（金）から10月7日（水）にかけて不正アクセスが行われ、会員情報が漏えいしたことが10月13日（火）に判明しました。同社は不正アクセスの事実を把握した後、直ちに通信元からのアクセスを遮断しています。漏えいしたのは約1,118万件の公式アプリ会員情報です。クレジットカード番号は同社が保持しておらず漏えいしていません。ログインパスワード情報の漏えいは、公表時点で確認されていません。
会員がやることは、届いたメールやSMSのリンクを開かず、アプリを自分で開いて確かめることです。原因と不正アクセスが可能になった経緯は外部専門機関と調査中のため、本記事は原因を断定しません。運営側が学べるのは、6日間続いた不正アクセスが判明までさらに6日かかったという時間の側です。期間を後から割り出せるログと、初日に気付ける仕掛けがあるかを確かめてください。
| 項目 | 公表されている内容 |
|---|---|
| 不正アクセスの期間 | 2026年10月2日〜10月7日 |
| 漏えいの判明 | 2026年10月13日（火） |
| 公表 | 2026年10月15日 |
| 対象 | 公式アプリ会員情報 約1,118万件 |
| カード番号 | 保持しておらず漏えいなし |
| ログインパスワード | 漏えいは現在確認されず |
| 原因 | 外部専門機関と調査中 |
会員が最初に確かめる4点｜案内メールの真偽・対象の確認・パスワード・問い合わせ窓口
同社からの案内メールと、同社を装った偽のメールやSMSの見分け方
同社は「継続・順次実施中」の対応として、対象の会員へメールで案内を送っています。つまり、同社名のメールが届くこと自体は不自然ではありません。一方で同社は、当社や当社サービスを装った不審なメール、SMS、電話にも注意するよう呼びかけています。不審な連絡を受け取った場合は、URLへのアクセス、添付ファイルの開封、会員情報やパスワードの入力をしないようにと明記しました。
本物と偽物を本文の見た目で見分けるのは困難です。メールやSMSのリンクからは何も入力せず、インストール済みのバーガーキング公式アプリを自分で開くか、下記の問い合わせ窓口に自分で電話をかけて確かめてください。クーポンやポイントを口実にしたSMSも、届いたリンクではなくアプリ側で確認すれば足ります。
公式アプリ会員が漏えい対象かどうかとパスワード変更の要否の確認
対象は「公式アプリ会員情報 約1,118万件」で、どの会員が対象外かは発表に書かれていません。対象の会員には同社からメールで案内が届くとされているため、まずアプリの登録メールアドレスの受信箱を確認します。迷惑メールのフォルダも確認してください。判断がつかないときは窓口で確かめます。
ログインパスワードは「漏えいは現在確認されておりません」とされ、同社は会員にパスワード変更を求めてはいません。ただし、同じパスワードを他のサービスでも使い回しているなら、そちらは変えておくと安心です。使い回しを避ける考え方はパスワード管理のベストプラクティスで整理しています。
会員の問い合わせ先と受付時間｜平日10時〜17時のカスタマーサービス
会員からの問い合わせ先は、ビーケー・ジャパンのカスタマーサービス（電話0120-945-630、平日10時〜17時、土日祝日は休業）です。メールの窓口も公式発表（2026年10月15日・PDF）に記載されています。電話番号は、届いたメールやSMSに書かれた番号ではなく、公式発表に載っている番号にかけてください。
公式発表を時系列で確認する｜10月2日から7日の不正アクセスと13日の判明まで
6日間続いた不正アクセスと、判明までにかかったさらに6日間の経緯
公式発表によると、同社は会員情報を管理するシステムへの第三者による不正アクセスの可能性を確認し、調査を行いました。その結果、10月2日（金）から10月7日（水）にかけて不正アクセスが行われ、会員情報が漏えいしたことが10月13日（火）に判明しています。公表は判明の2日後、10月15日です。
不正アクセスの開始から判明までは11日、最後の不正アクセスから判明までは6日です。いつ「可能性」に気付いたのか、遮断がどの日だったのかは、発表からは読み取れません。発表時点で、本件に起因する不正利用などの二次被害は確認されていないとしています。
運営元の実施済みの対応と継続中の対応・個人情報保護委員会への報告
実施済みとされているのは、不正アクセス元からの通信の遮断、暫定対策の実施、対策本部の設置、個人情報保護委員会への報告の4つです。継続・順次実施中なのは、恒久対策の実施、外部専門機関と連携した各種調査、対象会員へのメールによる案内です。再発防止策として、システムのセキュリティ対策と監視体制を強化するとしています。
不正アクセスによる漏えいは、個人情報保護委員会への報告の対象です。個人情報保護委員会の「漏えい等の対応とお役立ち資料」に報告の記載例が載っています。民間事業者が速報と確報を出す段取りは個人情報保護委員会への報告義務で整理しました。
2024年10月にも公式アプリでの漏えいのお知らせが報じられていた
同社は2024年10月22日にも、公式アプリでの情報漏えいについてお知らせを出していたとScanNetSecurity（2024年10月31日）が報じています。当時の公式PDFは文字を選択できない形式で、本記事では内容を確かめられていません。今回の事案との関係も、今回の発表には書かれていません。
約1,118万件で漏れた10項目｜生年月日・氏名・電話番号がそろう意味と対象外の情報
会員IDからメールアドレス認証の有無まで、公式発表に並んだ10項目
漏えいした内容として公式発表に並んでいるのは、会員ID、メールアドレス、登録種別、都道府県、性別、生年月日、氏名（漢字・カナ）、電話番号、モバイルオーダー履歴の有無、メールアドレス認証の有無の10項目です。モバイルオーダーは「履歴の有無」で、注文の中身が出たとは書かれていません。
同じ月に公表された焼肉きんぐの不正アクセスでは、漏えいは会員番号、氏名（アプリ登録名）、メール、電話番号の4項目で、生年月日は対象外でした。今回は生年月日と、漢字とカナの氏名が含まれます。件数は近くても、出た項目の組み合わせが違います。
生年月日と氏名と電話番号の漏えいで増える窓口のなりすましの危険
氏名、生年月日、電話番号の3つは、電話やチャットの窓口で本人確認に使われやすい組み合わせです。これがそろうと、会員本人になりすまして他のサービスの窓口に連絡し、登録情報の変更を頼む手口が成り立ちやすくなります。会員の側は、身に覚えのない「登録情報を変更しました」という通知に注意してください。
メールアドレス認証の有無と都道府県も出ているため、受け取る側の状況に合わせた文面のフィッシングも作れます。フィッシングが成立する仕組みと実装者向けの対策はフィッシング詐欺とはで解説している内容です。手口の最新情報と報告件数はフィッシング対策協議会が公開しています。
6日間の不正アクセスの期間をログから割り出す｜認証情報ごとの初日と最終日を出すSQL
OWASP A09:2025が求める「後日の調査に足る期間のログ」と記録する4項目
今回の発表は、不正アクセスの期間を「10月2日から7日」と日付で示しています。期間を言い切れるのは、その間のアクセスの記録が残っていたからだという読み方です。運営側が自社で同じことをできるかは、ログの中身と保持期間で決まります。
OWASP Top 10:2025のA09（Security Logging and Alerting Failures）は、ログインやアクセス制御の失敗を利用者の文脈とともに記録し、後日のフォレンジック分析ができる期間だけ保持するよう求めています。会員データを返すAPIでは、呼び出した認証情報、時刻、エンドポイント、返した行数の4項目を1行ずつ残す運用にしてください。ログの見方と攻撃痕跡の探し方はセキュリティログ分析の手法にまとめています。
1日の返却行数がしきい値を超えた認証情報の初日・最終日・合計を出すSQL
次のSQLは、アクセスログ（api_access）から認証情報ごと・日ごとの返却行数を集計し、1日500行を超えた日だけを残して、その認証情報の初日、最終日、日数、合計行数を出します。SQLiteの構文で、period.sqlとして保存します。500はサンプルの値なので、自社の通常の最大値を測ってから決めてください。
WITH daily AS (
SELECT principal,
date(ts) AS day,
SUM(rows_returned) AS rows_out
FROM api_access
GROUP BY principal, day
),
flagged AS (
SELECT d.*,
ROUND(100.0 * d.rows_out / (SELECT COUNT(*) FROM members), 1) AS pct
FROM daily d
WHERE d.rows_out > 500
)
SELECT principal,
MIN(day) AS first_day,
MAX(day) AS last_day,
COUNT(*) AS days,
SUM(rows_out) AS rows_total,
MAX(pct) AS max_pct_per_day
FROM flagged
GROUP BY principal
ORDER BY rows_total DESC;2026年10月16日に、架空のデータで実行しました。会員1万件と次の章で使う架空会員3件の表に、9月28日から14日分のアクセスログ8,839行を入れています。一般の会員300人が自分の情報を1日1〜3回参照し、店舗の担当者が1日20回、20件ずつ検索します。そこに、ある会員の認証情報が10月2日から7日まで、一覧を50件ずつ1日34回めくる記録を混ぜました。
member:8812 | 2026-10-02 | 2026-10-07 | 6 | 10003 | 17.0出力は1行だけです。1日あたりは会員全体の17.0%と目立たない量でも、6日で全件にあたる10,003行を返したことと、期間が10月2日から7日であることが分かります。1日の量が少ないため、日ごとのしきい値だけでは気付きにくい点に注意してください。
期間を割り出すにはログを最低でも事案の判明後まで消さずに残す
このSQLが働くのは、期間の初日のログがまだ残っている場合だけです。今回の事案では開始から判明まで11日でした。アクセスログの保持が7日なら、判明した時点で初日の記録は消えています。会員データを返すAPIのログは、少なくとも90日を目安に、アプリのサーバーとは別の場所へ追記専用で送ってください。A09:2025も、ログがローカルにしかなくバックアップされていない状態を失敗の例に挙げています。
架空会員（ハニートークン）での初日検知｜OWASP A09:2025に沿うスクリプト
会員表に本物の会員と区別できない架空会員を混ぜておく検知の仕組み
期間を後から割り出せても、気付くのが遅ければ被害は広がります。A09:2025は防止策の1つとして、アプリケーションに攻撃者を誘う罠「ハニートークン」を入れることを挙げています。通常の業務では使われないため、アクセスがあれば誤検知のほとんどない通知になる、という考え方です。
会員アプリに当てはめると、会員表に実在しない架空の会員を数件入れておく形になります。架空会員は本物の会員と同じ形式の会員IDを持ち、ID帯の先頭、中ほど、末尾に散らして置く設計です。一覧や検索のAPIがこの会員を返したら、誰かが本来見るはずのない範囲を見ています。
アクセスログから架空会員の返却を拾う標準ライブラリのPythonスクリプト
次のスクリプトは、APIが返した会員IDを1行ずつ記録したJSON Lines形式のログを読み、架空会員を返した認証情報を通知します。Python 3の標準ライブラリだけで動き、honeytoken_check.pyとして保存します。DECOY_IDSは自社で決めた架空会員の会員IDに書き換えてください。
import json, sys
# 会員表に入れておいた架空会員（ハニートークン）の会員ID
DECOY_IDS = {"M00000451", "M00004999", "M00009502"}
hits = {}
with open(sys.argv[1], encoding="utf-8") as f:
for line in f:
rec = json.loads(line)
found = DECOY_IDS & set(rec["ids"])
if found:
h = hits.setdefault(rec["principal"], {"first": rec["ts"], "count": 0})
h["count"] += len(found)
h["last"] = rec["ts"]
for p, h in hits.items():
print(f"ALERT {p}: 架空会員を{h['count']}回返却 初回={h['first']} 最終={h['last']}")
sys.exit(1 if hits else 0)前の章と同じ架空のログ（会員ID付き）に対して、2026年10月16日に実行した結果です。
$ python honeytoken_check.py access.jsonl
ALERT member:8812: 架空会員を3回返却 初回=2026-10-02 03:02:00 最終=2026-10-07 06:44:00一覧をめくり始めた初日の10月2日3時2分の時点で、通知が1件出ています。一般の会員300人と店舗の担当者は1件も引っかかりませんでした。通知が出たら1分ごとに回す仕組みにしておけば、6日間を待たずに認証情報を止められます。
架空会員を末尾にまとめて置くと最終日まで気付けなかった検証結果
最初の検証では、架空会員の会員IDを本物の会員より後ろの番号にまとめて振りました。すると通知が出たのは、一覧の末尾まで達した最終日の10月7日でした。ID順にめくられる取得では、罠を末尾に置くと最後まで踏まれません。架空会員は本物と同じ番号帯に散らして振ってください。
もう1つの注意点は、店舗の担当者が業務で使う検索画面に架空会員が出ないようにすることです。管理画面の検索結果にだけ出さないフラグを持たせ、APIの全件取得や一覧のページ送りには混ぜたままにします。APIの認可やレート制限の実装はAPI不正アクセス対策の実装手順で扱っています。
生年月日と電話番号で本人確認する窓口の見直しと自社ドメインのDMARCの確認
漏えい済みの項目だけで本人確認が通る窓口での追加確認による対策
今回のように氏名、生年月日、電話番号がまとめて出ると、それだけで本人確認を通す窓口は、なりすましに弱くなります。自社のコールセンターやチャットで、登録情報の変更やポイントの移行をこの3項目だけで受け付けていないかを確かめてください。登録済みのメールアドレスやアプリへのワンタイムの確認を1段足せば、項目を知っているだけの第三者は通れません。
自社ドメインを騙るメールを受信側で止めるDMARCのp=rejectを確認する
漏えいのあとは、運営元を装ったメールが会員に届きます。受信側で止められるかを決めるのがDMARCで、2026年5月にRFC 9989として標準化されました。2026年10月16日に公開DNSで確かめたところ、burgerking.co.jpのDMARCレコードは「v=DMARC1; p=none;」でした。自社ドメインのレコードは次のコマンドで確認できます。
nslookup -type=TXT _dmarc.example.jppの値がnoneなら、ドメインを騙ったメールは受信側で止まりません。quarantineなら迷惑メールに振り分けられ、rejectなら受信が拒否されます。会員への案内をメールで送る事業者は、正規の送信元を全てSPFとDKIMにそろえたうえでrejectへ上げてください。手順はDMARCのquarantineとrejectの違いにまとめています。
会員ログの点検を今すぐ進めるべき事業者と外部SaaS任せで後回しにできる事業者
会員数が数十万件を超え、自社で会員データを返すAPIを持つ事業者
自社のアプリやWebサービスが会員データを返すAPIを持ち、会員数が数十万件を超えるなら、今月中に次の3点を確かめてください。会員データを返すAPIのログに認証情報と返却行数が残っているか、そのログが判明までの期間を超えて残るか、架空会員のような初日に気付ける仕掛けがあるかです。1つでも欠けていれば、今回と同じ事態で期間も件数もすぐには言えません。
一覧APIで1回に返す件数と項目を絞る対策は焼肉きんぐの不正アクセスの記事で、他人の会員IDで操作が通らないかの点検はセイコーマートの不正アクセスと57万人の会員情報で解説しました。漏えいの原因別の防ぎ方は情報漏洩対策とはが入口になります。
会員管理を外部のSaaSに任せている小規模アプリで過剰になる場面
会員情報を自社のサーバーに持たず、認証と会員管理を外部のSaaSに任せている小規模なアプリでは、自前で架空会員と検知の仕組みを組む運用は過剰です。その場合は、SaaSの監査ログが何日残るか、管理者アカウントに多要素認証が掛かっているか、会員の一括エクスポートを誰が実行できるかの3点を確かめれば足ります。
判断に迷うのは、どの経路から会員表の全件に届くのか、そのログがどこに何日残るのかを社内で答えられない場合です。会員データへの経路とログの残り方を第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、APIからの大量取得と記録の抜けを含めて点検できます。
よくある質問
バーガーキングの不正アクセスについて、会員とアプリを運営する担当者から出やすい質問をまとめました。
バーガーキング公式アプリの会員は全員が対象ですか？
発表は対象を「公式アプリ会員情報 約1,118万件」としており、どの会員が対象外かは示していません。対象の会員には同社からメールで案内が届くとされています。判断がつかないときは、ビーケー・ジャパンのカスタマーサービス（0120-945-630、平日10時〜17時）で確認してください。
パスワードは変更したほうがよいですか？
同社はログインパスワード情報の漏えいは現在確認されていないとしており、会員に変更は求めていません。同じパスワードを他のサービスで使っている場合は、そちらを別のパスワードに変えておくと、今後の続報で状況が変わっても慌てずに済みます。
同社から届いた案内メールは本物ですか？
同社は対象の会員にメールで案内を送っているため、同社名のメールが届くこと自体はあり得ます。ただし同社を装った偽のメールやSMSにも注意するよう呼びかけています。メール内のURLは開かず、アプリを自分で開くか、公式発表に載っている電話番号に自分でかけて確かめてください。
クレジットカード情報は漏れていますか？原因は何ですか？
クレジットカード番号は同社が保持しておらず、漏えいしていないと明記されています。原因は第三者による不正アクセスと確認した段階で、不正アクセスが可能となった経緯と詳細な原因は外部専門機関と調査中です。手口は公表されていないため、続報を待つ必要があります。
自社の会員アプリで同じことが起きたとき、期間と件数を言えるか何から確かめればよいですか？
最初に、会員データを返すAPIのログに、認証情報、時刻、エンドポイント、返却行数が残っているかを確かめます。次に、そのログが何日残るかを確かめ、判明までの日数を超えて残る設定にしてください。最後に架空会員を数件、番号帯に散らして入れ、返却されたら通知が出る状態にします。本記事のSQLとスクリプトはその出発点として使えます。
関連記事
- 焼肉きんぐ不正アクセスで1,078万件の情報漏洩｜対象の確認方法・原因と運営側のAPI点検：一覧APIの件数上限と返却項目の点検
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効：APIの認可とレート制限の実装
- セイコーマートの不正アクセスと57万人の会員情報｜アプリAPIの認可を点検する手順：他人の会員IDで操作が通らないかの点検
- タイムズカー情報漏洩・流出：対象の確認と補償、0120-25-8924は本物か、免許証画像への備え：届いた連絡の真偽を確かめる事例
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の段取り
- ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検：同じ週に公表された、会員情報取得APIの不正利用による事案と返却項目の点検
