本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

有名事故・脆弱性

7pay 不正利用事件(2019)— 二段階認証なしの決済アプリはなぜ乗っ取られたか

2019年7月、セブン&アイの決済アプリ『7pay』が公開直後にアカウント乗っ取り被害を受け、約808人・約3,862万円の不正利用が発生し、約3か月でサービス廃止に至りました。核心は二段階認証が無く、パスワード再設定を登録外のメールアドレス宛に実行できたこと。攻撃手順ではなく、あなたのサービスで認証設計をどう固めるか(2FA・安全なパスワード再設定・リスト型攻撃対策・公開前レビュー)を公開記録の事実だけにもとづいて解説します。

公開日 2026-07-07 更新日 2026-07-07 13分で読める

実際に起きた公開事故を、ニュースの再放送ではなく 「あなたの環境でどう防ぐか」 の視点で読み解きます。本記事は 公開記録(企業公式・当局・報道)にもとづく解説です。出典は末尾に明記し、攻撃の再現手順は扱いません。

約3,862万円
不正利用の被害額
約808人
被害を受けた利用者(2019年7月末時点)
約3か月
公開から廃止までの期間
2FA無し
ID+パスワードのみでログイン
事故サマリー / CASE FILE
対象
決済アプリ「7pay」の利用者アカウント(運営:株式会社セブン・ペイ/セブン&アイHD傘下)
発覚
2019年7月2〜3日(公開直後に不正アクセスを認知)
手口分類
二段階認証欠如 + パスワード再設定の宛先を登録外にできる欠陥 → 認証の突破 → 残高の不正利用
影響規模
約808人・被害額 約3,862万円(後の調査で件数は精査)
根本原因
2FA未導入(ID+PWのみ)+ パスワード再設定を登録外メール宛に実行可能 + リスト型攻撃への耐性不足 + 外部ID(7iD)連携の設計不備 + 公開前の認証フロー検証不足
本命の対策
重要操作への2FA必須化・パスワード再設定は登録済み経路限定・リスト型攻撃の検知/ロック・公開前の認証フロー第三者レビュー

何が起きたか(平易に)

スマホ決済アプリは、あなたの お金を動かす権限 を預かります。だからこそ「本人だけがログインでき、他人はできない」という認証の設計が要になります。7payはここが弱く、守りが実質 パスワード1枚 でした。

問題は2つ重なっていました。1つ目は 二段階認証(2FA) が無かったこと。ID+パスワードさえ合えばログインできるので、他社サービスから漏れたID/パスワードの使い回しを試す リスト型攻撃 に弱い状態でした。2つ目は、パスワードを忘れたときの 再設定 の設計です。新しいパスワードを 登録済みとは別のメールアドレス にも送れてしまったため、生年月日・電話番号・メールといった断片的な情報を持っていれば、本来の持ち主でなくてもパスワードを差し替えられました。この2つが合わさると、パスワード1枚の守りを、本人確認の甘い再設定で正面から奪える ことになります。

『お金を動かせる入口』を、単一の弱い認証で守るのは最も危険

攻撃者にとって価値が高いのは、1枚破れば金銭・個人情報に直結する単一の関門です。決済・送金・管理者ログインのような「動かせる価値が大きい入口」を、パスワード1枚+甘い再設定で守るのは、まさにその条件を満たします。これは決済に限らず、1つのログインで残高や全ユーザーのデータに手が届くあらゆる管理画面に共通する危うさです。

攻撃の連鎖は「防御の地図」でもある

この事件も、各段に止め所があった 連鎖でした。攻撃手順ではなく、どこで断ち切れたか として読んでください。

① 入口:ID+パスワードだけのログイン

他所で漏れた資格情報の使い回しが通ってしまう状態。

⊘ 止め所:二段階認証(2FA)・パスキー・リスト型攻撃の検知とロック

② パスワード再設定で本人になりすまし

新パスワードを登録外の宛先にも送れる設計だった。

⊘ 止め所:再設定は登録済み経路のみ・本人確認を強化・再設定の即時通知

③ アカウントを奪って残高を不正利用

乗っ取ったアカウントで決済・チャージが行われた。

⊘ 止め所:重要操作前の再認証・異常な決済の検知と一時停止・利用通知

④ 被害拡大・サービス廃止

全チャージ停止を経て、約3か月でサービスそのものを廃止。

⊘ 止め所:公開前の認証フロー第三者レビュー・そもそも設計段階で単一障害点を作らない

連鎖の各段で“止められた”。多層防御とは、1枚の壁ではなくこの止め所を複数持つこと。

公表された時系列

  1. 2019-07-01

    7pay サービス開始(セブン‑イレブンアプリ内・7iD連携)。
  2. 2019-07-02

    海外IPからのアクセスなど、不正利用に関する第一報が寄せられ始める。
  3. 2019-07-03

    不正利用を認知。海外からのアクセスを遮断し、クレジット/デビットカードからのチャージ(入金)を停止。
  4. 2019-07-04

    記者会見で公表し、全チャージ機能を一時停止。二段階認証の不在が広く指摘される。
  5. 2019-07-05

    経済産業省が対応を要請。原因調査と再発防止の体制強化に着手。
  6. 2019-08-01

    サービスの廃止を発表(安全な再開には相当の時間が必要と判断)。
  7. 2019-09-30

    7pay サービス終了。

根本原因は「1つのミス」ではなく層の崩れ

この事件を「パスワードを破られた」で片付けると、再発します。実際には 認証にまつわる複数の層が同時に薄かった のが本質です。

崩れていた構成(事故時)

  • 決済アプリなのに 二段階認証が無い(ID+パスワードのみ)
  • パスワード再設定を 登録外のメールアドレス宛 に実行できた
  • 他社流出の資格情報を使う リスト型攻撃 に耐えられない
  • 公開前に 認証フローの十分な検証 がされていなかった

守られた構成(再発防止)

  • 重要操作に 二段階認証/パスキー を必須化
  • 再設定の新パスワードは 登録済みの経路のみ に送る
  • リスト型攻撃を想定した 検知・レート制限・ロック
  • 公開前に 認証フローを第三者レビュー(設計段階で単一障害点を潰す)

速さより設計:事後の代償は事前投資よりはるかに大きい

7payは公開直後の被害を受け、全チャージ停止を経て、約3か月で サービスそのものを廃止 しました。競争を急いで認証設計の検証を省くと、信頼の失墜・撤退・作り直しのコストは、事前の設計投資よりはるかに大きくつきます。守る価値(お金・個人情報)に見合った認証を、公開の前に設計しておくことが本質です。

あなたの環境での再発防止

決済を作っていなくても、「1つのログインで大きな価値が動く」入口が1つでもあるなら自分ごとです。優先順の対策です。

1

重要操作に二段階認証(2FA)を用意する

ログインやお金・個人情報を動かす操作に 2FA を用意し、可能なら パスキー のようなフィッシング耐性の高い方式を選ぶ。ワンタイムパスワード(OTP)でもパスワード1枚よりはるかに堅くなる。

2

パスワード再設定を『登録済みの経路だけ』に限定する

新しいパスワードやリセットリンクは、登録済みのメール/電話にのみ 送る。任意の宛先を受け付けない。断片的な個人情報(生年月日・電話番号)だけで本人確認を通さない。再設定が起きたら 即時に本人へ通知 する。

3

リスト型攻撃(使い回し)を想定して検知・制限する

他社流出の資格情報を試す攻撃は前提。レート制限・異常ログインの検知・一定回数でロックを用意し、既知の漏洩パスワードの使用を拒否する。ユーザーには使い回しをやめてもらう導線を作る。

4

公開前に認証フローを第三者レビューする

ログイン・再設定・重要操作の再認証を、設計段階と公開前に別の目でレビューする。「動く」ことと「安全」は別。速さを優先して認証の検証を省かない。

当サイトの設計思想と重なる点

この事件の本質は、価値のある操作を単一の弱い認証で守り、しかも本人確認の甘い経路でその認証を奪えた ことです。当サイト自身の原則——単一障害点を作らない・重要操作は多層で守る・爆発半径を最小化する——とちょうど裏返しの関係にあります。決済に限らず、1つのログインで残高や全ユーザーのデータに手が届く 管理画面は同じ危うさを持ちます。「2FAを足す・再設定は登録済み経路だけ・重要操作の前に再認証」は、規模を問わず誰でも実装できる守りです。

出典(公開記録)

本記事の事実は、以下の公開情報にもとづきます。攻撃の再現手順は扱わず、防御の教訓に絞っています。

  • 株式会社セブン&アイ・ホールディングス「『7pay(セブンペイ)』サービス廃止のお知らせ」(2019) — 7andi.com
  • 株式会社セブン‑イレブン・ジャパン「『7pay』一部アカウントへの不正アクセスの件」(2019) — sej.co.jp
  • 経済産業省「キャッシュレス決済の不正利用に関する対応」関連公表 (2019) — meti.go.jp

次に読む

よくある質問

Q7pay事件の根本原因は何ですか?
A

認証設計の欠陥です。決済アプリでありながら二段階認証(2FA)が無く、ID+パスワードだけでログインできました。さらにパスワード再設定の際、新しいパスワードを『登録済みとは別のメールアドレス』にも送信できたため、生年月日・電話番号・メールといった断片的な情報だけでアカウントを乗っ取れる状態でした。他社から流出したID/パスワードを使い回すリスト型攻撃にも弱い構成でした。

Q決済サービスを作っていない自分にも関係がありますか?
A

あります。本質は『価値のある操作(お金・個人情報)を、パスワード1枚だけで守り、しかも本人確認の甘い再設定でその1枚を奪える』という設計の問題です。ログインに二段階認証を用意する、パスワード再設定は登録済みの経路にだけ送る、重要操作の前に再認証を挟む——この考え方はどんなアプリ・管理画面にも効きます。

Q個人ユーザーとして自衛できることはありますか?
A

あります。①サービスごとにパスワードを使い回さない(リスト型攻撃を無力化)②二段階認証やパスキーが用意されていれば必ず有効にする③決済・送金は利用通知をオンにして異常に早く気づく。運営側の設計が甘くても、使い回しをやめるだけで乗っ取りの主要経路は大きく塞げます。