---
title: "ユミルリンク不正アクセスで延べ約900万件：Cuenote FC利用企業と受信者の確認点"
url: "https://www.issoh.co.jp/tech/details/18689/"
published: 2026-10-21
updated: 2026-10-21
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# ユミルリンク不正アクセスで延べ約900万件：Cuenote FC利用企業と受信者の確認点

ユミルリンクは2026年10月19日、メール配信サービス「Cuenote FC」の一部サーバシステムが外部から不正アクセスを受け、メールアドレスを含む情報が延べ約900万件出力されたと試算を公表しました。影響のあるシステムは「Cuenote FC 専用ASPプラン」のうち合計5システムです。本記事では、利用企業からメールを受け取っている人と、Cuenote FCを使っている企業の担当者が知りたい「自分は対象か」「届いたメールは本物か」「どこに問い合わせるか」に公式発表の文言で先に答えます。後半では、SaaSを運営する側に向けて、サポート用アカウントの認証情報が別システムへの足場になった構造を読み解き、横展開を検知するPythonのコードと、委託元が負う報告の範囲を示します。

## まとめ：ユミルリンク不正アクセスで公表された事実と利用企業・受信者が今やること

確定しているのは次の事実です。10月16日（金）未明にユミルリンクの担当者が不正アクセスを確認しました。攻撃者はプログラムの脆弱性を使って、同社のサポート・品質管理担当者の認証情報を取得し、不正プログラムを設置してデータベースからデータを出力していました。さらにその認証情報で、他のシステムへの認証も試みています。

メールを受け取っている人が今日やることは、普段メールを受け取っている企業の公表を確かめ、心当たりのない案内メールのリンクを開かないことです。Cuenote FCの利用企業は、自社の環境が5システムに入るかをユミルリンクに確かめ、入る場合は個人情報保護委員会への速報の準備に入ります。

| 項目        | 公表されている内容（10月21日時点）       |
| --------- | ------------------------- |
| 確認日       | 2026年10月16日（金）未明          |
| 影響のあるシステム | Cuenote FC 専用ASPプラン中5システム |
| 出力された件数   | メールアドレスを含む情報 延べ約900万件（試算） |
| 原因        | プログラムの脆弱性（種類は未公表）         |
| 当局への対応    | 捜査機関へ届出済み                 |
| 専用窓口      | 03-6820-0088（平日9時〜20時）    |
| 続報        | 第二報は未公表（外部専門家と詳細調査中）      |

## 自分が対象か確かめる手順｜メールの受信者と利用企業で異なる問い合わせ先

### 受信者はユミルリンクではなく普段メールを受け取る企業の公表を先に見る理由

Cuenote FCは、企業がメールマガジンや通知メールを送るために契約する配信システムです。受信者から見ると、メールの差出人は契約している企業で、ユミルリンクの名前はほとんど出てきません。出力されたデータは、各利用企業が配信のために預けた宛先リストと考えられますが、どの企業のデータかは公表されていません。

このため、受信者が自分が対象かを知る手がかりは、メールを受け取っている企業の公表です。ユミルリンクの[Cuenote公式の第一報](https://www.cuenote.jp/information/news/unauthorizedaccess.html)にある専用窓口は利用企業と受信者の双方に開かれていますが、個別の宛先が入っているかを答えられるのは、宛先リストを持つ利用企業です。配信システムの仕組みは[メール配信システムとは](https://www.issoh.co.jp/column/details/15316/)で解説しています。

### 利用企業はCuenote FC専用ASPプランの5システムに入るかをまず確認

影響範囲は「Cuenote FC 専用ASPプランのうち、合計5システム」です。この記載は10月19日19時05分に更新されたWeb版で追記されたもので、同じ日の[東証の適時開示PDF](https://www2.jpx.co.jp/disc/43720/140120261019553124.pdf)には製品名がありません。共用型のプランや、メールリレーサーバー「Cuenote SR-S」などの別製品を使っている企業は、記載の上では対象に含まれていません。

利用企業が確かめることは2つです。自社の契約が専用ASPプランか、そのうえで自社の環境が5システムに入るかです。後者は外から判断できないため、ユミルリンクの専用窓口（電話03-6820-0088、メールsupport@cuenote.ne.jp）に問い合わせます。

### 山陽新聞社とNTTPCの公表に見る「漏えい未確認」と「否定できない」の差

10月21日までに、利用企業2社の公表を確認できました。山陽新聞社は10月18日14時15分頃からメール配信を止め、[10月21日の第4報](https://c.sanyonews.jp/release/2026/10/20261021121018.html)で、ユミルリンクから「当社が利用している環境では情報漏えいは確認されていない」との連絡を受けたとして配信を再開しました。

[NTTPCは10月20日](https://www.nttpc.co.jp/press/info/2026/10/202610201600.html)、10月19日にユミルリンクから報告を受けたと公表しました。利用者の情報への影響は確認できていないものの、可能性を完全には否定できないとして、連絡先メールアドレス等の漏えいの可能性に注意を呼びかけています。同じ「影響未確認」でも、自社環境が5システムの外と分かった企業と、まだ確認中の企業では意味が違います。受信者は、利用企業の公表がどちらの段階かを見てください。

## 届いたメールは本物か｜cuenote.jpから届くカード会社名義の迷惑メールの見分け方

### 10月20日の注意喚起にある件名と送信元アドレスの組み合わせ

ユミルリンクは[10月20日の注意喚起](https://www.ymir.co.jp/info/ymir-information20261020.html)で、同社のドメインを使い、第三者を騙った迷惑メールが複数確認されていると公表しました。挙げられている例は次のとおりです。

| 項目      | 確認されている例              |
| ------- | --------------------- |
| 件名      | ご利用確認のお願い／利用内容確認のご依頼  |
| 送信元アドレス | セゾンカードinfo@cuenote.jp |
| 送信元アドレス | SAISONinfo@cuenote.jp |

同社は、このような内容のメールを自社のドメインから送信指示することは一切ないとしています。返信、URLのクリック、QRコードの操作をせずに削除し、やり取りを始めてしまった場合は警察署へ相談するよう求めています。この迷惑メールと今回の不正アクセスとの関係は、注意喚起には書かれていません。

### 受信時に表示名ではなく@の後ろのドメインを普段の送信元と照らす手順

メールソフトに大きく表示される「セゾンカード」は表示名で、送信者が自由に書ける文字列です。見るべきは山かっこの中のアドレスで、@の後ろがcuenote.jpです。カード会社の利用確認は、そのカード会社のドメインから届きます。配信システムの事業者のドメインからカード会社名義のメールが来た時点で、正規の連絡ではないと判断できます。

スマートフォンでは表示名しか見えないことが多いため、差出人をタップしてアドレスを開いてください。送信ドメインの認証結果をPythonで確かめる手順は[SpeeCAN RAIDEN不正アクセス](https://www.issoh.co.jp/tech/details/18363/)で、DMARCの仕組みは[DMARCとは](https://www.issoh.co.jp/column/details/3287/)で扱いました。最新のフィッシング報告は[フィッシング対策協議会](https://www.antiphishing.jp/)が公開しています。

## 第一報で読む侵入の4段階｜脆弱性から担当者の認証情報、DB出力、横展開まで

### 4つの事実と3つの対応策が1対1で並んでいる第一報の構成と読み方

第一報は、アクセス記録から確認した事実をⅠ〜Ⅳの番号で並べ、対応策にも同じ番号を振っています。番号を突き合わせると、同社が何を塞いだかが読めます。

| 番号 | 確認された事実               | 講じた対応            |
| -- | --------------------- | ---------------- |
| Ⅰ  | プログラムの脆弱性             | 脆弱性のあるプログラムの修正   |
| Ⅱ  | サポート・品質管理担当者の認証情報を取得  | 同担当者の認証情報を削除     |
| Ⅲ  | 不正プログラムを設置しDBからデータを出力 | 不正プログラムの検知体制を整備  |
| Ⅳ  | 同じ認証情報で他のシステムへ認証を試行   | 他システムから同担当者情報を削除 |

ⅡとⅣの対応が「認証情報の削除」で共通している点に注目してください。サポート・品質管理担当者のアカウントが複数のシステムに登録されていたため、1か所で取られた認証情報が他のシステムの鍵にもなりました。不正プログラムの設置と検知の手口は[Webシェルとは](https://www.issoh.co.jp/tech/details/18314/)で解説しています。

### 延べ約900万件は人数でも利用企業数でもない試算値である点に注意

約900万件は「延べ」の「試算」です。同じメールアドレスが複数の利用企業の宛先リストに入っていれば、その分だけ重ねて数えられます。実際の人数はこれより少ない可能性がありますが、何人かは公表されていません。また「メールアドレスを含む情報」とあるだけで、氏名や会員番号など他の項目が含まれるかは、利用企業が配信システムに何を登録していたかで変わります。

### 正規アカウント悪用をMITRE ATT&CKのValid Accountsで読む

取得した正規の認証情報でログインする攻撃は、攻撃手法の分類であるMITRE ATT&CKで[T1078 Valid Accounts](https://attack.mitre.org/techniques/T1078/)に当たります。正規のアカウントなので、ログインの成功そのものは異常に見えません。検知の手がかりは、そのアカウントが普段入らないシステムに入った、普段使わない接続元から来た、短時間に複数のシステムを試した、という振る舞いの差です。この分類への当てはめは当社の整理で、ユミルリンクの発表にはありません。

## サポート用アカウントの横展開を検知するPython実装｜許可外システムと渡り歩き

### 横展開の検知に向けてログに残す5項目とアカウントごとの許可表を先に作る設計

横展開の検知には、ログイン記録に時刻、システム名、アカウント、成否、接続元IPの5項目がそろっている必要があります。そのうえで、サポート用アカウントごとに「入ってよいシステム」を許可表として持ちます。次のコードは、許可表と管理用ネットワークの範囲をもとに、3種類の兆候を拾う例です。support\_login\_audit.pyとして保存します。

```
import csv, io
from collections import defaultdict
from datetime import datetime, timedelta

# サポート・品質管理用アカウントのログイン記録から、管理用ネットワーク外からの認証、
# 許可外システムへの認証、短時間で複数システムを渡り歩く試行を拾い出す
ALLOWED = {  # アカウントごとに入ってよいシステム
    "support-qa01": {"mail-03"},
    "support-qa02": {"mail-01", "mail-02"},
}
ADMIN_NET = ("10.20.",)          # 社内の管理用ネットワーク
WINDOW = timedelta(minutes=30)   # 渡り歩きを数える時間幅
SPREAD = 3                       # 時間幅内に何システム以上なら警告するか

LOG = """time,system,account,result,src_ip
2026-10-01T23:58:10,mail-03,support-qa01,success,203.0.113.45
2026-10-02T00:04:31,mail-01,support-qa01,failure,203.0.113.45
2026-10-02T00:05:02,mail-02,support-qa01,failure,203.0.113.45
2026-10-02T00:06:40,mail-04,support-qa01,success,203.0.113.45
2026-10-02T09:12:00,mail-01,support-qa02,success,10.20.1.8
"""

def audit(rows):
    alerts, recent = [], defaultdict(list)
    for r in rows:
        t, acct, host = datetime.fromisoformat(r["time"]), r["account"], r["system"]
        head = f"{r['time']} {acct}"
        if not r["src_ip"].startswith(ADMIN_NET):
            alerts.append(f"{head}: 管理用ネットワーク外({r['src_ip']})から {host} へ {r['result']}")
        if host not in ALLOWED.get(acct, set()):
            alerts.append(f"{head}: 許可外の {host} へ {r['result']}")
        recent[acct] = [(x, s) for x, s in recent[acct] if t - x <= WINDOW] + [(t, host)]
        hosts = sorted({s for _, s in recent[acct]})
        if len(hosts) >= SPREAD:
            alerts.append(f"{head}: {WINDOW.seconds // 60}分以内に{len(hosts)}システムへ認証 {hosts}")
    return alerts

for a in audit(csv.DictReader(io.StringIO(LOG))):
    print(a)
```

2026年10月21日に、Python 3.14.7で実行した結果です。ログとシステム名は架空で、ユミルリンクの実際の記録ではありません。

```
$ python support_login_audit.py
2026-10-01T23:58:10 support-qa01: 管理用ネットワーク外(203.0.113.45)から mail-03 へ success
2026-10-02T00:04:31 support-qa01: 管理用ネットワーク外(203.0.113.45)から mail-01 へ failure
2026-10-02T00:04:31 support-qa01: 許可外の mail-01 へ failure
2026-10-02T00:05:02 support-qa01: 管理用ネットワーク外(203.0.113.45)から mail-02 へ failure
2026-10-02T00:05:02 support-qa01: 許可外の mail-02 へ failure
2026-10-02T00:05:02 support-qa01: 30分以内に3システムへ認証 ['mail-01', 'mail-02', 'mail-03']
2026-10-02T00:06:40 support-qa01: 管理用ネットワーク外(203.0.113.45)から mail-04 へ success
2026-10-02T00:06:40 support-qa01: 許可外の mail-04 へ success
2026-10-02T00:06:40 support-qa01: 30分以内に4システムへ認証 ['mail-01', 'mail-02', 'mail-03', 'mail-04']
```

許可された mail-03 への深夜のログインは接続元だけで警告され、その6分後から許可外の3システムを順に試した時点で、渡り歩きの警告が出ます。社内ネットワークから許可内のシステムへ入った support-qa02 は警告されません。

### このスクリプトで拾えない攻撃と本番で組み合わせる3つの仕組み

このコードは検知の考え方を示す最小の例です。攻撃者が管理用ネットワーク内の踏み台から、許可されたシステムだけを使った場合は何も出ません。本番では、検知より先に次の3つで「取られても他で使えない」状態にしておくのが先です。

- サポート用アカウントをシステムごとに別にし、同じ認証情報を複数のシステムに登録しない
- 常設の権限を持たせず、作業のたびに期限付きで発行して作業後に失効させる
- ログインに多要素認証と接続元の制限を掛け、パスワードだけでは入れなくする

1つ目だけでも、第一報のⅣ（他システムへの認証の試行）は成立しなくなります。ロールで権限を分ける考え方は[RBACとは](https://www.issoh.co.jp/tech/details/6488/)、トークンの失効は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱いました。利用企業ごとに環境を切り分ける段階的な方法は[スカラコミュニケーションズの不正アクセス](https://www.issoh.co.jp/tech/details/18209/)で解説しています。

## 委託元の報告責任｜利用企業が個人情報保護委員会と本人へ通知する範囲と期限

### 委託先の事故でも報告の主体は利用企業になる個人情報保護法26条の構造

個人情報保護法26条1項は、漏えい等が起きた個人データを取り扱う事業者に、個人情報保護委員会への報告を義務づけています。配信を委託した利用企業は、宛先リストを預けた側として報告の主体になります。委託先のユミルリンクは、利用企業に事態を通知すれば、ただし書により自らの報告義務を免れる仕組みです。不正アクセスによる漏えいのおそれは、件数が1人でも報告対象です。

期限は、速報がおおむね3〜5日以内、確報は不正の目的によるものなので60日以内です。様式と手順は[個人情報保護委員会の「漏えい等の対応とお役立ち資料」](https://www.ppc.go.jp/personalinfo/legal/leakAction/)、判断の流れは[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で整理しています。

### 利用企業が速報の期限内にユミルリンクから取り寄せる4つの情報

自社の環境が5システムに入ると分かった利用企業は、速報に書く材料を委託先から集める必要があります。次の順で問い合わせると、報告と本人への通知の両方に使えます。

1. 自社の環境から出力されたデータの項目（メールアドレスのほか、氏名・会員IDなどの属性列があるか）
2. 出力された件数と、宛先リストのどの時点の版か
3. 出力が行われた期間と、アクセス記録の保全状況
4. 再発防止策の実施日と、自社環境で同じ担当者アカウントが削除されたか

件数が延べの試算のままだと、本人への通知の範囲が決まりません。速報は分かっている範囲で出し、確報までに項目と件数を確定させるのが現実的な進め方です。

## 配信SaaSの委託先管理を今月見直す企業と次の契約更新でよい企業

### 宛先リストに氏名や会員ID、購買履歴まで載せて配信している企業

差し込み配信やセグメント配信のために、メールアドレス以外の属性まで配信システムに登録している企業は、今月中に2点を確かめてください。1点目は、配信に使っていない属性列が残っていないか。2点目は、委託先の内部担当者がどの範囲のデータを見られるかを契約と実態の両方で把握しているかです。今回の事案では、まさにその内部担当者の認証情報が使われました。

委託先のSaaSを含めて、外から到達できる画面とAPI、内部アカウントの権限まで第三者の目で洗い出したいときは、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で点検できます。委託先を起点とする攻撃の全体像は[サプライチェーン攻撃とは](https://www.issoh.co.jp/column/details/13184/)にまとめました。

### メールアドレスだけを渡し配信ごとに宛先リストを入れ替えている企業

配信のたびにメールアドレスだけを登録し、配信後に削除している企業は、漏えいしたときの影響がメールアドレスに限られます。この場合、委託先の見直しは次の契約更新時で足ります。先に済ませるべきは、自社を名乗る偽のメールへの備えで、送信ドメインのDMARCをp=rejectまで上げておくことです。

## よくある質問

ユミルリンクの不正アクセスについて、メールの受信者とCuenote FCの利用企業から出やすい質問をまとめました。

### ユミルリンクから直接メールが届いたことがなくても対象になりますか？

対象になる可能性はあります。Cuenote FCは企業がメールを送るための配信システムで、受信者に届くメールの差出人は契約企業の名前です。出力されたのは利用企業が預けた宛先リストと考えられ、ユミルリンクと直接の取引がなくても含まれる可能性があります。普段メールを受け取っている企業の公表を確かめてください。

### 延べ約900万件は900万人分の情報が流出したということですか？

同じではありません。ユミルリンクは「延べ」の「試算」としており、同じメールアドレスが複数の利用企業のリストに入っていれば重ねて数えられます。人数と、メールアドレス以外にどの項目が含まれるかは調査中で、10月21日時点では公表されていません。

### セゾンカードを名乗るinfo@cuenote.jpからのメールは本物ですか？

本物ではありません。ユミルリンクは10月20日の注意喚起で、件名「ご利用確認のお願い」「利用内容確認のご依頼」、送信元「セゾンカード <info@cuenote.jp>」などのメールを自社のドメインから送信指示することは一切ないとしています。返信やURLのクリックをせずに削除してください。

### メールアドレスやパスワードは変えたほうがよいですか？

メールアドレスを変える必要は、公表された事実からは読み取れません。パスワードが出力されたという記載もありません。漏えいしたメールアドレスを狙った偽の案内メールが増える可能性はあるため、メール内のリンクからログインせず、ブックマークや公式アプリから開く習慣に切り替えておくのが安全です。

### Cuenote FCの利用企業は個人情報保護委員会へ報告が必要ですか？

自社の環境が影響のある5システムに入り、個人データが漏えいしたおそれがある場合は、利用企業が報告の主体です。不正アクセスによるものは件数にかかわらず報告対象で、速報はおおむね3〜5日以内に出します。自社の環境が対象外だとユミルリンクから回答を得た場合は、その回答の日付と内容を記録に残してください。

## 関連記事

- [SpeeCAN RAIDEN不正アクセス：防災メール登録者の対象確認と不審メールの見分け方](https://www.issoh.co.jp/tech/details/18363/)：同じ10月に起きたメール配信システムの事案と送信元の判定
- [スカラコミュニケーションズの不正アクセスと最大71万件：管理サイトから他社へ広げない設計](https://www.issoh.co.jp/tech/details/18209/)：SaaS事業者の事故が複数の利用企業へ広がった構造
- [Webシェルとは？Tomcatへの設置手口と検知・除去の手順をコマンド例で解説](https://www.issoh.co.jp/tech/details/18314/)：サーバに設置される不正プログラムの検知と除去
- [フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](https://www.issoh.co.jp/tech/details/13548/)：カード会社を装う確認メールの手口と対策
- [DMARCとは？仕組み・SPFやDKIMとの違い・レコードの書き方を解説【2026年版】](https://www.issoh.co.jp/column/details/3287/)：自社を名乗る偽メールを受信側で弾かせる設定

---

出典: [ユミルリンク不正アクセスで延べ約900万件：Cuenote FC利用企業と受信者の確認点](<https://www.issoh.co.jp/tech/details/18689/>)（株式会社一創）