Commune不正アクセス：約30.7万人漏えいの対象確認と共通署名鍵の教訓

コミュニティサービス「Commune」「Commune for Work」を運営するコミューン株式会社は2026年10月9日、10月5日からの不正アクセスで会員約30.7万人（推計）の情報が漏えいしたと公表しました。Sansan、スズキ、LINEヤフーなど、Communeでユーザーコミュニティを運営していた企業も相次いで影響を公表しています。本記事の前半は、自分は対象か、パスワードを変えるべきか、届いたメールを信じてよいかという会員の疑問への、公式発表に沿った回答です。後半では、利用企業の公表にある「全コミュニティ共通のログイン用の署名鍵」が何を意味するかを整理し、SaaSの開発者がテナントごとに鍵と権限を分ける実装をPythonのコードで示します。

まとめ：Commune不正アクセスで確定した事実と会員・利用企業・開発者の対応

確定しているのは、攻撃者が非公開コミュニティの招待リンクを不正に取得して一般会員として登録し、さらに管理者になりすまして会員情報を閲覧・取得し、データを上書きしたことです。コミューンは原因を「当社システムの不備」とし、契約企業の設定や運用によるものではないと明言しています。漏えいした情報の悪用や二次被害は、10月9日時点で確認されていません。

会員がまずやることは、利用していたコミュニティの運営企業からの個別連絡を確かめることです。パスワードの漏えいは確認されておらず、全員の変更は求められていません。開発者が受け取る教訓は1つです。署名鍵を全テナントで共有すると、1本の鍵の流出が全顧客の管理者権限に直結します。

会員が最初に確かめること：対象かどうか、パスワードの扱い、届いたメール

自分が対象かを確かめる方法と利用企業5社・団体が公表した人数

コミューンのお知らせは、コミュニティごとの人数を影響が確認された契約企業へ個別に案内するとしています。会員から見ると、自分が対象かどうかは、登録していたコミュニティの運営企業（ブランドや自治体）の公表と個別連絡で確かめることになります。下の表は、10月14日までに公表文を確認できた企業・団体の一部です。

出典はSansanの公表、スズキの公表、LINEヤフーの公表です。項目は企業ごとに違い、スズキはメールアドレス、ニックネーム、性別、年代、居住地（都道府県）、所有車名など7項目を挙げています。

パスワードを変更すべき144名と全会員の再ログイン、届くメールの見分け方

パスワードそのものの漏えいは確認されていません。ただし144名の会員は、本人の操作によらずパスワードが仮パスワードに変更されました。仮パスワードは失効済みで、対象者は再開後にログイン画面の「パスワードを忘れた場合」から再設定します。それ以外の会員も、安全のため一度ログアウトされた状態です。再開後にもう一度ログインすれば足ります。

注意したいのはメールです。漏えいした約12.6万人分の情報にはメールアドレスが含まれます。コミューンは、メールや電話でパスワード等を尋ねることは一切ないと明記しています。パスワードの入力や再登録をリンク先で求めるメールは、差出人がコミューンや運営企業を名乗っていても開かずに削除してください。同じパスワードを他のサービスで使っている人には、スズキが念のための変更を勧めています。

公式発表で追う経過：10月5日の侵入から10月16日以降の段階的な再開まで

10月5日18時の侵入から7日の再侵入と14時58分の遮断までの時系列

1. 10月5日18時頃：第三者による不正アクセスが始まる
2. 10月6日：検知し、通信遮断と防御措置を実施。21時頃に全コミュニティをメンテナンスモードへ切り替え
3. 10月7日13時17分〜14時36分：メンテナンス中に残っていた通信経路を悪用した不正な会員登録と閲覧が発生し、14時58分に遮断
4. 10月8日12時頃：社内検証コミュニティで安全性を確かめたうえで、再開を希望したコミュニティから順次再開
5. 10月9日：コミューンと利用企業が一斉に公表

見落とせないのは7日の再侵入です。全コミュニティを止めた後も、経路が1本残っていました。停止の判断と経路の洗い出しは別の作業だということを示しています。コミューンは対策として、攻撃に使われた不備の修正、ログイン用の署名鍵の更新、不正なIPアドレスからのアクセス拒否、攻撃者が作ったアカウントの退会処理と書き込みの除去を挙げています。データは10月6日18時時点の状態に巻き戻され、ダイレクトメッセージ、いいね・リアクション、新規登録は復元の対象外となる見込みです。

約30.7万人の内訳と不正アクセスを受けなかったCommune CRMなど5製品

約30.7万人のうち、メールアドレスを含む情報が漏えいしたのが約12.6万人で、ここにはコミューンの従業員とテスト用デモアカウントの合計約4.2万人が含まれます。残る約18.1万人は、表示名、自己紹介、非公開グループの所属など、メールアドレスを含まない情報です。人数は同一会員IDの重複と攻撃者が作ったアカウントを除いた推計で、調査の進展で変わる場合があるとされています。

同社の他製品のうち、Commune CRMとCommune Engageは不正アクセスを試みられたものの漏えいは起きていません。Commune Voice、Commune Navigator、Commune DataHubは不正アクセス自体を受けていないとしています。会員間のダイレクトメッセージの漏えいも確認されていません。

管理者なりすましの仕組み：全コミュニティ共通のログイン用署名鍵が意味すること

ちとせグループの10月13日更新で示された共通署名鍵と自動化された攻撃

コミューンのお知らせは「管理者になりすまして」と書くだけで、どうやってなりすましたかには触れていません。手がかりは利用企業側の公表にあります。ちとせグループの公表（10月13日更新）は、コミューンの調査結果として、攻撃者が同社の運営管理する全コミュニティ共通のログイン用の署名鍵を入手し、管理者になりすましていたと書いています。この経路は公開・非公開を問わず全コミュニティが対象になり得るものでした。攻撃は複数のIPアドレスから短時間に大量の操作を同時に行うもので、AI等で自動化された攻撃と推定されています。

渋谷未来デザインの公表も、管理者アカウント1件の不正利用が判明した後、委託先が該当アカウントの認証用鍵（トークン）を入れ替えたと説明しています。一方で、署名鍵をどこから入手したのか、署名の方式が何かは10月14日時点で公表されていません。本記事はこの2点を推測で補いません。

署名鍵1本で全テナントの管理者になれる構造とテナント境界の崩れ方

ログイン用の署名鍵は、サーバーが「このログイン状態は自分が発行したものだ」と確かめるための鍵です。代表的な実装であるJWT（JSON Web Token）では、利用者のIDや権限を書いた本文に署名を付け、サーバーは署名が合えば中身を信用します。署名鍵を持つ者は、任意の利用者、任意の権限を名乗る正しい署名つきのログイン状態を作れることになります。

鍵が全コミュニティ共通なら、被害は1社にとどまりません。A社のコミュニティでもB社のコミュニティでも同じ鍵で署名が通るため、テナントの境界は鍵の上では存在しないのと同じです。さらに権限の判定を署名つきの本文に書かれた値だけで行っていれば、管理者を名乗るだけで会員一覧に届きます。ちとせグループの公表にある「会員一覧（メールアドレスを含む）を閲覧・取得された可能性」は、この管理者権限の画面を通った結果と読むのが自然です。認可の判定をサーバー側に置く考え方は認可バイパスの仕組みと対策で詳しく扱っています。

マルチテナントSaaSの実装手順：テナント別の署名鍵とaud照合、権限のサーバー側参照

署名鍵をテナントごとに分けkidとaudで照合するPythonの検証コード

JWTの実装指針であるRFC 8725（BCP 225）は、3.8節でJWTの暗号操作に使われた鍵が発行者に属することを検証するよう求め、3.9節で受け手がaud（対象者）を必ず検証するよう定めています。3.1節の要求は、使うアルゴリズムを呼び出し側で固定することです。これをマルチテナントに当てはめると、次の3点になります。鍵をテナントごとに分け、どのテナント宛てかをaudで照合し、権限はトークンでなくサーバー側の会員台帳で引く。

# テナントごとの署名鍵・aud照合・権限のサーバー側参照を確かめる最小例（Python 3.9以上・標準ライブラリのみ）
import base64, hashlib, hmac, json, secrets, time

ISSUER = "https://auth.example.com"
# 鍵はテナントごとに別。本番はKMSやシークレット管理から読み、コードや設定ファイルに置かない
KEYS = {"tenant-a": {"a-2026-10": secrets.token_bytes(32)},
        "tenant-b": {"b-2026-10": secrets.token_bytes(32)}}
# 権限はトークンではなくサーバー側の会員台帳で引く
MEMBERS = {("tenant-a", "u100"): "admin", ("tenant-b", "u200"): "member"}

def b64(data: bytes) -> str:
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def unb64(s: str) -> bytes:
    return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4))

def sign(header: dict, claims: dict, key: bytes) -> str:
    head = b64(json.dumps(header).encode()) + "." + b64(json.dumps(claims).encode())
    return head + "." + b64(hmac.new(key, head.encode(), hashlib.sha256).digest())

def issue(tenant: str, user: str) -> str:
    kid, key = next(iter(KEYS[tenant].items()))
    now = int(time.time())
    claims = {"iss": ISSUER, "aud": f"community:{tenant}", "sub": user, "iat": now, "exp": now + 900}
    return sign({"alg": "HS256", "typ": "JWT", "kid": kid}, claims, key)

def verify(token: str, tenant: str) -> dict:
    """tenantはトークンではなくリクエスト先（サブドメインやパス）から決める"""
    head, body, sig = token.split(".")
    header = json.loads(unb64(head))
    if header.get("alg") != "HS256":
        raise PermissionError("想定外のalg")
    key = KEYS[tenant].get(header.get("kid"))  # このテナントの鍵だけを候補にする
    if key is None:
        raise PermissionError("このテナントの鍵ではない")
    expected = hmac.new(key, f"{head}.{body}".encode(), hashlib.sha256).digest()
    if not hmac.compare_digest(expected, unb64(sig)):
        raise PermissionError("署名不一致")
    claims = json.loads(unb64(body))
    if claims.get("iss") != ISSUER or claims.get("aud") != f"community:{tenant}":
        raise PermissionError("iss/aud不一致")
    if claims.get("exp", 0) < time.time():
        raise PermissionError("期限切れ")
    role = MEMBERS.get((tenant, claims["sub"]))
    if role is None:
        raise PermissionError("このテナントの会員ではない")
    return {"sub": claims["sub"], "role": role}

def attempt(label: str, token: str, tenant: str) -> None:
    try:
        print(f"{label}: 許可 {verify(token, tenant)}")
    except PermissionError as e:
        print(f"{label}: 拒否（{e}）")

if __name__ == "__main__":
    attempt("1 正規の会員", issue("tenant-b", "u200"), "tenant-b")
    attempt("2 Aの管理者トークンをBで提示", issue("tenant-a", "u100"), "tenant-b")
    # Aの鍵を入手した攻撃者が、BのaudとroleをつけてAの鍵で署名した場合
    kid_a, key_a = next(iter(KEYS["tenant-a"].items()))
    now = int(time.time())
    forged = {"iss": ISSUER, "aud": "community:tenant-b", "sub": "u200", "role": "admin", "iat": now, "exp": now + 900}
    attempt("3 Aの鍵で偽造したBの管理者", sign({"alg": "HS256", "kid": kid_a}, forged, key_a), "tenant-b")
    attempt("4 kidだけBに書き換えた偽造", sign({"alg": "HS256", "kid": "b-2026-10"}, forged, key_a), "tenant-b")

要はverifyの引数tenantです。どのテナントの鍵で検証するかを、トークンに書かれた値ではなくリクエスト先のサブドメインやパスから決めます。RFC 7515が定めるkidヘッダは鍵を選ぶための目印にすぎず、署名前の値なので信用しません。このテナントの鍵の中に無いkidは、その時点で拒否します。署名の比較には、処理時間から値を推測されないようhmac.compare_digestを使います。

4ケースの実行結果と本番でPyJWTに置き換えるときに渡す引数

Python 3.14.6（Windows）でpython tenant_token.pyを実行した結果です。鍵は実行のたびにsecretsで生成するため、値は毎回変わりますが判定は同じです。

1 正規の会員: 許可 {'sub': 'u200', 'role': 'member'}
2 Aの管理者トークンをBで提示: 拒否（このテナントの鍵ではない）
3 Aの鍵で偽造したBの管理者: 拒否（このテナントの鍵ではない）
4 kidだけBに書き換えた偽造: 拒否（署名不一致）

3の偽造トークンは本文に"role": "admin"を書いていますが、仮にB社の鍵まで盗まれて署名が通ったとしても、返る権限は会員台帳のmemberです。鍵を分けることでA社の鍵の流出はA社の中に閉じ、権限をサーバー側で引くことで、署名が通っても管理者には上がれません。共通鍵と、トークン本文の権限をそのまま信じる実装が重なると、この2つの防壁が両方とも無くなります。

上の例は仕組みを見せるための最小構成です。本番では検証済みのライブラリを使ってください。PyJWTの使い方に沿うなら、jwt.get_unverified_header()でkidを読み、リクエスト先テナントの鍵の中から選んだうえで、jwt.decode()にalgorithms=["HS256"]、audience、issuer、options={"require": ["exp", "iss", "sub", "aud"]}を渡します。audやissが合わなければInvalidAudienceErrorやInvalidIssuerErrorが送出されます。

鍵の保管とローテーション、漏えいの疑いで全セッションを失効させる手順

テナント別の鍵は、アプリのサーバーに平文で置かず、AWS KMSのような鍵管理サービスやシークレット管理から読み込みます。kidに年月を入れておくと、新しい鍵で発行を始め、古い鍵は有効期限ぶん検証だけ続けてから外す、という入れ替えが可能です。漏えいの疑いが出たときは、該当テナントの古いkidを即座に外せば、そのテナントのログイン状態だけを無効にできます。

コミューンは今回、署名鍵を更新し、全会員を一度ログアウトさせました。鍵が全テナント共通だったなら、鍵の更新は全テナントのログイン状態の失効と同じ意味になります。テナント別の鍵なら、止める範囲は被害を受けたテナントだけです。失効の手順を含むログイン状態の設計はセッション管理の実装と保存先の選び方にまとめています。

利用企業の判断：外部コミュニティSaaSを使い続ける条件と個人情報の報告主体

コミュニティSaaSの選定で事業者に確かめる鍵の分離と監査ログの4項目

今回、会員から見た運営者は利用企業であり、公表も個別連絡も利用企業の名前で出ています。外部のコミュニティSaaSを使い続けるなら、契約前と更新時に次の4点を事業者へ書面で確かめます。

• ログイン用の署名鍵や暗号鍵がテナントごとに分かれているか
• 管理者権限での会員一覧の閲覧・エクスポートが監査ログに残り、利用企業が取り出せるか
• 管理者アカウントに多要素認証やIPアドレス制限を掛けられるか
• 停止時に残る経路（API・招待リンク・会員登録）も含めて止める手順があるか

判断は言い切れます。1つ目に「全テナント共通」と答える事業者には、メールアドレスを含む会員名簿を預けません。名簿を持たない匿名の掲示板的な使い方に限るなら、そこまで求めるのは過剰です。7日の再侵入が示すとおり、4つ目は停止と再開を事業者任せにしないための項目です。SaaS全般の設定診断や連携アプリの棚卸しはSaaSセキュリティ対策の実装手順で扱っています。

個人情報保護委員会への報告は契約企業側：速報3〜5日の起点と委託先の通知

個人情報保護法26条1項のただし書は、委託を受けた事業者が委託元に事態を通知したときは、委託先の報告義務を外しています。コミューンは電気通信事業者として総務省に報告するとしたうえで、契約企業が個人情報保護委員会へ報告するために必要な情報を提供していると書いています。会員名簿の報告主体は、コミュニティを運営する契約企業です。実際にSansanは、10月7日に速報を受け取り、9日に委員会へ報告しています。

個人情報保護委員会の案内では、速報は事態を知った日から3〜5日以内、確報は30日以内、不正の目的によるおそれがある場合は60日以内です。今回のように委託先の通知で事態を知る場合、起点は通知を受けた日です。報告の段取りは個人情報保護委員会への報告義務の実務で解説しています。自社でSaaSを運営する立場なら、テナント分離と認証の設計、管理者機能の認可を第三者の目で確かめる脆弱性診断・セキュリティ診断で点検できます。

よくある質問

Commune（コミューン）の不正アクセスについて、会員と利用企業の担当者から出やすい質問をまとめました。

Communeの不正アクセスで漏えいした情報は何ですか？

コミューンの公表では、約12.6万人分はメールアドレスを含む情報、約18.1万人分は表示名、自己紹介、非公開グループの所属などメールアドレスを含まない情報です。項目はコミュニティと会員によって異なり、スズキは性別や年代、所有車名、LINEヤフーは氏名やポイントも挙げています。パスワード、ダイレクトメッセージの漏えいは確認されておらず、決済情報はコミューンが保持していません。

自分が対象かどうかはどこで確認できますか？

コミューンはコミュニティごとの人数を契約企業へ個別に案内するとしているため、登録していたコミュニティの運営企業の公表と、運営企業から届く個別連絡で確認します。Sansanのように全会員へメールで通知した企業もあります。運営企業の公式サイトにお知らせが無い場合は、同社の窓口へ問い合わせてください。

パスワードは変更したほうがよいですか？

パスワード自体の漏えいは確認されていないため、全員に変更は求められていません。仮パスワードに変えられた144名は、再開後に「パスワードを忘れた場合」から再設定が必要です。同じパスワードを他のサービスでも使っている場合は、スズキが勧めるとおり、他のサービス側を変更しておくと安心です。

コミューンや運営企業を名乗るメールは本物ですか？

本物の連絡も届きますが、見分ける基準ははっきりしています。コミューンはメールや電話でパスワード等を尋ねることは一切ないと明記しています。パスワードやカード番号の入力を求めるメール、SMSはリンクを開かずに削除してください。真偽を確かめたいときは、メール内のリンクではなく運営企業の公式サイトのお知らせから窓口をたどります。

Communeのコミュニティはいつ再開しますか？

コミューンは10月8日12時頃から、再開を希望したコミュニティを順次再開しています。ちとせグループの10月13日更新によると、10月15日に機能制限の詳細が管理者へ案内され、16日以降に申請順で一部機能を制限した暫定再開が始まる予定です。制限が外れる本復旧の時期は未定で、再開日はコミュニティごとに運営企業が判断します。

関連記事

• JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説：署名鍵で守られるログイン状態の仕組み
• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説：管理者になりすました後に権限が通ってしまう原因
• 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：利用企業として点検する範囲の全体像
• Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：SaaS側の不備で利用者の情報が出た別の事例
• タイムズカー情報漏洩・流出：自分が対象かの確認と補償、0120-25-8924は本物か：漏えい後に届く連絡の真偽を確かめる手順
• skyticket不正アクセス：1,464万件流出の対象確認と本物メールの見分け方：同じ週に公表された予約サイトの流出事例
• ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方：同じ週に公表された会員管理システムの漏えい事例