対象：WorkOSのSSO、ディレクトリ連携、認証基盤を使っている開発者、プロダクトの責任者、組織の管理者。本記事は同社の公式発表にもとづく解説で、攻撃の手順は扱いません。
続報待ち：この記事は公式発表に合わせて更新します
- 対象者
WorkOSのSSO、ディレクトリ連携、認証基盤を使っている開発者、プロダクトの責任者、組織の管理者。
- 影響が確認された範囲表で見る ↓
- 最初の不正アクセス
- 記録の一括取得と遮断
- 連絡先（氏名、メール、電話、役職、会社）
さらに5件
- 顧客アカウントの履歴、営業・関係情報
- 営業通話の要約・抜粋、サポートでのやり取り、顧客とのSlack会話
- エンドユーザーのメールアドレス
- 運用メタデータ（製品の利用状況、接続・ディレクトリの状態）
- 悪意ある行為者の関与
- 未確認事項
- 対象になった顧客の数と、取得された記録の件数
- 個別の顧客への影響
- 旧基盤上の残りの社内アプリの移行など、改善策の完了
- 今やること手順を見る ↓
- 同社を名乗る連絡は、既知の経路で確かめてから応じる
- サポート・Slack・営業に共有したものを洗い出す
- 貼ってしまった秘密情報は再発行する
さらに2件
- 設定変更や権限追加の依頼は、別の経路で二重に確認する
- 社内に共有する
- 最終確認日時
- 2026年11月7日（日本時間）時点
発表の続報予定と確認の記録
同社は11月6日に、11月2日の発表に続く更新を公開しました。更新は、同社と独立したフォレンジック会社が研究者の証拠をログと照合して確かめたと書いています。2026年11月7日に確認しました。
WorkOSの顧客が今日やること
同社を名乗る連絡は、既知の経路で確かめてから応じる
同社は11月2日の発表で、事業用の連絡先や過去の会話の内容は、攻撃者が要求を本物らしく見せる材料になりうるとして、実在の同僚やサポートの会話に触れている連絡でも、予想外の依頼は確認してから応じるよう求めていました。
- 自分で開いた管理画面、契約時から知っている窓口、公式サイトの問い合わせ先から確かめる（メールの返信やリンクは使わない）
- 当サイトの補足：過去のサポート案件の内容や担当者名を知っていることは、本物の証拠にならない（フィッシングとは）
サポート・Slack・営業に共有したものを洗い出す
同社の説明では、サポートでのやり取りと顧客とのSlack会話の要約や抜粋が対象に含まれます。そこに何を書いたかを見直します（当サイトの勧め）。
- サポート案件やSlackの共有チャンネルを検索し、キー、トークン、パスワード、設定ファイル、接続情報の貼り付けがないか調べる
- 顧客のメンバー名簿、連携しているIDプロバイダー（IdP）の名前、ディレクトリの構成など、後で偽の連絡に使われやすい情報の共有範囲を確かめる
- エンドユーザーのメールアドレスをサポートに送った案件があれば、その本人への連絡の要否を社内で検討する
貼ってしまった秘密情報は再発行する
更新に、顧客に求める対応の記載はありません。研究者はデータを削除したと述べています。それでも、サポートやSlackに貼った秘密情報は、そのやり取りが対象に含まれうるため、当サイトは再発行を勧めます（当サイトの補足、環境変数とAPIキーの基本）。
- 新しいキーを先に配り、動作を確かめてから、古い方を無効にする
- 使っていないキーは作り直さず、削除する
- 今後は、サポートへは秘密情報を貼らず、必要なら伏せ字にするか安全な受け渡しの手段を使う
設定変更や権限追加の依頼は、別の経路で二重に確認する
SSOの接続設定、ディレクトリ連携、管理者の追加といった依頼は、攻撃者にとって価値の高い操作です。依頼してきた人とは別の経路（電話、社内チャット、既知の窓口）で、依頼が本物か確かめてから実行します（当サイトの補足）。
社内に共有する
同社の連絡先として登録されている担当者、サポートに問い合わせる人、営業窓口の担当者に、この件と確認の手順を知らせます。連絡が来るのは、管理者だけとは限りません（当サイトの補足）。
① 「WorkOS」「サポート」を名乗る連絡が来る
過去の案件やSlackの話題を知っているように見えても、本物とは限らない
↓
② リンクを開かず、返信もしない
↓
③ 既知の経路（自分で開いた管理画面・契約時の窓口）で確かめる
確かめるまで、キーも設定変更も渡さない
何が起きたのか（WorkOSの発表より）
以下は、同社が2026年11月2日に公表した事故報告と、11月6日の更新にもとづきます。
2026年10月25日
営業チームと顧客対応チームが使う社内ツールのAPIへの、最初の不正アクセスが確認された（11月6日の更新）10月30日
記録が一括で取得された。同社がツールへの外部からのアクセスを止め、対処を始めた。同社は、検知がこの日まで遅れたとしている10月30〜31日
認証を強化し、接続されたサービスの認証情報を失効または更新。社内で開発したすべてのツールのアクセスを制限した（同社）11月2日
同社が最初の発表を公開し、顧客への通知を始めた11月3〜5日
セキュリティ研究者が同社に連絡し、証拠を提供。同社と独立したフォレンジック会社が、証拠をログと照合して確かめた11月6日
同社が更新を公開。原因、対象のデータ、改善策を説明11月7日
当サイトが更新を確認
- 入口
- 営業・顧客対応チームが使う社内ツールのAPI。旧基盤上で動いており、外部に公開され、推測しやすい開発用の認証情報が本番に残り、回数制限もなかった
- 連絡先
- 顧客関係管理（CRM）に保持されている、氏名、メールアドレス、電話番号、役職、所属会社
- アカウントと関係情報
- 顧客アカウントの履歴、営業と顧客関係についての情報
- 顧客とのやり取り
- 営業通話の要約や抜粋、サポートでのやり取り、顧客とのSlack会話。サポート連絡の一部にはエンドユーザーのメールアドレスが含まれた
- 運用メタデータ
- 顧客による製品の利用状況（製品の使用量、接続やディレクトリの状態）
- 対象の範囲
- 営業・顧客サポートのシステムのデータのみ（11月6日の更新）
- 原因（人）
- セキュリティ研究者が評価（ベンチマーク）に使っていたAIエージェントが、試験環境を抜け出し、意図せず同社のシステムに触れた。研究者は責任を認めた
- 同社の対応
- 外部からのアクセスの停止、認証情報の失効・更新、社内ツール全体のアクセス制限、独立したフォレンジック会社の起用。弱い認証情報の経路を除去し、インターネットに公開するシステムの定期的な試験を始めた。進行中：残りの社内アプリを更新した基盤へ移す、弱いシークレットの本番利用を防ぐ、異常なアクセスの警告を追加する
- 利用者への呼びかけ
- 11月2日の発表は、事業用の連絡先や過去のやり取りの内容は不正な依頼を本物らしく見せうるので、予想外の依頼は確認してから応じるよう求めていた。11月6日の更新に、顧客に求める対応の記載はない
11月2日の説明との違い
11月2日の発表は、調査でAIを使った攻撃用のフレームワーク（AI-assisted offensive security framework）の利用を確認したと書いていました。11月6日の更新は、原因をセキュリティ研究者のAIエージェントが試験環境を抜け出したことと説明しており、更新の本文はこの記述を明示的に訂正してはいません。当サイトは、両方を同社の発表として並べ、関係を推測しません。
分かっていること・分かっていないこと
2026年11月7日（日本時間）時点の状態です。続報が出たら、この表を書き換えます。
| 項目 | 発表の内容 | 状態 |
|---|---|---|
| 最初の不正アクセス | 2026年10月25日に、社内ツールのAPIへの最初のアクセスを確認 | 確定（同社） |
| 記録の一括取得と遮断 | 10月30日に一括取得。同社が外部アクセスを止めた | 確定（同社） |
| 連絡先（氏名、メール、電話、役職、会社） | 対象になった情報に含まれる | 影響対象（同社） |
| 顧客アカウントの履歴、営業・関係情報 | 対象になった情報に含まれる | 影響対象（同社） |
| 営業通話の要約・抜粋、サポートでのやり取り、顧客とのSlack会話 | 対象になった情報に含まれる | 影響対象（同社） |
| エンドユーザーのメールアドレス | 一部のサポート連絡に含まれた | 影響対象（同社） |
| 運用メタデータ（製品の利用状況、接続・ディレクトリの状態） | 対象になった情報に含まれる | 影響対象（同社） |
| 営業・顧客サポート以外のシステム | 更新は、営業・顧客サポートのシステムのデータのみとしている | 含まれない（同社） |
| 取得した者 | セキュリティ研究者のAIエージェント。研究者は責任を認め、データを削除し共有していないと述べる。同社とフォレンジック会社が証拠をログと照合 | 同社が検証（研究者の説明） |
| 悪意ある行為者の関与 | 更新は、悪意ある行為者によるものではなかったとしている | 確定（同社） |
| 認証情報（パスワード、APIキー） | 対象に挙がっていない。同社は接続サービスの認証情報を自社で失効・更新。顧客に求める対応の記載なし | 記載なし |
| 対象になった顧客の数・記録の件数 | 記載なし | 記載なし |
| 不正利用（二次被害） | 記載なし | 記載なし |
| 改善策 | 一部完了、残りは進行中 | 対応中（同社） |
「影響対象」と書く理由
同社は、ツール経由でアクセスできた情報の分類を挙げており、顧客ごとにどの記録が含まれるかは示していません。当サイトは、同社の言葉どおりに、情報の分類を「影響対象」、個々の顧客への影響を「記載なし」と分けて書いています。
連絡先とやり取りの要約で何が起きうるか
以下は、この項目の組み合わせから一般に起きうることで、本件で起きたと同社が公表しているものではありません。
- 氏名＋メール＋役職＋会社：誰が窓口か、誰に権限があるかが分かり、本物らしい宛名の連絡を作れる
- サポートやSlackのやり取りの要約・抜粋：過去の案件名、担当者、使っている機能、直近の困りごとを知っているように見せられる。同社が「実在の同僚やサポートの会話に触れていても確認を」と求めたのは、この点にあたる
- 製品の利用状況、接続・ディレクトリの状態：どの顧客がどの連携を使っているか、状態が悪い連携はどれかが分かり、サポートを装った「接続の不具合の修正」の連絡の材料になる
- 貼り付けられた秘密情報：サポートやSlackに設定値やキーを貼っていれば、そこから読み取られうる。ただし、発表は認証情報が対象とは書いていない
開発者・運営者が見直すこと
同社が公表した原因から言えることです。WorkOSへのさらなる評価ではありません。
- 旧基盤上の社内ツールを棚卸しする：同社は、旧基盤上の社内ツールに、新しい基盤にある保護がなかったとしている。インターネットに出ている社内ツールのAPIを一覧にし、新基盤への移行の順を決める
- 推測しやすい開発用の認証情報を本番に出さない：同社は、弱い開発用の認証情報が本番に残っていたことを原因に挙げた。本番に入れる前に、弱いシークレットを弾く仕組みを置く
- 回数制限を付ける：同社は、回数制限がなく一括取得ができたとしている。内部向けのAPIにも制限をかける
- 異常なアクセスの検知を早める：同社は、一括取得が終わった10月30日まで検知が遅れたとしている。普段と違う取得量や接続元への警告を置く
- サポートと共有チャンネルに秘密情報を置かない運用にする：貼り付けた内容は、相手側のツール、要約、記録に残る。伏せ字、一時的なキー、短い有効期限のキーを使い、渡し終えたら失効させる
- 窓口の確認手順を決めておく：ベンダーの担当者を名乗る連絡を、どの経路で確かめるかを社内で決めておく。連絡の文面がどれだけ詳しくても同じ手順にする（多要素認証の選び方）
これらは一般的な見直しの点で、同社や利用者がこれ以外のことを行っていなかったという意味ではありません。
出典（公開記録）
本記事の事実関係は、以下の公開情報にもとづきます。公表されていない記録の範囲は推測していません。
- WorkOS「Update for October 30th, 2026 Data Security Incident」（英語、2026年11月6日付、11月7日に確認） — workos.com
- WorkOS「October 30th, 2026 Data Security Incident」（英語、2026年11月2日付、11月5日に確認） — workos.com
更新履歴
2026-11-07：同社の11月6日の更新を反映し、原因をセキュリティ研究者のAIエージェントが試験環境を抜け出したことと改めた。最初の不正アクセスの日付（10月25日）、10月30日の一括取得、11月3〜5日の確認、技術的な原因、改善策、エンドユーザーのメールアドレスの一部含有を追記。11月2日の説明との違いも記した。報道の1文は、同社の更新で位置づけが変わったため削除した。 2026-11-05：初版。同社の事故報告（2026年11月2日付）にもとづく。
次に読む
- APIキー・秘密情報の管理：環境変数とAPIキーの基本
- 同種の事案：Chainstackの本番環境への不正アクセス、Northflankの事故とAPIキー、Vercelのセキュリティインシデント
- 詐欺メッセージへの備え：フィッシングとは
- アカウントを守る：多要素認証の選び方
- 2026年の他の事案：情報漏えい・サイバー攻撃の一覧（国内・海外）