集英社の不正アクセスでブロガー2,835名が流出｜CMS設定不備とAPI認証情報の守り方

集英社は2026年9月28日、ファッション誌メディアで活動するブロガーの情報管理・連絡用システム「HAPPY PLUS COMMUNITY（ハピコミュ）」が外部から不正アクセスを受け、登録ブロガー2,835名の個人情報などが漏洩したと公表しました。原因は、利用しているCMSの設定不備に起因するAPI認証情報を狙った攻撃で、特権ユーザーアカウントを不正に作られ、APIリクエストを繰り返されたと説明されています。本記事で整理するのは、公式発表の時刻と件数に基づく経緯、流出したデータの性質による分類、ブロガーと取引先が警戒すべき連絡の型です。後半では、CMSや管理APIを持つ自社サービスが同じ構図を避けるための認可と認証情報の管理、監査ログから異常を拾うコードを示します。

まとめ：集英社の不正アクセスで公表された事実と関係者・開発者が今やること

確定しているのは、2026年9月9日の深夜と日中の2回、合わせて約4時間にわたり不正アクセスがあったこと、その間にシステムのテンプレートを使ったメールが100名宛てに計3通送られたこと、受信者の通報で同日14時53分に発覚したことです。集英社は不正アカウントの削除と設定変更、脆弱性の解消、不正検知設定の強化を済ませ、9月25日に対象ブロガーへメールで通知しました。一方、CMSの製品名、設定不備の中身、狙われたAPI認証情報の種類は公表されていません。

関係者の打ち手は、集英社や各誌を名乗る連絡を通常の経路で確かめることに尽きます。今回は本物のシステムから本物のテンプレートでメールが送られた点が特徴で、見た目だけでは見分けられません。開発側が持ち帰るべき教訓は、API認証情報が漏れた時点で特権アカウントを作れてしまう設計と設定にあります。

公式発表を時系列で確認する｜9月9日の2回の侵入から通知と公表まで

深夜と日中の2回の侵入と、通報で発覚した14時53分までの流れ

集英社の公式発表（2026年9月28日）によると、不正アクセスは9月9日の0時45分から1時25分までと、13時42分から16時46分までの2回です。この間にシステム内のデータが閲覧・取得された可能性があり、漏洩が発生したとされています。

発覚のきっかけは、システムから届いた不審なメールを受け取ったユーザーの通報で、時刻は14時53分です。2回目の侵入はまだ続いていた時間帯で、通報の後も16時46分までアクセスが続いています。社内の検知ではなく外部からの通報で見つかった点は、後半で扱う監査ログと検知設定の話に直結します。

不正アカウントの削除から9月25日の本人通知と9月28日の公表まで

集英社は漏洩を確認した後、開発ベンダーに調査を依頼し、不正に作られたアカウントの削除と設定内容の変更を行いました。漏洩した内容を確認したうえで、9月25日に対象のブロガーへ、登録メールアドレス宛てに概要と漏洩内容の詳細、対応窓口を通知しています。公表はその3日後の9月28日です。

個人情報保護委員会には速報を出しており、確報は取りまとめ中とされています。外部会社によるフォレンジック調査も進めているため、侵入の詳細や追加の被害の有無は今後の続報で変わる可能性があります。

CMSの設定不備という公表原因から読み取れる構図と推測できない範囲

公表された原因は「利用しているCMSの設定の不備に起因するAPI認証情報を狙った攻撃」で、その結果、特権ユーザーアカウントが不正に作成され、APIリクエストが繰り返し実行されたとされています。CMSの製品名、どの設定が不備だったのか、API認証情報がAPIキーなのかトークンなのかは書かれていません。そのため本記事では特定の製品や脆弱性に結び付けた推測はしません。

読み取れるのは構図です。外部の第三者がAPI認証情報を手に入れるか悪用できる状態にあり、その認証情報には特権アカウントを作れるだけの権限が付いていました。さらに作られた特権アカウントでデータを一括で引き出せ、実在のテンプレートでメールも送れました。どの段階で止まっていても、被害はここまで広がっていません。

流出したデータを種類別に仕分ける｜ブロガー情報・案件・送信メール・取引先

登録ブロガー2,835件に含まれる生活に踏み込んだ項目の重さ

ブロガーに関する情報は2,835件で、氏名、メールアドレス、住所、電話番号、生年月日、性別、職業、プロフィール画像と情報、SNSアカウント、フォロワー数に加え、結婚状況、子の有無、身長、肌タイプなど個人別画面に登録された情報が含まれます。本人か編集部が入力したもので、対象媒体はnon-no、MORE、MAQUIA、LEE、SPUR、BAILA、Marisol、éclatです。媒体や個人により項目は異なります。

住所と電話番号に加えて、結婚状況や子の有無までそろっている点が重さを決めます。SNSアカウントとフォロワー数があるため、発信している人物と住所が結び付きます。パスワードと違って変更できない情報ばかりで、流出後の対処は警戒しか残りません。

送信メール11,237件とテンプレート悪用が詐欺の材料になる理由

システムから送ったメールは11,237件すべてが対象です。案件の依頼や連絡の文面がそのまま残っているため、件名の付け方、署名、言い回しといった、本物らしく見せるための材料がそろいます。案件情報630件にはブログや撮影、イベント参加の依頼記録が含まれ、誰にどんな依頼が出ていたかも分かります。

侵入中に、実際のテンプレートを使ったメールが100名宛てに計3通送られた事実もあります。内容は公表されていませんが、本物のシステムから本物の書式で届くメールは、受け手が見た目で偽物と見抜けません。流出した文面を下敷きにした連絡が今後届く前提で動くべきです。

取引先一覧10,780件のうち連絡先が含まれる件数と担当者名の扱い

取引先一覧は10,780件で、会社名は全件、メールアドレスは26件、電話番号は113件が含まれます。担当者の氏名は登録されていなかったとされています。件数は大きいものの、連絡先まで含むのは一部です。

性質の異なるデータなので、件数を足し合わせて被害人数とはできません。人として特定できる個人情報は、ブロガー2,835名分と取引先の連絡先の一部です。

ブロガーと取引先が警戒する連絡の型｜各誌を名乗る依頼と認証の要求

案件の依頼や撮影の連絡を装うメールを通常の連絡経路で見分ける確認手順

警戒すべきは、案件の依頼、撮影や取材の日程調整、謝礼の振込に関する連絡です。流出した送信メールと案件情報があれば、過去のやりとりに沿った自然な文面を作れます。見分けるには文面ではなく経路で確かめます。いつも連絡を取っている編集部の担当者に、既に知っている連絡先から問い合わせ、依頼が実在するかを確認してください。

メール本文にあるリンクからログイン画面へ進む、添付ファイルを開く、振込先や連絡先の変更に応じるといった操作は、確認が取れるまで止めます。住所や家族構成を知っている前提で話しかけてくる連絡も、同じ扱いです。

ログインやファイル共有を求める連絡にアカウントの防御で備える

SNSアカウントが流出しているため、そのSNSを狙ったログイン画面の偽装やパスワード再設定の誘導も考えられます。SNSと、登録メールアドレスのアカウントには二要素認証を設定しておくと、パスワードを入力させられても単独では入れなくなります。方式の違いを確認する際の参照先は、二段階認証とはの記事です。

出版社の事案では、講談社でもフィッシングを起点に社員のアカウントが侵害されています。講談社の個人情報流出3,812件は攻撃の入口が異なる事例として、今回と比べる材料になります。

取引先企業が請求先や振込先の変更連絡を通常の経路で照合する理由

取引先側は、集英社や各誌を名乗る請求先・振込先の変更、契約書類の再送、ファイル共有サービスへの招待に注意します。会社名が全件流出しているため、宛先を絞った連絡が届く可能性があります。社内では、口座変更は電話など別経路での確認を必須にする、という既存のルールを改めて周知するのが手堅い対応です。

CMSと管理APIで起きた構図を分解する｜認証情報の漏えいから特権の作成まで

CMSのAPI認証情報が狙われる経路と設定不備が入口になるパターン

API認証情報が外に出る経路は限られます。設定ファイルや管理画面の値が外部から読める、公開リポジトリや配布物に埋め込まれている、既定値のまま使われている、といった設定の問題が典型です。OWASP API Security Top 10 2023のAPI2（Broken Authentication）は、認証の仕組みは誰からも見えるため狙われやすいとし、APIキーは利用者の認証ではなくクライアントの識別に使うものだと述べています。

今回どの経路だったかは非公表です。ただ、外部の第三者がAPI認証情報を使えた時点で、そのキーで何ができるかが被害の上限を決めます。入口を塞ぐ対策と、キーの権限を絞る対策は別に考える必要があります。

管理API経由で特権ユーザーを作れる状態がデータ流出被害を広げる仕組み

特権ユーザーをAPIから作れる設計そのものは珍しくありません。問題は、通常の連携に使う認証情報にも、その操作が許されていた可能性がある点です。API5（Broken Function Level Authorization）は、管理者専用のはずの招待機能を一般の呼び出しから使い、役割をadminにした招待で管理者アカウントを作る攻撃例を挙げ、既定ですべてのアクセスを拒否し、機能ごとに特定の役割へ明示的に許可するよう求めています。

特権アカウントを作られると、その後の操作は正規の管理者と同じに見えます。一括取得もテンプレートメールの送信も、システムにとっては許可された操作です。だからこそ、ユーザー作成と権限変更の操作は、ほかの操作と分けて扱います。

外部ベンダーが構築したCMSで発注側が把握しておくべき設定の範囲

今回の調査の依頼先は、システムの開発ベンダーです。ベンダーが構築・保守するCMSでは、どのAPI認証情報が存在し、どの権限を持ち、どこに保管されているかを発注側が把握していないことがよくあります。少なくとも、管理APIの一覧と各認証情報の権限、発行日と最終利用日、特権アカウントの一覧の4点は、発注側の資料として受け取っておきます。

同じく事業者の管理側から被害が広がった例として、タイムズカーの不正アクセスや、受け口のサーバーから利用者のデータベースまで届いたGyazoの不正アクセスも比較の材料になります。

自社のCMSとAPIで点検する認可と認証情報の管理｜最小権限・失効・二要素

連携用のAPI認証情報からユーザー作成と権限変更の操作を外す

最初に手を付けるのは、連携用のAPI認証情報が持つ権限の棚卸しです。記事の投稿や会員情報の参照に使うキーに、ユーザーの作成や役割の変更まで許されていないかを確かめます。OWASPのSecrets Management Cheat Sheetは、認証情報には必要な用途に足りる最小限の権限だけを与えるよう求めています。

ユーザー作成と権限変更は、管理画面から人が操作する経路に限り、二要素認証を通った管理者だけに許すのが基本形です。APIで自動化する必要がある場合も、その操作専用のキーを分け、接続元を固定します。

API認証情報の有効期限と定期的なローテーションを組み込む運用手順

同じCheat Sheetは、盗まれた認証情報が短い期間しか使えないよう定期的にローテーションすること、可能な限り有効期限を付けること、手作業のローテーションは誤りを生みやすいため自動化することを挙げています。また、アプリケーションを再起動しても盗まれた認証情報は失効しない点にも注意を促しています。

事故が起きたときに、どのキーを止めれば被害が止まるかを即答できる状態にしておくことが目標です。発行したキーの一覧と用途、失効の手順を運用資料に残しておけば、通報を受けてから遮断までの時間を縮められます。

採用する条件と見送る場面｜小規模なCMSで過剰にしない線引き

ここまでの対策を一式入れる価値があるのは、外部の人の個人情報を数百件以上扱う、管理APIを外部連携に開いている、ベンダーに保守を任せている、のいずれかに当たる場合です。今回のハピコミュはこの3つすべてに当てはまります。

社内の数人だけが使い、個人情報を扱わず、APIも外部に開いていないCMSなら、キーの専用化や自動ローテーションまでは過剰です。その場合は、管理者アカウントの二要素認証、既定値の認証情報が残っていないかの確認、特権アカウント一覧の定期点検を先に固めます。

監査ログで特権付与とAPI急増を検知する｜Pythonで書く抽出スクリプト

CMSの監査ログにまず記録しておくべきユーザー管理と高リスク操作のイベント

今回の発覚は外部からの通報でした。社内で気づくには、検知の材料になるログが残っている必要があります。OWASPのLogging Cheat Sheetは、可能な限り常に記録すべきイベントとして、認証の成功と失敗、認可の失敗に加え、ユーザーの追加や削除、権限の変更といったユーザー管理操作、管理者権限の利用、データのインポートとエクスポートを挙げています。

CMSの監査ログにユーザー作成と役割変更が残るか、APIリクエストに使われた認証情報の識別子と接続元IPが残るかを確かめてください。残っていなければ、検知の前にログの設定から直す必要があります。

監査ログから特権ロールの作成と認証情報ごとのリクエスト急増を拾うコード

次のコードは、1行1件のJSON形式の監査ログから、管理者などの特権ロールでのアカウント作成・役割変更をすべて出力し、同じ認証情報からのAPIリクエストが5分間に300件を超えた箇所を報告します。Python 3.14.6で、特権アカウントの作成1件と、同一キーから0.5秒間隔で400件のリクエストを含むサンプルログを入力して動かし、両方が検出され、通常の会員作成と1分間隔のリクエストは検出されないことを確認しました。

import json
import sys
from collections import defaultdict
from datetime import datetime, timedelta

PRIV_ROLES = {"admin", "administrator", "owner"}
WINDOW = timedelta(minutes=5)
THRESHOLD = 300


def load(path):
    with open(path, encoding="utf-8") as f:
        for line in f:
            if line.strip():
                ev = json.loads(line)
                ev["ts"] = datetime.fromisoformat(ev["ts"])
                yield ev


def main(path):
    events = sorted(load(path), key=lambda e: e["ts"])

    # 1. 特権ロールでのアカウント作成・権限変更を全件出す
    for ev in events:
        if ev["action"] in ("user.create", "user.role_change") and ev.get("role") in PRIV_ROLES:
            print(f"[特権付与] {ev['ts']} actor={ev['actor']} "
                  f"target={ev['target']} role={ev['role']} ip={ev['ip']}")

    # 2. 認証情報ごとのAPIリクエスト数を5分窓で数える
    by_cred = defaultdict(list)
    for ev in events:
        if ev["action"] == "api.request":
            by_cred[ev["credential_id"]].append(ev["ts"])
    for cred, times in by_cred.items():
        start = 0
        for end, t in enumerate(times):
            while t - times[start] > WINDOW:
                start += 1
            if end - start + 1 >= THRESHOLD:
                print(f"[API急増] credential={cred} 開始={times[start]} 件数={end - start + 1}")
                break


if __name__ == "__main__":
    main(sys.argv[1])

入力の1行は、時刻、操作の種類、実行者、対象、役割、接続元IP、APIなら認証情報の識別子を持つ形を想定しています。サンプルログでの出力は次のとおりです。

[特権付与] 2026-09-09 00:46:10+09:00 actor=api:key-7 target=sysadm2 role=admin ip=203.0.113.5
[API急増] credential=key-7 開始=2026-09-09 00:45:02+09:00 件数=300

通常のAPIリクエスト数に基づく検知の閾値と特権付与を即時通知に回す運用

閾値の300件は例です。普段のAPIリクエスト数を1週間ほど集計し、最大値の数倍に置くのが出発点になります。連携の夜間バッチなど決まった大量処理は、認証情報ごとに除外するか、別の閾値を持たせます。

特権ロールの作成は、件数の閾値ではなく1件でも通知に回すべき操作です。人の手による作成でも、誰が作ったかを担当者がすぐ確かめられれば、正規の操作かどうかの判断は数分で済みます。痕跡を遡る手順は不正アクセスのログ確認・解析方法が使えます。

漏えい等報告と再発防止の段取り｜個人情報保護委員会への報告と外部点検

報告対象の4類型と速報・確報の期限を自社の事故に当てはめる際の判断基準

個人情報保護委員会の案内では、報告の対象は要配慮個人情報、財産的被害のおそれがある個人データ、不正の目的をもって行われたおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等（民間事業者）の4類型です。速報は発覚から3〜5日以内、確報は30日以内、不正の目的による場合は60日以内とされています。

今回は外部からの不正アクセスで、本人も2,835名と1,000人を超えています。集英社は速報を提出済みで、確報を取りまとめ中です。自社で同じ事故が起きたときの判断と段取りは個人情報保護委員会への報告義務で詳しく扱っています。

次の侵害に備えて自社のCMSと管理APIを外部の目で点検する順番

点検の順番は、特権アカウントと管理APIの認証情報の棚卸し、各認証情報の権限と保管場所の確認、監査ログでユーザー作成と権限変更が追えるかの確認です。設定の不備は作った側では気づきにくく、ベンダーに保守を任せている場合はなおさらです。

管理APIの認可や認証情報の扱いを含めて外部に点検を任せたい場合は、脆弱性診断・セキュリティ診断で、CMSの設定から管理APIの権限までを通して確認できます。

よくある質問

集英社の不正アクセスについて、関係者と開発者から出やすい質問をまとめました。

自分が対象のブロガーかどうかはどうすれば分かりますか？

集英社は9月25日に、対象のブロガーへ登録メールアドレス宛てで個別に通知しています。この通知が届いていれば対象です。届いていない場合や内容を確かめたい場合は、公式発表に記載された集英社デジタルソリューション部の問い合わせ窓口へ、公式発表のPDFに載っている連絡先から問い合わせてください。

パスワードの流出はありましたか？

公表された漏洩事項に、ブロガーのパスワードは挙がっていません。ただしSNSアカウントとメールアドレスが流出しているため、それらを狙った偽のログイン画面やパスワード再設定の誘導には注意が必要です。二要素認証を有効にしておくと被害を防ぎやすくなります。

CMSの製品名や設定不備の中身は分かっていますか？

2026年10月9日時点で公表されていません。公式発表は、利用しているCMSの設定の不備に起因するAPI認証情報を狙った攻撃とだけ説明しています。外部会社によるフォレンジック調査が続いているため、続報で詳細が出る可能性があります。

取引先として登録されていた企業は何をすればよいですか？

取引先一覧は会社名が全件、メールアドレス26件、電話番号113件が対象で、担当者名は含まれていません。集英社や各誌を名乗る請求先・振込先の変更、ファイル共有への招待などは、通常の取引経路で確かめてから応じてください。

自社のCMSは何から点検すればよいですか？

最初に、管理APIの認証情報の一覧と、それぞれがユーザー作成や権限変更をできるかを確かめます。次に特権アカウントの一覧と二要素認証の有無、最後に監査ログでユーザー作成と権限変更、認証情報ごとのリクエストが追えるかを確認します。

関連記事

• 講談社の個人情報流出3,812件｜フィッシング起点のアカウント侵害の技術解説：同じ出版社で入口が異なる事例
• タイムズカーの不正アクセスと約660万件の流出｜免許証画像を退会者まで残さない保管設計：事業者側の侵害で関係者が回す点検の比較に
• Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：受け口から利用者データまで届いた構図の比較に
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：自社で事故が起きたときの報告の段取り
• 不正アクセスのログ確認・解析方法｜見るべきログと攻撃痕跡の調べ方を実践解説：特権付与やAPI急増の痕跡調査に