バーガーキング情報漏洩｜アプリ会員約1,118万件・10項目が流出、なりすましへの備えと開発者の確認

バーガーキング情報漏洩は、国内でバーガーキングを運営する株式会社ビーケー・ジャパンが2026年10月15日に発表した不正アクセスです。「バーガーキング」公式アプリの会員情報を管理するシステムが第三者に侵入され、公式アプリ会員情報 約1,118万件が漏えいしました。漏れたのは氏名・メールアドレス・電話番号・生年月日など10項目で、クレジットカード番号は同社が保持しておらず、漏えいしていないとしています。

開発者が自分のシステムを守る全体の考え方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 に、2026年の国内事案を入口と対策で並べた一覧は セキュリティ事案一覧 にまとめています。

バーガーキング情報漏洩の時系列

不正アクセスの期間が終わってから判明まで6日、判明から発表までは2日でした。同社は不正アクセス元の通信を遮断し、対策本部を設置し、個人情報保護委員会へ報告したとしています。

バーガーキング情報漏洩で漏れた情報と、漏れていない情報

発表の内容を「漏えいした」「漏えいしていない」「分かっていない」の3つに分けると次のとおりです。

注文履歴は「有無」だけで、注文の中身や日時は10項目に含まれていません。件数の単位は「件」なので、約1,118万件をそのまま約1,118万人と読み替えることはできません。

なりすましに使われうる組み合わせ

漏れた項目は1つずつなら目新しくなくても、組み合わせると本物らしい連絡を作れます。本件で二次被害は確認されていないと同社は説明しています。下の表は、こうした情報が使われうる手口の一般的な例です。

バーガーキング情報漏洩で利用者がやること

同社の呼びかけは、同社を装った不審なメール・SMS・電話に注意し、記載のURLを開いたり、会員情報やパスワードを入力したりしないことです。これに沿って、利用者がやることを並べます。

・連絡の真偽は届いた経路で確かめない。公式アプリか、ブラウザで自分で開いた公式サイトのお知らせと照らし合わせる
・アプリのパスワードを他のサービスでも使っていれば、そちらを別のものにする。漏えいは現時点で確認されていませんが、使い回しがあると1か所の漏えいが他のサービスに広がります
・退会しても、すでに漏れた記録は消えない。退会やアカウント削除をするかどうかと手順は、公式アプリと同社の案内に従う

使い回しが狙われる仕組みと、サービス側の守り方は リスト型攻撃の対策｜他社で漏れたパスワードで自社が破られる仕組みと、パスワード漏洩確認の実装・ログでの検知 で扱っています。

カード番号の非保持と会員基盤を持つ開発者の教訓

今回、漏えいの範囲を区切ったのは「何を持っていたか」でした。会員システムがカード番号を持っていなかったので、侵入されてもカード番号はそこから出ていきません。発表から言えるのはここまでで、決済の仕組みの中身は公表されていません。

会員基盤を設計・運用する側が持ち帰れる点を、表にまとめます。

正しい認証のまま大量に引かれるAPIの止め方は APIレート制限の設計 で、会員情報を返すAPIが悪用された事案は ソースネクスト情報漏洩 で扱っています。パスワードの保存や個人情報の最小化といった連載の他の回は、セキュリティ事案一覧 の対策の列からたどれます。今回の侵入経路は公表されていないため、どの対策が本件に当てはまるかは分かりません。

会員APIの大量読み出しを確かめるコマンド

本件の侵入経路は未公表です。ここでは一般的な点検として、会員情報を返すAPIのアクセスログから「1つのクライアントが1日に何人分の会員を読んだか」を数えます。nginx の標準形式（combined）で、会員の取得が /api/members/<数字> の形のURLだと仮定しています。

# 会員APIのアクセスログを読み、「クライアント（IP）×日」ごとに、成功応答で返した会員IDの種類を数える（読み取りだけ）
LOG=${LOG:-/var/log/nginx/access.log}   # 自分のログの場所に置き換える
LIMIT=${LIMIT:-200}                      # 1クライアントが1日に見る会員IDの目安。自社の通常値から決める
awk -v limit="$LIMIT" '
  $9 ~ /^2/ && match($7, /^\/api\/members\/[0-9]+/) {
    id  = substr($7, 14, RLENGTH - 13)    # "/api/members/" の後ろの数字
    key = $1 " " substr($4, 2, 11)        # IP と日付（例: 03/Oct/2026）
    if (!((key, id) in seen)) { seen[key, id] = 1; n[key]++ }
  }
  END { for (k in n) printf "%s %d%s\n", k, n[k], (n[k] > limit ? " 多い" : "") }
' "$LOG" | sort -k3,3nr | head -5

URLの形が違うなら /api/members/ と 14（その文字数＋1）を、ログにAPIキーや利用者の識別子を残しているなら $1 をその列に置き換えます。mawk 1.3.4 で、合成したログに陽性対照と陰性対照を作って確かめました。

# 陰性対照（利用者40人が自分の会員情報を見る＋店舗端末1台が1日60人分を見る、2,052行）
192.0.2.50 02/Oct/2026 60
192.0.2.50 03/Oct/2026 60
198.51.100.10 02/Oct/2026 1
198.51.100.10 03/Oct/2026 1
198.51.100.11 02/Oct/2026 1
# 陽性対照（上に、1クライアントが連番の会員ID 3,000件を成功応答で、存在しないID 500件を404で読む行を足した5,552行）
203.0.113.7 03/Oct/2026 3000 多い
192.0.2.50 02/Oct/2026 60
192.0.2.50 03/Oct/2026 60
198.51.100.10 02/Oct/2026 1
198.51.100.10 03/Oct/2026 1

陰性対照では目安の200を超える行は出ず、陽性対照では大量に読んだ1クライアントだけが先頭に「多い」付きで出ました。404の500件は数えていません。

この結果はログの形から見た目安です。侵害の判定ではありません。「多い」が出ても、社内のバッチや店舗の端末、多くの利用者が1つのIPを共有する携帯回線のように、正当な理由があることがあります。逆に何も出なくても、これだけでは安全とは言えません。多数のIPに分けた少しずつの読み出し、ログの保存期間より前の出来事、URL以外（POSTの本文など）で会員IDを渡すAPIは見ていないからです。最終判断はAPIの認可の設計と監査ログの突き合わせで行ってください。

影響範囲と、分かっていないこと

2026年10月17日時点で、発表から分かることと分からないことを分けます。

続報では侵入経路と再発防止策、パスワードの扱いの調査結果、対象者への案内の範囲を見ると、自分の対応を見直しやすくなります。続報が出たら、本記事も更新します。

参照ソース

• 株式会社ビーケー・ジャパンの発表 2026-10-15（PDF）
• バーガーキング 公式サイト「お知らせ」一覧
• BleepingComputer “Burger King Japan data breach exposes 11 million customer records”