プリペイド式Visaカードのアプリ「ultra pay カード」と「PayBlend」を運営する株式会社Yenyは2026年11月12日、第三者の不正アクセスで会員情報が漏えいしたと公表しました。漏れたのは電話番号と同社固有の会員IDで、件数は退会者を含む1,332,505件です。決済情報の漏えいは、公表時点で確認されていません。前半では、対象のサービスと自分への案内の届き方、漏れた電話番号で起こりうること、偽のSMSへの備え、退会と個人情報の消去を、公式発表とサポートFAQで確かめます。後半は原因とされた「API接続設定の不備」を、接続先ごとの設定と読み取り件数で点検するコードで示します。
まとめ：Yeny不正アクセスで漏れた電話番号と会員ID、利用者が今日やること
Yenyは10月31日、接続先の事業者から不審なAPIコールの連絡を受けて調査を始めました。11月2日にAPI接続の設定不備が原因だと確かめて緊急メンテナンスで対応し、11月5日に電話番号と会員IDの漏えいを確認しています。同社は、漏れた情報だけでは不正ログインや決済には使えないと説明しています。
利用者がやることは3つに絞れます。Yenyを名乗るSMSや電話でパスワードやカード情報を聞かれても答えないこと。ultra pay と同じパスワードを他のサービスで使っているなら、そちらを先に変えること。もう使わないなら、残高を確かめてから退会と情報の消去を申し込むことです。
| 項目 | 公表内容（2026年11月12日15時時点） |
|---|---|
| 運営会社 | 株式会社Yeny（TISインテックグループ） |
| 対象サービス | ultra pay カード／PayBlendの3種 |
| 件数 | 1,332,505件（退会者を含む） |
| 漏えいした情報 | 電話番号、Yeny固有の会員ID |
| 確認されていない情報 | クレジットカード番号等の決済情報 |
| 原因 | Yeny側のAPI接続設定の不備 |
| 対象者への案内 | 各アプリ内のお知らせ欄 |
| 未公表 | 侵入の開始時期・接続先の名称・不備の中身 |
ultra payとPayBlendの利用者が確かめること：対象、ログイン、偽SMS
対象となる4サービスと、アプリ内のお知らせ欄に届く個別の案内
Yenyの公式発表が対象に挙げるのは、ultra pay カード、アスルクラロ沼津Pay、巫神こんPay、東芝ブレイブルーパス東京Payの4サービスです。後ろの3つは、チームや配信者を応援するファン向けのカードを出すPayBlendの提携アプリにあたります。ultra pay カードは、ultra payのお知らせ一覧にあるとおり、2024年10月23日に株式会社ULTRAから社名を変えたYenyのサービスです。
対象者への連絡は、メールやSMSではなく各アプリ内のお知らせ欄で行うと発表されています。照会用のWebページや電話窓口は設けられておらず、問い合わせの受付先は、公式発表に載ったお問い合わせフォームです。件数に退会者が含まれるため、すでに退会した人も対象になりえます。この1,332,505件が人数なのか、サービスごとの登録件数の合計なのかは公表されていません。
漏れた電話番号はログインに使う値、パスワードの使い回しを断つ
ultra pay カードとPayBlendのアプリは、電話番号とパスワードでログインします。サポートFAQの「ログインできない」は、確認項目の最初に「電話番号またはパスワードが間違っていませんか」を挙げています。今回漏れたのは、このうち電話番号の側です。
Yenyはパスワードの漏えいを発表しておらず、漏れた情報だけではログインできないとしています。注意したいのは、他のサービスから漏れたパスワードとの組み合わせです。同じパスワードを使い回していると、電話番号と組にして試される余地が残るからです。パスワードの再設定は、アプリで登録電話番号に届くSMSの認証番号と生年月日を入れて行います。複数回ログインに失敗するとロックがかかる仕様もFAQに書かれています。
Yenyを名乗るSMSや電話で、パスワードとカード情報を聞かれたら偽物
公式発表は、今後Yenyを装った不審なSMSや電話が届く可能性があると注意を促しています。同社がSMSや電話でパスワードやカード情報の入力を頼むことはありません。心当たりのないSMSは、本文のURLを開かず、個人情報も入れずに削除するよう案内しています。
電話番号と会員IDが手元にある相手は、「ultra pay 会員ID ◯◯の方へ」と本物らしい文面を作れます。会員IDが合っていても、それだけで本物と判断しないでください。このアプリはSMS以外の認証方法に対応していないため、認証番号を聞き出すSMSや電話は特に危険です。届いた認証番号を人に伝えると、パスワードの再設定に使われるおそれがあります。偽の連絡が本物らしく見える仕組みはフィッシング詐欺の成立の仕組みと技術的対策で解説しました。
退会と個人情報の消去を申し込む手順、残高は放棄になる点に注意
もう使わないなら、FAQの退会・解約の手順に沿って手続きできます。
- アプリの「その他」メニューから、画面下部の「退会について」を選ぶ
- 注意事項を確かめる（残高がマイナス、後払いの支払いが未確認、リアルカードの発行依頼中や発送中は退会できない）
- 残高の放棄確認画面で、残高を放棄してよいか確かめて進む
- 退会確認画面と再確認画面で「退会する」を押して完了させる
退会しても登録情報がすぐに消えるわけではありません。アカウント・個人情報の消去は、退会したうえで、問い合わせフォームから別に申し込みます。その際、アプリに登録した電話番号、生年月日、氏名、メールアドレス、解約日を申告し、登録内容と一致しなければ受け付けられません。残高は退会時に放棄になるため、使い切ってから手続きするのが損のない順番です。
公表で追う経過：10月31日の不審なAPIコールから11月12日の公表まで
接続先からの連絡で発覚し、12日後に公表するまでの調査の時系列
公式発表の経緯を日付順に並べると、次のとおりです。
- 10月31日：Yenyが接続する特定の事業者から、不審なAPIコールが発生したと連絡を受け、初期調査を始める
- 11月2日：同じ事業者から電話番号が漏えいした可能性の連絡。API接続の設定不備が原因と確認し、緊急サービスメンテナンスで対応
- 11月3〜4日：原因と影響の詳細を調査
- 11月5日：電話番号と会員IDの漏えいを確認
- 11月6日：関東財務局と個人情報保護委員会に報告
- 11月12日：公表
異常に最初に気付いたのは、Yeny自身ではなく接続先の事業者でした。不審なAPIコールがいつから続いていたのか、接続先の名称、設定不備の具体的な中身は11月13日時点で公表されていません。同社は今後、設定の是正に加えて、不審なアクセスの監視と検知の体制を見直すとしています。
関東財務局と個人情報保護委員会の両方へ報告した理由と未公表の事項
Yenyは、前払式支払手段（第三者型）の発行者として関東財務局長第00727号、資金移動業者として同第00097号の登録を受けています。金融庁の所管する事業者のため、個人情報保護委員会と並んで関東財務局にも報告しています。前払式支払手段と資金移動業の区分は資金決済法の前払式支払手段と資金移動業の区分で整理しました。
個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある漏えいは、件数にかかわらず報告の対象です。Yenyは11月5日の漏えい確認の翌日に報告しており、日付から見て速報の段階です。確報では原因や再発防止策をまとめるため、続報で不備の中身が出てくる可能性があります。報告の段取りは個人情報保護委員会への報告義務の実務で解説しています。
API接続設定の不備をOWASP API Top 10の2項目で読み解く
接続先に返す項目が広すぎた場合はAPI3:2023のプロパティ単位の認可
公表されている原因は「API接続設定の不備」だけで、どの設定がどう誤っていたかは書かれていません。ここから先は、決済や会員の基盤を外部とAPIでつなぐときに、同じ言葉で説明されやすい不備の型を整理したものです。Yenyの事案がどれに当たるかは断定できません。
1つ目は、接続先の業務に要らない項目まで返してしまう形です。OWASPのAPI3:2023 Broken Object Property Level Authorizationは、利用者が読むべきでない機密のプロパティを返すAPIを脆弱と定義しています。対策は、汎用の変換関数で全項目を返さず、返す項目を個別に選び、応答をスキーマで検証することです。決済結果を伝えるだけの接続先に電話番号を返す設計は、この型に当たります。
サービス境界や接続元の制限が外れていた場合はAPI8:2023の設定不備
2つ目は、接続先のキーで他のサービスの会員まで読める、あるいは接続元のIPアドレスを絞っていない形です。OWASPのAPI8:2023 Security Misconfigurationは、すべての環境で設定の有効性を自動で評価し続ける仕組みと、APIスタック全体の設定の定期的な見直しを求めています。PayBlendのように1つの基盤に複数の提携アプリが載る構成では、接続先ごとにどのサービスの会員を読めるかという境界が設定の一部になります。
どちらの型でも、1件ずつ正しく認証されたAPIコールが大量に続くため、ログイン失敗の監視では見つかりません。API4:2023 Unrestricted Resource Consumptionが扱う呼び出し量の上限も、接続先ごとに置いていなければ働きません。全10項目の位置付けはOWASP API Security Top 10 2023の全10項目と対策にまとめました。
開発側の点検：接続先ごとの返却項目・境界・読んだ会員数を確かめるコード
接続先の設定を利用目的と突き合わせて、不要な個人情報を拾う点検
次のスクリプトは、架空の接続先2社のAPI設定と架空のアクセスログを使い、2つの点検をまとめて行います。前半は、接続先ごとの返却項目を利用目的と突き合わせ、サービス境界と接続元の制限が広すぎないかを調べる構成です。後半は、接続先ごと・時間帯ごとに「読んだ会員IDの種類数」を数え、前の時間帯の5倍を超えたら知らせます。
# 接続先ごとのAPI設定を点検し、アクセスログから「1時間に読んだ会員数」の急増を拾う（Python 3.9以上・標準ライブラリのみ）
# 設定もログも架空のデータ。実在のサービスのAPIには一切アクセスしない
import ipaddress
from collections import defaultdict
# 接続先（パートナー）ごとのAPI設定。purposeに必要な項目だけを返すのが原則
CLIENTS = {
"partner-a": {"purpose": "決済結果の通知", "services": ["fanpay-1"],
"fields": ["member_id", "status"], "allow_ips": ["203.0.113.0/28"]},
"partner-b": {"purpose": "決済結果の通知", "services": ["*"],
"fields": ["member_id", "status", "phone"], "allow_ips": ["0.0.0.0/0"]},
}
NEEDED = {"決済結果の通知": {"member_id", "status"}} # 目的ごとに本当に要る項目
SENSITIVE = {"phone", "email", "birthday", "name"}
def lint(cid, c):
issues = []
extra = set(c["fields"]) - NEEDED[c["purpose"]]
if extra & SENSITIVE:
issues.append(f"目的に不要な個人情報を返す: {sorted(extra & SENSITIVE)}")
if "*" in c["services"]:
issues.append("全サービスの会員を読める（サービス境界なし）")
for cidr in c["allow_ips"]:
if ipaddress.ip_network(cidr).num_addresses > 256:
issues.append(f"接続元の制限が広すぎる: {cidr}")
return issues
for cid, c in CLIENTS.items():
found = lint(cid, c)
print(f"[設定] {cid}: " + ("OK" if not found else " ／ ".join(found)))
# アクセスログ（時刻, 接続先, 読んだ会員ID）。partner-bは10時台に連番で大量に読んでいる
LOG = [(f"09:{m:02d}", "partner-a", f"M{m:05d}") for m in range(40)]
LOG += [(f"10:{m:02d}", "partner-a", f"M{m + 40:05d}") for m in range(45)]
LOG += [(f"09:{m:02d}", "partner-b", f"M{m:05d}") for m in range(30)]
LOG += [(f"10:{s // 60:02d}", "partner-b", f"M{s:05d}") for s in range(3600)]
seen = defaultdict(set)
for ts, cid, member in LOG:
seen[(cid, ts[:2])].add(member) # 接続先×時間帯ごとに、読んだ会員IDの種類数を数える
BASE, RATIO = "09", 5 # 前の時間帯の5倍を超えたら知らせる
for (cid, hour), members in sorted(seen.items()):
if hour == BASE:
continue
base = len(seen.get((cid, BASE), ())) or 1
flag = "要確認" if len(members) > base * RATIO else "通常"
print(f"[ログ] {cid} {hour}時台 会員{len(members)}件（前の時間帯{base}件） {flag}")接続元の範囲はPython標準のipaddressでアドレス数に直して比べ、集計はcollectionsのdefaultdictで行っています。Python 3.14.10（Windows）で実行した結果は次のとおりです。
$ python partner_api_audit.py
[設定] partner-a: OK
[設定] partner-b: 目的に不要な個人情報を返す: ['phone'] ／ 全サービスの会員を読める（サービス境界なし） ／ 接続元の制限が広すぎる: 0.0.0.0/0
[ログ] partner-a 10時台 会員45件（前の時間帯40件） 通常
[ログ] partner-b 10時台 会員3600件（前の時間帯30件） 要確認partner-bの設定には、電話番号の返却、全サービスへの読み取り、接続元の無制限という3つの指摘が出ました。実際の運用では、この設定の表をリポジトリで管理し、変更のたびにCIで点検を回します。目的の欄を埋めないと接続先を追加できない形にすると、「とりあえず全項目」を防げます。
1時間に読んだ会員数で急増を拾い、接続先からの連絡を待たない検知
後半の集計で見ているのは、リクエスト数ではなく読んだ会員IDの種類数です。正規の接続先は同じ会員を何度も照会しがちで、種類数はあまり増えません。会員IDを順に変えて読み出す呼び方は、種類数が急に跳ねます。例ではpartner-aが40件から45件で「通常」、partner-bが30件から3,600件で「要確認」になりました。
Yenyの事案では、最初の連絡は接続先から届いています。自社の側で接続先ごとの種類数を見ていれば、相手の連絡を待たずに気付ける余地がありました。閾値の5倍は例として置いた値です。実際には接続先ごとに曜日と時間帯の平常値を取り、月末の一括照会のような正規の山を除いてから決めます。認証系APIのレート制限や機能単位の認可、トークン失効までの実装はAPI不正アクセス対策の実装手順で詳しく扱いました。
実在のサービスに他人の会員IDを送って確かめる行為は、許可がなければ不正アクセスに当たりえます。点検は必ず自社の検証環境とログで行ってください。
判断：会員や決済の基盤を外部とAPIでつなぐ事業者が見直す条件
接続先APIの点検を自社で回せる条件と、外部の診断に頼む場面
接続先が数社で、返却項目と接続元の設定を1つの表で管理できているなら、上のような点検は社内で始められます。逆に次のどれかに当たるなら、設定の見直しを先に行うべきです。
- 接続先ごとに返す項目を決めた記録がなく、どの接続先に電話番号が渡っているか即答できない
- 1つのAPIキーで複数のサービスやブランドの会員を読める
- 接続元のIPアドレス制限がない、または広いまま運用している
- 接続先ごとの読み取り件数を日次で見ておらず、異常の連絡を外から受けて初めて気付く体制になっている
API連携の数が増えると、設計した人が異動し、設定の意図が分からないまま残ることが増えます。API連携の仕組みと設計の考え方はAPI連携の仕組みと導入判断で整理しました。会員や決済の情報を扱うAPIを外部に開いているなら、接続先ごとの権限と設定は、第三者の目でも確かめたい点です。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準にまとめています。自社APIの接続設定や認可を外部の目で点検したい場合は、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
Yenyの不正アクセスについて、ultra pay カードとPayBlendの利用者から出やすい質問をまとめました。
Yenyの不正アクセスで自分の情報は漏れましたか？
対象はultra pay カード、アスルクラロ沼津Pay、巫神こんPay、東芝ブレイブルーパス東京Payの会員で、退会者も含みます。Yenyは対象者に各アプリ内のお知らせ欄で案内するとしているため、まずアプリを開いて確かめてください。個別の照会ページや電話窓口はなく、問い合わせは公式発表に載ったお問い合わせフォームで受け付けています。
ultra payのパスワードは変更したほうがよいですか？
パスワードの漏えいは発表されておらず、Yenyは漏れた情報だけでは不正ログインできないとしています。ただし、ログインは電話番号とパスワードで行うため、同じパスワードを他のサービスで使っているなら、ultra payと他のサービスの両方を別のパスワードに変えると安全です。再設定はSMSの認証番号と生年月日で行えます。
カードの番号や残高は悪用されませんか？
公表時点で、クレジットカード番号等の決済情報の漏えいは確認されていません。Yenyは、漏れた情報だけでは決済に使えないと説明しています。身に覚えのない利用があった場合、ultra payとPayBlendには利用規約第18条に基づく不正利用の補償制度があり、申し込みには警察への事前相談の受理番号と本人確認書類が必要です。
Yenyから届いたSMSが本物か見分ける方法はありますか？
Yenyは、SMSや電話でパスワードやカード情報の入力を頼むことはないとしています。入力画面へのURLが付いたSMSや、認証番号を聞き出す電話は偽物と考えてください。本件の案内はアプリ内のお知らせ欄で届くため、SMSのリンクを開かず、アプリを自分で起動して確かめるのが確実です。
ultra payを退会すれば登録情報は消えますか？
退会だけでは登録情報は消えません。退会したうえで、問い合わせフォームからアカウントと個人情報の消去を別に申し込みます。登録した電話番号、生年月日、氏名、メールアドレス、解約日の申告が必要です。退会時に残高は放棄になるため、使い切ってから手続きしてください。
関連記事
- セイコーマートの不正アクセス（サイバー攻撃）：574,647人の対象確認とアプリのログイン再開・カード連携：会員アプリのAPIで起きた別の漏えい事案
- APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説：APIの主要リスクと実装対策の全体像
- 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順と相談窓口：企業として点検する範囲の全体像
- フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策を解説：漏えい後に増える偽SMSへの組織的な備え
