TITLE

GitBookで不正アクセス、トークン漏えいの可能性 ― 利用企業が今すぐ確認すべきこと

投稿日：2026.11.04

経緯 ― 検知から公表、復旧まで1日足らず

GitBookの発表によれば、11月2日19:00(CET)ごろに攻撃者がインフラの一部認証情報へ不正アクセスし、GitBookは直後にこれを検知して攻撃者を遮断、関連する脆弱性を解消しました。その上でインフラ上の全認証情報・シークレットを入れ替え、全顧客のAPIトークンを無効化、個人用APIトークンも取り消しています。安全性を確認するまでアプリと認証付きドキュメントサイトは一時停止されましたが、公開済みのコンテンツはキャッシュにより公開が維持されました。

この対応の経過が公式に告知されたのが11月3日13:15(CET)、そしてアプリ・API・公開ドキュメントが復旧したのが同日16:21(CET)です。発生から公表、復旧までが1日足らずに収まっている一方、詳細なポストモーテム(事後報告書)はまだ公開されておらず、「近日公開予定」とされています。

影響を受けた可能性があるもの ― コンテンツでなく「鍵」

GitBookの調査で「アクセスされた可能性がある」とされているのは、インテグレーションのトークン、Git Syncのシークレット、GitBook APIトークン、外部ツール連携用のサードパーティAPIトークン、そしてサイト訪問者がGitBook Assistant(AIチャット機能)に投げた質問内容です。一方で、コンテンツが改ざんされた証拠は見つかっていません。

見られた可能性があるのは、ドキュメントの中身そのものではなく、GitBookと外部サービスを出入りする「鍵」にあたる情報だという点が、この事案の影響範囲を理解する出発点になります。トークンが流出していれば、その鍵を使って別のサービスへ不正にアクセスされる経路が開きます。

利用者が今すぐ確認すべきこと

GitBookが利用者に呼びかけている対応は、次の5点です。

GitBook APIトークンのローテーション ― 既存のAPIトークンを入れ替える。
連携先の第三者トークン・シークレットのローテーション ― GitBookに接続している外部サービスのAPIトークン・シークレットも、あわせて入れ替える。
公開インテグレーションのシークレット確認 ― 公開インテグレーションでシークレットを使っている場合も、同じくローテーションする。
GitBook MCPサーバーの再認証 ― AIエージェントからGitBookへ接続する際に使うMCPサーバーを利用している場合は、再認証を行う。
組織の管理者への作業依頼 ― 上記の対応を組織の管理者に依頼する。

挿絵(L1ライトフラット): ノートPCでAPIトークンの文字列を入れ替える(ローテーションする)手元の操作シーン。

GitBookが行ったのは、インフラ側のトークン・シークレットの入れ替えと、既存APIトークンの無効化までです。無効化した先の新しいトークンの発行や、連携先に登録し直す作業は利用者の手に残ります。「サービス側が対応したから大丈夫」ではなく、自社が発行・保存している側のトークンを自分で入れ替える作業が別に残ります。

「AIエージェントによる攻撃」という説明をどう読むか

GitBook公式は、今回の侵入を「AIエージェントを使った、高度で標的を絞った攻撃」と説明しています。ただし、この「AIエージェントによる」という説明の技術的根拠は公式発表の中に示されていません。Hacker Newsのスレッドでは、ステータスページの概要に当初不正アクセスの記載が無かった点や、AIエージェント攻撃という説明の根拠が不明な点を指摘する声が出ており、GitBookのCTOがこのスレッドにコメントし、詳細はポストモーテムで公開するとしています。

確認できているのはタイムラインと影響範囲、GitBookが取った対応までで、侵入の手口が実際にどのようなものだったかは、まだ検証可能な形で公開されていません。「AIエージェントによる攻撃」という言葉は印象的ですが、それが事実かどうかを確かめる前に、まず確認済みの事実(トークンがアクセスされた可能性)に沿って手を動かす方が、今回は理にかなっています。トークンのローテーションという対応の必要性は、攻撃者の手口が何であったかとは関係なく、すでに確定しているからです。

文書SaaSを使う企業が見直す運用のポイント

今回の事案はGitBook固有の話ですが、ドキュメント作成・公開SaaSや類似のナレッジベースツールを業務で使っている以上、自社が同じ立場で通知を受け取る可能性は契約先を問わず残ります。

接続しているSaaSへ渡しているトークン・シークレットを棚卸しする ― 自社がどのツールに、どの権限のトークンを渡しているかを一覧化しておく。
ローテーション手順を事前に用意する ― 緊急時に誰がどのトークンを、どの順で入れ替えるかを決めておく。決まっていなければ、通知を受けてから手順を考えることになる。
ベンダーのステータスページ・告知の監視体制を作る ― 段階的に情報が更新される事案では、最新の発表を見落とさない担当者を決めておく。
MCPサーバー等のエージェント連携の認証情報も対象に含める ― AIエージェントからSaaSへ接続する経路が増えている分、トークン棚卸しの対象をドキュメントツール本体だけに絞らない。

まとめ

今回の事案が示しているのは、対応を「手口の解明を待つもの」と「待たずに動かせるもの」に最初に分けるという判断基準です。ポストモーテムの公開を待つ必要があるのは「何が起きたか」の解明であって、「トークンを入れ替えるかどうか」の判断ではありません。自社がGitBookや類似のドキュメントSaaSに渡しているトークン・シークレットの一覧を作り、連携先ごとに入れ替えの優先順位を付け、緊急時の手順をあらかじめ文書化しておく ― この一式は、次に同じような通知が届くのを待たず、今回の事案を使って今試すことができます。