--- title: "コミックシーモア不正アクセスで会員情報流出：再開時期・パスワード再設定と運営側のログ点検" url: "https://www.issoh.co.jp/tech/details/18569/" published: 2026-10-19 updated: 2026-10-19 categories: ["セキュリティ"] publisher: "株式会社一創" --- # コミックシーモア不正アクセスで会員情報流出：再開時期・パスワード再設定と運営側のログ点検 電子書籍ストア「コミックシーモア」を運営するNTTソルマーレは、2026年10月15日11時35分にサービスを停止し、翌16日に会員情報の流出を公表しました。流出したのはメールアドレス、ハッシュ化されたパスワード、生年月日、性別、ニックネームの5項目で、件数は精査中です。本記事では、会員が知りたい「自分は対象か」「パスワードはどうするか」「いつ再開するか」「買った本は消えないか」に公式発表の文言で先に答えます。後半では、第3報で判明した「システムログファイルの閲覧・取得」を受けて、運営側がログに残った会員情報を見つけて伏せる方法を、手元で動かしたPythonで示します。 ## まとめ：コミックシーモア不正アクセスで公表された事実と会員が今日やること 確定しているのは次の事実です。10月15日にサーバーへの外部からの不正アクセスの可能性が高いと判断してサービスを止め、16日に会員情報を管理するシステムから会員情報が第三者へ流出したことを確認しました。18日の第3報では、原因を特定して対処を進めていること、一部のシステムログファイルも閲覧・取得されていたことが加わりました。クレジットカード情報は対象のシステムで持っておらず、流出していません。 会員が今日やることは1つです。コミックシーモアと同じメールアドレスとパスワードの組み合わせを使っている他社サービスのパスワードを変えてください。コミックシーモア自体のパスワードは、再開時に全会員へ再設定を依頼する予定と案内されています。運営側が学べるのは、会員DBだけでなくログファイルも持ち出しの対象になる点です。 | 項目 | 公表されている内容（10月18日時点） | | ------ | ------------------------- | | サービス停止 | 2026年10月15日（木）11時35分 | | 流出の確認 | 10月16日（金）会員情報を管理するシステム | | 流出した項目 | メール・PWハッシュ・生年月日・性別・ニックネーム | | 対象件数 | 精査中 | | 追加で判明 | 一部のシステムログファイルの閲覧・取得 | | カード情報 | 対象システムで保有せず流出なし | | 再開日時 | 未定（購入済書籍のWEB閲覧から順次の予定） | 表中のメールはメールアドレス、PWハッシュはハッシュ化されたパスワードを指します。 ## 会員が最初に確かめる5点｜対象確認・パスワード・再開時期・MY本棚・偽メール ### 自分が対象かは件数の精査中で流出を確認した会員へ個別連絡の段階 10月18日の[第3報](https://www.nttsolmare.com/press/2026/1016-1.html)でも対象件数は「引き続き精査中」です。同じ発表は、流出が確認されたお客様には確認でき次第速やかに連絡すると書いています。今の段階で「自分は対象外」と判断できる材料はありません。 会員登録をしていれば対象になり得る、という前提で動くのが安全です。連絡は登録メールアドレスに届くと考えられますが、届き方は公表されていません。迷惑メールのフォルダも含めて、NTTソルマーレ名の連絡を見落とさないようにしてください。 ### 再開時に全会員へパスワード再設定を依頼予定で今は他社サービスを先に変更 第2報と第3報は、サービス再開時に全会員へパスワードの再設定を依頼する予定だと書いています。サービスは止まっているので、コミックシーモアのパスワードを今変える手段はありません。詳細は再開時に知らせるとされています。 先に手を付けるのは他社サービスです。発表は、流出したメールアドレスとパスワードの組み合わせで、第三者が他のWebサービスへの不正ログインを試みるおそれがあると呼びかけています。順番は、メールアカウント、ネット銀行と決済、通販サイトの順が目安です。メールを乗っ取られると、他のサービスのパスワード再設定まで奪われます。使い回しを避ける決め方は[パスワード管理のベストプラクティス](https://www.issoh.co.jp/column/details/13508/)で整理しています。 ### 購入済みの本とMY本棚は流出・消失・欠損とも10月18日時点で確認されず 第2報は「購入履歴の流出、MY本棚の流出・消失・欠損は現時点確認されておりません」と書き、第3報も「現時点においても確認されておりません」と繰り返しました。買った本の一覧が消えたという事実は、今のところ公表されていません。 ただし「確認されていない」は「無事が確定した」とは違います。ログの精査が続いているためです。再開後にMY本棚を開き、購入した作品がそろっているかを確かめてください。 ### 再開日時は未定で購入済書籍のWEB閲覧から順次再開する準備の段階 第3報は、原因は特定できたものの、さらなる安全性の確保と関係機関との調整が必要なため、正確な再開日時を伝えるのは難しいと説明しています。再開は、購入済書籍のWEBでの閲覧から順次進める準備をしているとのことです。新しい本の購入や会員登録がいつ戻るかは書かれていません。 2026年10月19日に当社が確認した時点で、cmoa.jpのトップページは応答コード503（サービス一時停止）を返していました。再開の告知は[NTTソルマーレのニュースリリース](https://www.nttsolmare.com/press/2026/1016.html)に出るので、SNSの転載ではなく発表元で確かめてください。 ### お詫びや再開案内を装う偽メールの見分け方と公式の問い合わせ先 発表は、流出した情報が悪用され、同社や関係者を装った不審なメールが届く可能性があるとしています。身に覚えのないメールのURLや添付ファイルは開かないこと、不審なサイトに個人情報やパスワードを入力しないことを求めています。「再開に伴うパスワード再設定」をうたうメールは、本物の案内が来る前提があるぶん信じやすく、特に疑ってください。 メールのリンクからではなく、自分でブラウザに公式サイトのアドレスを入れて開くのが確実です。発表に載っている問い合わせ先は、NTTソルマーレ経営企画部の広報担当のメールアドレスです。フィッシングの最新の報告は[フィッシング対策協議会](https://www.antiphishing.jp/)が公開しています。 ## 公式発表3報を時系列で確認する｜10月15日11時35分の停止から18日の第3報まで ### 初報から第3報までの4日間で分かったことと分かっていないことの一覧 3本の発表を並べると、日を追うごとに確定した事実が増えています。なお第3報のページの日付は10月18日ですが、URLは「1016-1」です。初報のURLも「0616-1」で日付と一致しないため、リンクを共有するときは見出しで判断してください。 | 発表 | 日付 | 新しく分かったこと | | --- | ------ | ------------------------- | | 初報 | 10月15日 | 不正アクセスの可能性が高いと判断し緊急メンテナンス | | 第2報 | 10月16日 | 11時35分の停止・会員情報5項目の流出を確認 | | 第3報 | 10月18日 | 原因を特定・システムログの閲覧と取得・再開は未定 | 未公表のまま残っているのは、件数、侵入経路と攻撃手法の中身、パスワードのハッシュ方式、不正アクセスが始まった日時の4点です。[初報](https://www.nttsolmare.com/press/2026/0616-1.html)から第3報まで、どの発表もこれらを書いていません。本記事も手口を断定しません。 ### 第3報で加わったシステムログの閲覧・取得と件数がまだ確定しない理由 第3報は、前回発表した会員情報に加えて、一部のシステムログファイルも閲覧・取得されたことが判明し、会員情報の有無を確かめるためにログを精査していると書いています。件数が確定しない理由の1つがここにあります。会員DBなら件数は行数で数えられますが、ログに何人分の情報が紛れているかは、中身を1行ずつ調べないと分かりません。 システムログには、アクセスの記録、エラーの詳細、不具合調査のために一時的に出したデバッグ出力などが入ります。どれに会員情報が入っていたかは公表されていません。ただ、運営する側からすると、「会員DBは守っていたがログに同じ情報が残っていた」という事態はどの会員サービスでも起こり得ます。後半の2章でこの点検の方法を示します。漏えい時の報告の段取りは[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で整理しました。報告の様式は[個人情報保護委員会の「漏えい等の対応とお役立ち資料」](https://www.ppc.go.jp/personalinfo/legal/leakAction/)にあります。 ### ハッシュ化されたパスワードでも使い回しの変更と全会員の再設定が要る理由 第3報は、ハッシュ化されたパスワードを「元のパスワードをそのまま保存せず、元の内容を読み取れない形に変換したもの」と説明しています。そのままでは読めませんが、どの方式でハッシュ化していたかは公表されていません。短いパスワードや辞書にある語は、方式によっては総当たりで割り出されます。 [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)は、Argon2idをメモリ19MiB・反復2・並列度1以上で使うよう勧めています。この設定は解読を遅らせるもので、解読そのものを不可能にはしません。全会員の再設定が予定されているのはこのためです。ハッシュと暗号化の違いは[ハッシュ化とは](https://www.issoh.co.jp/column/details/13487/)、解読にかかる手間の見積もりは[銀のさらの不正アクセスの記事](https://www.issoh.co.jp/tech/details/18365/)で扱いました。 ## ログに会員情報が残っていないかを調べる｜Pythonで5種類の値を数えるスキャナ ### OWASP Logging Cheat Sheetに基づく認証情報・個人データの記録除外 [OWASP Logging Cheat Sheetの「Data to exclude」](https://cheatsheetseries.owasp.org/cheatsheets/Logging%5FCheat%5FSheet.html)は、ログに直接記録せず、削除・マスク・ハッシュ化・暗号化するべき値を列挙しています。会員サービスで特に当てはまるのは次の項目です。 - 認証のパスワード（Authentication passwords） - アクセストークン（Access tokens） - セッションIDの値（必要ならハッシュ値に置き換える） - 機微な個人データと一部の個人を特定できる情報（PII） - データベースの接続文字列と暗号鍵 - 銀行口座やカード会員のデータ 同じ文書は、ログを保存する仕組みが扱ってよい分類より上のデータを記録しないことも求めています。実務で最初に見るのはパスワードとトークンです。次にメールアドレスと生年月日を見ます。この順で調べると、流出したときの被害が大きい値から片付きます。 ### ログファイルからメールアドレスやパスワードを検出するPythonスクリプト 次のスクリプトは、指定したログファイルを1行ずつ読み、メールアドレス、password=で始まる値、bcryptとArgon2形式のハッシュ、Bearerトークン、生年月日の5種類が出る行を数えます。Python 3の標準ライブラリだけで動き、scan\_logs\_pii.pyとして保存します。正規表現は自社のログの形式に合わせて足してください。 ``` import re, sys, glob, collections # ログに残ってはいけない値の検出パターン PATTERNS = { "email": re.compile(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}"), "password": re.compile(r"(?i)\b(password|passwd|pwd)=[^&\s\"]+"), "pw_hash": re.compile(r"\$(2[aby]|argon2id|argon2i)\$[^\s\"]+"), "bearer": re.compile(r"(?i)authorization: ?bearer [A-Za-z0-9._~+/=-]+"), "birthday": re.compile(r"(?i)\b(birthday|birth_date|dob)=\d{4}-?\d{2}-?\d{2}"), } hits = collections.Counter() files_hit = collections.defaultdict(set) emails = set() for path in sys.argv[1:]: for f in glob.glob(path): with open(f, encoding="utf-8", errors="replace") as fh: for line in fh: for name, rx in PATTERNS.items(): found = rx.findall(line) if found: hits[name] += 1 files_hit[name].add(f) if name == "email": emails.update(m.lower() for m in found) for name in PATTERNS: print(f"{name:9} {hits[name]:7}行 {len(files_hit[name])}ファイル") print(f"異なるメールアドレス {len(emails)}件") sys.exit(1 if hits else 0) ``` 2026年10月19日に、Python 3.14.7で架空のログに対して実行しました。アクセスログ50,000行は会員IDとパスだけを記録した形式です。アプリログ20,000行には、不具合調査で入れたまま残ったデバッグ出力が混ざっている想定で、ログインのリクエスト内容やパスワード更新のSQLを入れています。 ``` $ python scan_logs_pii.py "logs/*.log" email 395行 1ファイル password 395行 1ファイル pw_hash 183行 1ファイル bearer 223行 1ファイル birthday 428行 1ファイル 異なるメールアドレス 393件 $ echo $? 1 ``` ### ログの検出結果の読み方と流出時に影響を受ける会員数を見積もる手順 検出はすべてアプリログの1ファイルに集中し、アクセスログからは出ませんでした。会員IDだけを記録する形式なら、ログが持ち出されてもメールアドレスは漏れません。逆にアプリログ側では、ログインのデバッグ出力1種類がメールアドレスとパスワードを平文で395行残していました。 「異なるメールアドレス」の件数は、そのログが流出したときに連絡すべき会員数の下限になります。調べる対象は、アプリサーバーの手元にあるファイルだけではありません。ログの転送先、障害調査のために社内で共有した抜粋、バックアップも同じスクリプトにかけます。終了コードは1件でも見つかれば1なので、定期実行して検出が出たら通知する使い方もできます。 ## ログを書く時点で会員情報を伏せる｜logging.Filterで5種類の値を置き換える設定 ### Python標準のlogging.Filterで出力前にメッセージを書き換える仕組み スキャナは残ってしまった値を見つける道具です。新しく書かれるログには、書き出す前に伏せる仕組みを入れます。[Pythonの公式ドキュメント](https://docs.python.org/3/library/logging.html#filter-objects)は、Filterがログレコードをその場で書き換えられること、ハンドラーに付けたFilterは出力の直前に呼ばれることを説明しています。次の設定で出力するのは、スキャナと同じ5種類の値を置き換えたログです。mask\_filter.pyとして保存します。 ``` import logging, re # 書き出す前にログの文字列から会員情報を伏せる Filter RULES = [ (re.compile(r"(?i)\b(password|passwd|pwd)=[^&\s\"]+"), r"\1=***"), (re.compile(r"\$(2[aby]|argon2id|argon2i)\$[^\s\"]+"), "[PW_HASH]"), (re.compile(r"(?i)(authorization: ?bearer )[A-Za-z0-9._~+/=-]+"), r"\1***"), (re.compile(r"(?i)\b(birthday|birth_date|dob)=\d{4}-?\d{2}-?\d{2}"), r"\1=***"), (re.compile(r"[A-Za-z0-9._%+-]+@([A-Za-z0-9.-]+\.[A-Za-z]{2,})"), r"[EMAIL \1]"), ] class MaskFilter(logging.Filter): def filter(self, record): msg = record.getMessage() for rx, rep in RULES: msg = rx.sub(rep, msg) record.msg, record.args = msg, None return True handler = logging.StreamHandler() handler.addFilter(MaskFilter()) handler.setFormatter(logging.Formatter("%(levelname)s %(message)s")) log = logging.getLogger("member") log.addHandler(handler) log.setLevel(logging.INFO) log.info("POST /login email=%s password=%s", "hanako.sato" "@example.jp", "Seymour2026!") log.info("Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0ODIxMyJ9.sig") log.info("UPDATE members SET pw=%s WHERE id=48213", "$2b$12$Q9b7cJxM1k3s0fPpZr8m2uYb6eGkqL0yW1n5vT3aH2dC4xE6zR7iO") log.info("profile birthday=1990-04-01 nickname=hana") ``` 2026年10月19日に実行した結果です。パスワードとトークン、ハッシュ、生年月日は値ごと伏せ、メールアドレスはドメインだけを残しました。問い合わせ対応で「どのドメインの会員か」を追えるようにするためです。 ``` $ python mask_filter.py INFO POST /login email=[EMAIL example.jp] password=*** INFO Authorization: Bearer *** INFO UPDATE members SET pw=[PW_HASH] WHERE id=48213 INFO profile birthday=*** nickname=hana ``` ### マスキングで防げない経路とログ保管先の権限・保持期間の見直し このFilterはloggingを通る出力にしか効きません。Webサーバーやロードバランサーのアクセスログにクエリ文字列として会員情報が載る作り、例外の詳細にリクエスト本文がそのまま出る設定は、別に止める必要があります。会員情報はURLのクエリに入れず、POSTの本文で送るのが前提です。ニックネームのように形式で判定できない値も、この方法では伏せられません。 伏せた上で、ログを誰が読めるかと何日残すかも決め直してください。第3報が示したとおり、ログは持ち出しの対象になります。Laravelでのチャンネル別の保持期間とマスキングは[Laravelのログ設定](https://www.issoh.co.jp/tech/details/17156/)、改ざんを防ぎながら集める構成は[Fluentdで監査ログ基盤を作る](https://www.issoh.co.jp/tech/details/10505/)で解説しています。 ## 全会員パスワード再設定に備える｜再開時の一斉リセットで詰まる2つの箇所 ### 旧パスワードの一斉無効化と再設定画面にアクセスが集中する負荷対策 コミックシーモアは再開時に全会員へ再設定を依頼する予定です。同じ準備は、会員DBを持つどの事業者にも要ります。詰まりやすいのは2か所です。1つ目は、旧パスワードを一斉に無効化し、次のログインで必ず再設定に回す処理が用意されているか。2つ目は、再設定の画面とメール送信が全会員分の集中に耐えるかです。 2026年10月公表の[ソースネクストの不正アクセス](https://www.issoh.co.jp/tech/details/18387/)では、全会員のパスワードを初期化した後、再設定サイトにアクセスが集中してつながりにくくなりました。再設定メールのリンクを装う偽メールも同時期に出やすくなります。Cognitoでの管理者リセットとロックアウトの設計は[Cognitoのパスワードリセット実装](https://www.issoh.co.jp/tech/details/18514/)にまとめています。 ## ログ点検を今月中に進める事業者と後回しにしてよい事業者の線引き ### デバッグ出力を本番に残したまま会員数が数十万件を超える事業者 自社のサーバーに会員DBとアプリログを置き、会員数が数十万件を超えるなら、今月中に本記事のスキャナを本番相当のログにかけてください。過去にログインやパスワード変更の不具合を調べたことがあれば、そのときのデバッグ出力が残っていないかを先に見ます。検出が出た場合は、ファイルの削除だけでなく、転送先とバックアップの消去、出力したコードの修正までをセットで行います。 APIの認可とレート制限、トークン失効は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で扱いました。ログの置き場所が多く自社で洗い出しきれないとき、侵入経路も含めて第三者の目で確かめたいときは、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、ログに残る会員情報と保管先の権限を含めて点検できます。 ### ログを外部に送らず保持7日以内で会員情報を扱わない小規模サービス 会員情報を自社で持たず、認証を外部のIDaaSに任せていて、ログの保持が7日以内のサービスなら、スキャナの定期実行まで組むのは過剰です。確かめるのは、IDaaSから受け取るトークンをログに出していないかの1点で足ります。上のFilterのBearerの行だけを入れておけば、ほぼ間に合います。 ## よくある質問 コミックシーモアの不正アクセスについて、会員と会員サービスを運営する担当者から出やすい質問をまとめました。 ### コミックシーモアで買った本はなくなりますか？ 10月18日の第3報の時点で、購入履歴の流出とMY本棚の流出・消失・欠損は確認されていません。再開は購入済書籍のWEBでの閲覧から順次進める準備をしていると発表されています。ログの精査が続いているため確定ではありませんが、本が消えたという公表はありません。再開後にMY本棚を開いて確かめてください。 ### コミックシーモアはいつ再開しますか？ 第3報は、原因は特定できたものの、安全性の確保と関係機関との調整が必要なため正確な再開日時は伝えられないとしています。再開日時は確定次第知らせるとのことです。2026年10月19日時点で再開日の発表はありません。告知はNTTソルマーレのニュースリリースで確かめてください。 ### コミックシーモアのパスワードは今すぐ変えるべきですか？ サービスが止まっているため、今は変更できません。再開時に全会員へ再設定を依頼する予定と案内されています。今やるべきなのは、同じメールアドレスとパスワードを使っている他社サービスの変更です。メールアカウントを最初に変えてください。 ### クレジットカードは止める必要がありますか？ 発表によると、クレジットカード情報は今回の対象システムでは保有しておらず、流出していません。本件を理由にカードを止める必要は、公表された事実からは読み取れません。明細に覚えのない請求があれば、本件とは別にカード会社へ問い合わせてください。 ### 自社のログに会員情報が残っていないか、何から調べればよいですか？ 最初にアプリログから、パスワード、トークン、メールアドレスが出る行を数えます。本記事のスキャナのように正規表現で拾えば、どのファイルに何件あるかを確認できます。次に同じ方法で調べる対象は、ログの転送先とバックアップです。最後に、新しく書かれるログにマスキングを入れて、同じ値が増えない状態にします。 ## 関連記事 - [ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検](https://www.issoh.co.jp/tech/details/18387/)：会員APIの返却項目と大量取得の検知 - [とらのあな電子書籍の不正クローリング｜5日ぶりの再開までの経緯と利用者の確認点](https://www.issoh.co.jp/tech/details/12234/)：電子書籍ストアが停止から再開するまでの経緯 - [バーガーキング情報漏洩どうしたらいい？約1,118万件の対象確認・補償・退会とメールの真偽](https://www.issoh.co.jp/tech/details/18384/)：不正アクセスの期間を割り出すSQL - [フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](https://www.issoh.co.jp/tech/details/13548/)：お詫びメールを装う手口と実装側の対策 - [情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】](https://www.issoh.co.jp/column/details/18315/)：情報漏洩を原因別に防ぐ全体像 --- 出典: [コミックシーモア不正アクセスで会員情報流出：再開時期・パスワード再設定と運営側のログ点検]()（株式会社一創）