集英社は2026年9月28日、「HAPPY PLUS COMMUNITY(ハピコミュ)」が不正アクセス を受けたと公表しました。ファッション誌のメディアで活動するブロガーの、情報管理・連絡用のシステムです。登録されていたブロガー2,835人分の個人情報などが漏えいしています。原因は、利用しているCMS(サイトの中身を管理する仕組み)の設定の不備と説明しています。
集英社が公表した内容
お知らせは集英社のサイトの「お知らせ」にPDFで載っています。中身を表にまとめます。
項目
公表の内容
公表した日
2026年9月28日(集英社 デジタルソリューション部)
対象のシステム
HAPPY PLUS COMMUNITY(ハピコミュ)。ファッション誌のメディアで活動するブロガーの情報管理・連絡用システム
不正アクセスの日時
2026年9月9日(水)0時45分から1時25分と、13時42分から16時46分
気づいたきっかけ
この時間内に、システムのテンプレートを使ったメールが100人のメールアドレスあてに計3通送られた。受け取った人からの通報で、14時53分に発覚した
漏えいした情報
ブロガーの情報2,835件、案件情報630件、システムから送ったすべてのメール11,237件、取引先一覧10,780件
原因(集英社の説明)
CMSの設定の不備に起因するAPI認証情報を狙った攻撃を受け、特権ユーザーのアカウントが不正に作られ、APIリクエストを繰り返し実行されたことで漏えいしたと考えている
漏えいした情報の中身
ブロガーの情報は、氏名、メールアドレス、住所、電話番号、生年月日、性別、職業などです。プロフィール画像、SNSアカウント、フォロワー数、結婚状況、子の有無、身長、肌タイプなども含まれます。本人か編集部が個人別の画面に入れた情報で、媒体や人によって項目の数が違います。
集英社のお知らせの1ページ目。漏えいした事項と件数が並ぶ 出典: 集英社「「HAPPY PLUS COMMUNITY」への不正アクセスによる個人情報漏洩のお詫びとお知らせ」 (引用) 案件情報は、ブログや撮影、イベント参加などを依頼した記録です。取引先一覧は、会社名が全件、メールアドレスが26件、電話番号が113件です。担当者の氏名は登録されていないとしています。
集英社がしたこと
開発ベンダーに調査を頼み、不正なアカウントを削除して設定を変えた
不正アクセスの原因となった脆弱性 をなくし、不正検知の設定を強めた
9月25日、該当するブロガーに、登録のメールアドレスあてで概要・漏えいした内容・対応窓口を知らせた
さらなる被害がないかを確かめるため、外部の会社によるフォレンジック調査(攻撃の跡を調べる調査)を行っている
個人情報保護 委員会に速報を出し、確報をまとめている
集英社のお知らせの2ページ目。経緯と原因、対応が書かれている 出典: 集英社「「HAPPY PLUS COMMUNITY」への不正アクセスによる個人情報漏洩のお詫びとお知らせ」 (引用) 問い合わせ先は、デジタルソリューション部のメールアドレス hpc-contact@ms.shueisha.co.jp です。
登録しているブロガー・取引先が気をつけること
お知らせには、不審な連絡への注意などの呼びかけは書かれていません。ここからは集英社の公表ではなく、一般的な注意です。
漏えいした情報には、システムから送ったメールの中身も含まれる。過去のやりとりに似せた連絡が来ても、リンクや添付を開く前に、前から知っている連絡先で確かめる
住所や電話番号も含まれる。編集部を名乗る電話や郵便で、口座やパスワード を聞かれても答えない
SNSのアカウントも含まれる。SNSに届く、編集部を名乗るメッセージやログインを促すリンクにも気をつける
影響する人・会社、しない人・会社
影響する: HAPPY PLUS COMMUNITYに登録されていたブロガー2,835人。集英社は9月25日にメールで知らせたとしています。
影響する: システムから送られたメールの相手と、案件の依頼の記録に出てくる人・会社。メール11,237件と案件情報630件も漏えいしています。
影響する: 取引先一覧に載っていた会社。10,780件のうち、メールアドレスは26件、電話番号は113件です。
影響しない: HAPPY PLUS COMMUNITYに登録がなく、案件やメールのやりとり、取引もない人と会社。公表の対象は、このシステムに入っていた情報です。
管理者アカウントとAPIの認証情報を点検する
公表から言えること
入口はCMSの設定の不備で、狙われたのはAPI(ほかの仕組みからデータを出し入れする窓口)の認証情報だった
攻撃者は特権ユーザー(管理者の権限を持つ利用者)のアカウントを作り、APIで情報を取り出した
気づいたきっかけは、システムから身に覚えのないメールが送られ、受け取った人が通報したことだった
一般的な備え
ここからは今回の原因と結びつけず、一般的な備えとして整理します。
管理者の権限を持つアカウントの一覧を月に1回出し、知らないアカウントがないかを見る。作られたら通知が来る設定にする
APIのキーやトークン(認証情報)の置き場所と持ち主を書き出し、使っていないものは無効にする
短い時間にAPIの呼び出しが急に増えたら、通知が来るようにする
APIのキーの置き場所は、「APIキーは.envに」はもう危ない AIエージェントに渡す権限の決め方 でも整理しています。システムの開発や保守を外に頼んでいるなら、委託先に設定の点検や記録の残し方を聞きます。次のシートを使えます。
会社・情シスが今日やること
集英社の雑誌の案件にかかわる部署に、HAPPY PLUS COMMUNITYからのメールや取引がなかったかを聞く
集英社や編集部を名乗る心当たりのないメールは、リンクや添付を開かずに、知っている連絡先で確かめるよう社員に伝える
自社が使うCMSや業務システムの管理者アカウントの一覧を出し、知らないものや退職者のものがないかを確かめる
APIのキーやトークンの置き場所と持ち主を書き出し、使っていないものを止める。委託先が持っている分も聞く
「御社のシステムから変なメールが届いた」と社外から連絡を受けたときの窓口と、システムを止める人を決める
漏えいに気づいたあとの報告と通知の流れは、委託先で個人情報が漏えいしたら?報告3〜5日・30日と本人通知の流れ にまとめています。
