Cuenote FCの不正アクセス — 提供元のサポート用の認証情報から49システムに広がった経緯と、SaaSに顧客リストを預ける企業の3つの対策

Cuenote FCの不正アクセスとは

Cuenote FCの不正アクセスは、ユミルリンク株式会社が提供するメール配信サービス「Cuenote FC」で、プログラムの脆弱性を突かれて同社のサポート・品質管理担当者の認証情報が取得され、複数の利用企業のシステムからデータが出力された事案です。2026年10月16日の朝、同社の担当者が自身のアカウントの異常に気付き、同じ日のうちにライブラリの脆弱性による攻撃と特定しました。第一報の5システム・延べ約900万件という試算は、全システムの遡及調査を経て、第二報で広がりました。

第二報によると、Cuenote FCで不正アクセスが試行されたのは、単一の企業が利用するシステム78と、複数の企業が利用するシステム3でした。情報漏洩の痕跡が確認されたのは単一の企業が利用する49システムで、漏洩の恐れがある件数は延べ51,628,280件、複数の企業が利用するシステムでは0件です。漏洩件数を調査中のシステムが16あり、延べ件数は今後増える可能性があると同社は説明しています。最新の動きは、当社の事例速報「ユミルリンク株式会社（Cuenote FC）のサイバー攻撃被害」で更新しています。

検知から利用企業の公表までの経緯

提供元は検知から3日で第一報を出し、その後の遡及調査で対象の企業を広げました。利用企業の公表は、提供元からの連絡を受けた10月26日から集中しています。

漏洩した情報は、利用企業ごとに違う

Cuenote FCのアドレス帳には、配信先のメールアドレスと、差し込みや抽出に使う氏名、都道府県、生年月日などの付属情報が登録されます。どの付属情報を登録するかは利用企業ごとに異なるため、漏洩した項目も企業によって違いました。

提供元は、アドレス帳の項目を利用企業ごとに調査が完了し次第報告するとしています。ほかに、配信記録、申し込みページからの登録記録などのWebアクセス記録、利用企業の担当者の氏名や連絡先も、Cuenote FCに記録される情報として挙げられました。

なぜ1つの脆弱性から49システムに広がったのか

脆弱性から取得されたのが、提供元のサポート・品質管理担当者が各システムに入るための認証情報で、それを使った認証や不正プログラムによるデータの参照が続いたためです。第一報と第二報から、広がり方を3つに分けて整理します。

サポート用の認証情報が、ほかのシステムへの足がかりになった

第一報は、プログラムの脆弱性により担当者の認証情報が取得され、不正プログラムがデータベースからデータを出力し、さらにその認証情報でほかのシステムへの認証が試みられたことを確認したと説明しています。同社は被害の拡大を防ぐため、ほかのシステムから担当者の情報を削除し、10月18日にはサポート・QAアカウントの削除を始めました。利用企業が自社の環境に作っていないアカウントでも、提供元の保守のための入口が各システムに置かれていたことが、広がりの経路になったといえます。

不正プログラムとセッション情報で、ログを追うごとに範囲が広がった

第二報では、新たに45システムで、不正プログラムを介したほかのシステムのデータの参照と、ログイン時のセッション情報を使った不正ログインが確認されました。10月20日には、システム03を経由したシステム08への不正アクセスも見つかっています。手口が1つではなかったため、遡及調査が進むたびに、記録が見つかるシステムが増えていきました。

「影響なし」の連絡が、後から「対象」に変わった

サイボウズは10月20日に問い合わせた際、影響の範囲に入っていないとの回答を受けていましたが、10月26日に漏えいの可能性が高いとの連絡を受けました。JR3社とアニメイトも、当初は影響がないと報告を受けていたと公表しています。第一報の時点の回答はその時点の記録にもとづくものだったため、利用企業も、後から状況が変わる前提で動く必要があったわけです。

メール配信サービスやSaaSを使う中小企業が狙われる理由

メール配信サービスは多くの企業の顧客リストを1つの事業者がまとめて預かり、提供元の保守のための入口が各社の環境に置かれることもあるため、1か所の弱点が多くの利用企業に届きます。IPAの「中小企業のためのクラウドサービス安全利用の手引き」も、1台のインシデントが多数に影響することを、クラウドサービス固有のリスクに挙げています。当社代表の青山は、総合解説「サプライチェーン攻撃の起点は中小企業にある」で、メールの配信基盤そのものが破られて利用者全員が被害を受ける型を、侵入のパターンの1つに挙げています。同じ10月には、宛先リストが持ち出されたブラストメールの事例も起きました。

委託先のSaaSで情報漏えいが起きたら？利用企業が取るべき3つの対策

SaaSを使う企業が優先したいのは、①提供元の第一報を見たら、「影響なし」の回答を確定とせず、自社の環境ごとに証跡で確かめ直す、②どの配信に誰のどの項目を載せたかを記録し、対象者と項目を絞って段階的に公表する、③提供元のサポート担当が自社の環境に入れる経路と、管理画面・APIの接続元の制限を契約時と年1回確かめる、の3つです。①は対象の見落としを、②はお客様への説明の遅れを、③は保守の入口からの広がりを防ぐための備えといえるでしょう。

対策1：提供元の第一報を見たら、「影響なし」の回答を確定とせず、自社の環境ごとに証跡で確かめ直す

提供元の事故を知った日に最初にすべきなのは、自社の環境に影響があるかを問い合わせ、その回答を確定ではなく途中経過として記録することです。Cuenote FCの事例では、第一報の時点で影響がないと伝えられた複数の利用企業が、遡及調査の結果を受けて10月26日以降に対象と知らされました。ユミルリンクは第二報で、個別の連絡がない利用企業は現時点で利用環境の漏洩が確認されていないと説明しており、「現時点」の判断は調査とともに更新されていきます。

アスマークは、出力されたデータの項目・件数・証跡の提供を提供元に求めたと公表しています。問い合わせでは次の表の項目を聞き、回答を日時と担当者名とともに残してください。

判断の目安は、「提供元の続報が出た日のうちに、自社の状況を確かめ直して記録を更新している」状態です。落とし穴は、電話の口頭の回答だけで社内の対応を閉じ、続報を誰も追わなくなることでしょう。SaaSの管理担当者が窓口になれば、問い合わせと記録は1時間ほどで済み、提供元の続報が出るたびに同じ手順を繰り返します。

対策2：どの配信に誰のどの項目を載せたかを記録し、対象者と項目を絞って段階的に公表する

2つ目は、SaaSに載せた名簿の出どころと項目、配信ごとの宛先の条件を記録し、事故の日に対象者と項目を絞り込んで公表できるようにすることです。JR3社は、Cuenote FCで販売促進のメールや発車時刻の変更のお知らせなどを配信した会員を対象とし、漏えいした項目と漏えいの可能性がない項目を分けて示しました。アニメイトも、氏名や住所、電話番号が漏えいしていないことを確認したと明記しています。

自社の名簿と提供元の調査結果を突き合わせられれば、お客様は自分が対象かどうかと何が漏れたかを早く知ることができます。次の5つを配信の運用に組み込んでください。

1. SaaSのアドレス帳ごとに、元にした名簿（会員、メールマガジンの登録者、取引先、パートナーなど）と登録した項目を記録する
2. 配信ごとに、送った日付、宛先の条件、件数を残す
3. 提供元から項目と件数が届いたら、自社の記録と突き合わせ、漏えいした項目と含まれない項目を分ける
4. 件数が確定する前は、対象となりうる範囲と不審なメールへの注意を第一報として出し、確定後に第二報と個別の連絡を出す
5. 問い合わせ窓口が、メールアドレスや会員番号から対象かどうかを答えられる手順を用意する

判断の目安は、「提供元から対象者のリストが届いた日に、第二報と個別の連絡の文面を出せる」状態です。陥りやすいのは、配信のたびに名簿をまるごと上書きしていて、事故の時点でどの名簿が載っていたのかを誰も説明できなくなることでしょう。Cuenote FCには利用企業の担当者の情報も記録されるため、自社の社員にも、提供元や取引先を名乗る不審なメールへの注意を伝えておくと安心です。記録の様式はメールマガジンの担当者が半日で作れ、配信のたびに1行ずつ書き足します。

対策3：提供元のサポート担当が自社の環境に入れる経路と、管理画面・APIの接続元の制限を、契約時と年1回確かめる

3つ目は、提供元の保守やサポートのための入口が自社の環境にどう置かれているかを把握し、接続元の制限など自社で選べる設定を有効にしておくことです。今回の事例で足がかりになったのは、提供元のサポート・品質管理担当者の認証情報でした。ユミルリンクは再発防止策として、担当者の認証情報の削除に加え、操作画面とAPIにIP制限がされていなかった環境へのIP制限を行っています。

IPAのクラウドサービス安全利用チェックシートも、利用者の範囲の管理、厳格な認証、付帯するセキュリティ対策の公開状況の確認を、利用者の点検項目に挙げています。契約時と年に1回、次の項目を提供元に確かめて記録します。

判断の目安は、「提供元のサポート担当が入る経路を説明でき、管理画面とAPIは自社の拠点からしか使えない」状態です。落とし穴は、在宅勤務や外部の制作会社のために接続元の例外を広く開け、制限の意味が薄れることにあります。確認はSaaSの管理担当者が提供元とのやり取りを含めて半日ほどで終えられ、契約の更新時と年に1回、同じ表で見直します。

現状把握・修復・継続監視の3段階で見る、ガーディアンの支援

配信サービスの事故への備えは、名簿を集める自社のページの状態を知る現状把握、事故の日にお知らせと会社の名前を守る修復、改修が続くページを見続ける継続監視の3段階で考えると分かりやすい領域です。当社のサービスを段階ごとに置いたのが、次の表になります。

名簿を集める自社のページから、SCAN DOG 正規版で見る

配信サービスに載る名簿の多くは、自社のメールマガジン登録フォームや会員のマイページで集めたものです。SCAN DOG 正規版は、こうした公開Webアプリケーションを決めた頻度で診断し、指摘ごとに対応の状況を残せるので、フォームを作り直した後の確認にもそのまま使えます。関連会社や販売代理店のサイトは、SCAN DOG ライト版でURLをまとめてお預かりし、外から見える穴を一度に洗い出すのが近道でしょう。

事故の日の発信は、SCSC Dog の公式サイト運用で支える

提供元の事故が公表された日、お客様が対象かどうかを確かめに訪れる先は自社の公式サイトです。SCSC Dog は、公式サイトの更新から24時間365日の有人監視、障害時の復旧までを当社が受け持ち、第一報と第二報を続けて載せ替えられる状態を保ちます。当社がこの仕組みで運用するサイトは、2026年10月時点で76,325を数えます。

SCS評価制度で問われる、クラウドサービスとのつながりの把握と認証の強さ

SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）は、取引先どうしで対策の水準を確かめやすくするための任意の制度で、★3・★4の申請受付は2026年度末に始まる予定です。取引を規制するものではないものの、顧客の情報をクラウドサービスに預ける企業ほど、使っているサービスとその守り方を尋ねられる場面は増えていくとみられます。

この事例に関わるのは、★3の要求事項「2-1-1 取引先とのビジネス又はシステム上の関係」と「4-1-3 認証の強度・実装方法の決定」です。前者は、クラウドサービス提供者を含む取引先が管理・提供し、自社の資産が接続しているシステムを把握する仕組みと、年1回以上の点検を求めています。後者は、重要な機密情報を取り扱うクラウドサービスへのアクセスに多要素認証を使うことを求めるものです（IPA「★3・★4 要求事項・評価基準」）。対策3で提供元とのつながりと認証を確かめる作業は、この2つの準備も兼ねます。制度の要点はSCS評価制度への対応にまとめています。

まとめ

Cuenote FCの事例では、ライブラリの脆弱性から提供元のサポート・品質管理担当者の認証情報が取得され、不正プログラムやセッション情報を使った不正ログインを通じて、単一の企業が利用する49システムに情報漏洩の痕跡が残りました。漏洩の恐れがある件数は延べ51,628,280件で、利用企業は自社の名簿に合わせて対象と項目を公表しています。

メール配信や顧客管理のSaaSに顧客リストを預けている企業が、今日から進めたいのは次の3つです。

• 提供元の事故を知ったら、自社の環境への影響を問い合わせ、回答を日時と担当者名で記録し、続報のたびに確かめ直す
• SaaSのアドレス帳ごとに名簿の出どころと項目を、配信ごとに宛先の条件と件数を記録する
• 提供元のサポート担当が入る経路、管理画面とAPIの接続元の制限、二段階認証を、契約時と年1回確かめる

お知らせを載せる公式サイトの守りの基本がどこまでできているかは、77's Check!! で無料で確かめられます。

よくある質問

あわせて読みたい

• 
  総合解説

  サプライチェーン攻撃の起点は中小企業にある
• 
  事例一覧

  2026年 日系企業のサイバー被害事例一覧
• 
  SCS評価制度

  SCS評価制度への対応