Substackは2026年2月、69万ユーザーのデータを失った

私はSubstackを使い続ける。2026年2月の事件があっても

※私自身が被害に遭ったわけではないので、安心して読み進めてください。今回はセキュリティ意識を高める為、あえてこのようなメールを送らせていただきます。ぜひ最後までお読みください。

API scraping攻撃の手口と、ニュースレター運営者が翌日から取るべき対策

2026年2月6日、SubstackのCEO Chris Bestから全ユーザーに直接謝罪メールが届いた。本文は短く、しかし致命的だった。約69万7千ユーザー分のメールアドレス、電話番号、内部メタデータが、外部からアクセスされたまま放置されていた。

財務データは無事、パスワードもクレジットカードも漏れていない。Substack側はそう繰り返した。

それでも、私はこの事件を「軽微な事故」として扱わない。理由は二つある。一つは、攻撃が実行されたのは2025年10月であり、検出は4ヶ月後だったという時系列。もう一つは、流出した情報の性質だ。

4ヶ月の沈黙が意味するもの

2025年10月、何者かがSubstackのAPIに対してscraping攻撃を仕掛けた。「scraping」というのは、APIを連続して叩いて、本来一度に取り出せない情報を大量に抜き出す手口だ。Substack側のAPIには脆弱性があり、攻撃者はそれを使ってユーザー情報を約69万7千件抜いた。Substackは2026年2月にこの異常を検出し、システムを修正し、CEOが謝罪メールを送った。

問題は、攻撃から検出までの4ヶ月だ。

セキュリティ業界では「breach detectionは時間を要する」と言われる。実際、これは特別に遅い検出ではない。MITREのレポートを見ても、世界の平均的な侵害検出期間は数ヶ月単位だ。多くの侵害は、攻撃が止まった後に検出される。サイバー攻撃というのは、警報が鳴る種類のものではなく、後から痕跡を辿って気付く種類のものだ。

これが何を意味するか。攻撃者は4ヶ月間、Substackから抜いたデータを「自由に処理する時間」を持っていた。データは既に流通しているか、別のデータベースと統合されているか、あるいは静かに次の攻撃の準備に使われている。

「現時点で悪用の証拠はない」とSubstackは書いた。これは事実関係を述べているだけで、未来を予測しているわけではない。私はこの一文を、額面通り受け取ることを推奨しない。

メールアドレスと電話番号で何ができるか

流出した情報は、メールアドレス、電話番号、内部メタデータ。財務情報は無事。

「財務情報は無事だったから大丈夫」と読む人がいる。これは、サイバーセキュリティの初心者がよく間違える解釈だ。

財務情報の流出は、即座の被害(不正利用)を生む。メールアドレスと電話番号の流出は、即座の被害は生まない。代わりに、「時間をかけた精巧な攻撃」の弾丸になる。

精巧な攻撃の典型例を書く。

ある日、メールアドレスに「Substackから」と名乗るメールが届く。差出人は本物のSubstackのドメインに似せた偽ドメイン。「あなたのアカウントに不審なアクセスがありました。下記のリンクからパスワードを再設定してください」と書いてある。リンクは偽サイトに繋がっており、そこで入力したパスワードが盗まれる。

これがフィッシング（phishing）だ。

別のパターン。メールアドレスから推測した電話番号に、「Substack技術サポート」を名乗る電話がかかってくる。「あなたのアカウントに侵入の試みがありました。すぐに認証コードを送るので、口頭で読み上げてください」と言われる。読み上げると、それはSubstackやGmailの二段階認証コードで、攻撃者はユーザーアカウントに侵入する。

これがソーシャルエンジニアリング（social engineering）だ。

どちらの攻撃も、攻撃者が「メールアドレスと電話番号がSubstackに登録されている」という事実を知っているからこそ成立する。普通の不審メールなら警戒できる。「Substackから」というコンテキストが正しいと、警戒心が下がる。

財務情報の流出より、メールアドレスと電話番号の流出のほうが、長期的には恐ろしい。これは私の意見ではなく、サイバーセキュリティの実務家の標準的な評価だ。

「絶対安全なプラットフォーム」は存在しない

ここで一歩引いて考えたい。

「Substackが信用ならないから別のプラットフォームに移ろう」という発想は、ほぼ間違いだ。理由を説明する。

過去5年で大規模な情報流出を経験していないプラットフォームを探すのは難しい。Facebook、X、LinkedIn、Yahoo、Adobe、過去にすべて流出している。Substackだけが特別に悪いわけではない。情報流出はインターネットインフラの構造的な問題であり、どのプラットフォームを使っても、ある確率で起きる。

「Substackは危険だからやめる」と判断する人は、論理的には「インターネット全体をやめる」しかない。それは現実的でない。

正しい問いは、「Substackで配信を続けながら、どう自己防衛するか」だ。

Substack利用における5つの対策

ここから具体策を書く。私自身がやっていること、私のクライアントに勧めていることだ。

第一に、subscriber listを月1回CSV形式で書き出してローカルに保存する。これはSubstackの管理画面、Settings > Import/ExportでCSVを生成できる。月に1度、5分の作業だ。これをやっていれば、Substack側でアカウントが停止された時も、データ漏洩で混乱した時も、自分の手元にはリストが残る。月次バックアップは習慣化しないと続かない。スマホのカレンダーに毎月1日のリマインダーを入れる。

第二に、読者との「Substack外の連絡手段」を確保する。具体的には、自分の独自ドメインのメールアドレスを、Welcome emailに明記する。「いつでも返信してください、私が直接返事します」と書いておく。これをやっておくと、Substackが何かの理由で使えなくなった時、読者と直接連絡を取る経路が生きる。Substackのメッセージ機能だけに依存していると、Substackが落ちた瞬間に読者と切れる。

第三に、Substackからの不審メールに対する読者教育を、自分のニュースレター内で一度行う。「Substackからのメールに見える詐欺メールが今後増える可能性があります。私のメールから来たものか必ず差出人を確認してください」と。これは保険であり、同時に書き手としての誠実さの証明にもなる。読者は「この書き手はリスク管理ができている」と感じる。

第四に、自分自身のSubstackアカウントに二段階認証を設定する。Settings > Securityから設定できる。これは個人の防御策であり、書き手が自分のアカウントを乗っ取られて、読者に詐欺メールを送りつけられる事態を防ぐ。書き手のアカウントが乗っ取られれば、その被害は読者全員に及ぶ。

第五に、Substack上の本文・プロフィール・コメントに、個人を特定する情報を必要以上に書かない癖をつける。住所、家族構成、勤務先の社内情報、子供の学校名、こうした情報は将来のsocial engineeringの弾丸になる。書き手は知らず知らずに自分の情報を本文に織り込みがちだ。一度自分のプロフィールと過去5本の記事を読み直し、消せる情報は消す。

中小企業オーナーへの追加の論点

私の読者には、中小企業オーナーや個人事業主が多い。そんなあなたに対しては、追加で伝えたいことがある。

自社の業務でSubstackを使う場合、流出リスクは「個人のリスク」ではなく「事業のリスク」に変わる。顧客のメールアドレスを集めたリストがSubstack上に蓄積されていて、それが流出した場合、顧客への通知義務が生じる可能性がある。

日本の個人情報保護法は、5,000件を超える個人情報を扱う事業者に対して、漏洩時の通知義務を課している。Substackが直接の漏洩主体だとしても、書き手側もリストの管理責任を問われる場面が出てくる。これは法律家に確認すべき領域だが、知らずに使っていると、ある日突然問題になる。

「個人のニュースレターだから関係ない」と言い切れる人と、「事業として運用している以上、事業リスクとして扱う必要がある」人で、対応が違う。自分がどちらに属するか、一度真剣に考えるタイミングだ。

このプラットフォームを使い続けるかどうか

私はSubstackを使い続ける。2026年2月の事件があってもだ。

理由は、これがSubstack固有の問題ではなく、インターネットインフラ共通の構造的問題だからだ。Substackから別のプラットフォームに移っても、同じリスクは別の形で必ずある。

そして、Substack側の対応は、悪くなかった。CEOが直接謝罪し、影響範囲を明示し、システム修正を完了させた。「絶対安全」を約束するのではなく、起きたことを率直に伝える対応だ。完璧ではないが、最低限の誠実さは保たれている。

リスクをゼロにする方法はない。リスクの存在を理解しながら、対策を取って使う、これがインターネット時代の標準だ。

書き手として求められているのは、「不安に駆られて逃げる」ことでも、「気にせず使い続ける」ことでもない。リスクを正しく理解し、できる対策を取り、読者にも適切に伝える。それが、メディアに関わる人間の責任だ。

私のクライアントには、上記の5つの対策を全部やってもらっている。あなたも今日、subscriber listのCSV export一つ、いますぐやっておくといい。次の漏洩が起きてから慌てて取り出すよりも、月に5分の習慣を作っておく方が、ずっと安いコストで済む。