GROWIの閲覧権限を越える認可不備｜更新後も下書きとコピー先を点検

GROWIを運用している場合は、v8.0.7以降への更新と、保存前の編集下書きの確認を進めてください。2026年10月27日に開発元とJVNが公表した3件の認可不備では、閲覧権限のないページの本文やコメントを取得される可能性に加え、閲覧のみのユーザーなどに下書きを書き換えられる可能性があります。

特に共同編集の問題は、ゲストが直接ページを保存できないことだけでは防げません。変更された下書きを正規ユーザーが後から保存すると、そのユーザーの名前で履歴へ残るためです。更新による攻撃経路の修正と、すでに存在する下書きや履歴の点検を分けて対応します。

本稿は当日公表された勧告に基づくニュースと運用上の対応解説です。実環境での悪用や自社環境の侵害を確認したという意味ではありません。以下では開発元が示す影響条件と、本サイトが提案する点検手順を区別します。

3件の影響版と修正版を先に確認する

GROWI公式の脆弱性対応告知とJVN#51223238は、いずれも3件をv8.0.7で修正したとしています。影響が始まる版は機能によって異なるため、共同編集を使わないという理由だけで全件を対象外にしないでください。

CVE-2026-105272はページ表示・コメント機能の認可回避で、JVNと開発元のまとめではv3.2.10からv8.0.6が対象です。詳細勧告では本文取得の経路はv3.3.0から、コメント取得の経路は少なくともv3.2.10から影響すると説明されています。製品全体の対象範囲と個別経路の導入版を混同しないことが必要です。

CVE-2026-109848はタグ更新APIとページ更新APIの認可回避で、v4.5.5からv8.0.6が対象です。CVE-2026-115624は同時編集機能の認可欠如で、v7.0.0からv8.0.6が対象です。どちらもv8.0.7で修正されています。現行版の確認では構成管理上の予定値だけでなく、実際に起動しているアプリの版まで照合してください。

読めるページのIDだけ確認しても不十分だった

ページ表示・コメント機能の開発元勧告によると、一部の読み取り経路はリクエスト内のページIDに対する閲覧権限を確認する一方、指定されたリビジョンがそのページに属するかを確認していませんでした。攻撃者はログインでき、対象のリビジョンIDを知る必要があります。

その条件を満たすと、自分が閲覧できるページと、閲覧できないページのリビジョンを組み合わせて、別の版の本文やコメントへ到達できる可能性がありました。読み取り専用ユーザーも対象となる読み取り経路です。共有リンク経由のアクセスはこの問題の影響を受けないと詳細勧告は説明しています。

IDを知られなければよいという対策にはできません。開発元はリビジョンIDがMongoDB ObjectIdであり、秘密として設計された値ではないことを示しています。ここで優先するべきなのはIDの隠蔽ではなく、アクセス可能なページと取得対象のリビジョンの所属をサーバー側で結び付けて検証する修正の適用です。

修正版では、本文とコメントの読み取りで別ページのリビジョンをそのまま利用せず、そのページ自身の最新の版やコメントへ戻す扱いになります。一方、コメントを他ページの版に結び付ける書き込み経路は拒否する扱いです。更新後の確認は一律にエラー応答だけを期待せず、経路ごとの修正仕様に合わせます。

コピー先と通知先まで調査対象に含める

タグ更新・ページ更新APIの勧告では、ログイン済みで読み取り専用ではないユーザーが、閲覧できないリビジョンの本文を自分のアクセス可能なページへ保存できる問題が説明されています。これも対象リビジョンIDの把握が前提です。

問題は、その場で本文を読まれるだけではありません。コピーされた本文が新しいリビジョンとして別ページへ残ると、元ページの権限を見直してもコピー先の露出が残り得ます。運用上の点検では、機密ページの設定だけでなく、意図しない内容へ置き換わったページや不自然な新しい版を探す必要があります。

詳細勧告は、ページ更新APIの特定経路で別の版が差分計算へ使われ、条件がそろうとSlack更新通知の差分にも利用されることを説明しています。通知連携が有効な環境では、ページ内の履歴だけで調査を終えず、関連する通知先へ機密情報が出ていないかも対象期間を絞って確認することを本サイトは勧めます。

ただし、この問題だけからすべてのSlack通知が漏えいしたとは判断できません。利用していた更新経路、連携設定、対象ページ、通知の実物を確認します。通知先を一括削除する前に調査に必要な記録を保全し、関係者以外へ本文を再共有しない方法で内容を照合してください。

ゲスト拒否でもログイン済みの閲覧ユーザーは残る

同時編集機能の開発元勧告は、Yjsによる共同編集接続で閲覧可否だけを確認し、編集権限を確認していなかったと説明しています。ページを閲覧できる読み取り専用ユーザーや、承認待ち・停止中・招待中のユーザーも影響条件に含まれます。

未ログインのゲストについては、ゲストアクセスが閲覧のみでページを公開している場合に下書きを変更できる可能性があります。管理画面の/admin/securityでゲストアクセスを拒否にすると、この未ログイン経路を防げます。しかし、ページを閲覧できるログイン済みの読み取り専用ユーザーや非アクティブなユーザーへの対策を完了するものではありません。

ユーザー登録を無効にすることも未ログインの経路の緩和にはなりません。攻撃者が登録やログインを必要としない条件だからです。登録設定、ログイン状態、ページの閲覧権限、編集権限を別々の軸として棚卸しし、「外部登録を止めているので影響なし」という判断を避けてください。

修正版の共同編集接続は、閲覧権限に加え、ページ更新APIと同様にログイン済みのアクティブユーザーで読み取り専用ではないことを確認します。既存の業務アカウントで閲覧と編集が正しく分かれているかを確認することが、更新後の重要な検証項目です。

保存前の下書き点検を更新作業に組み込む

開発元は、影響を受けるサイトの管理者に対し、公開閲覧可能なページの編集下書きを保存する前に確認するよう求めています。ゲストはページ更新APIで直接リビジョンを保存できませんが、共同編集で変更された内容は下書きとして残り、正規ユーザーの保存によって履歴へ入るためです。

本サイトの提案は、まず利用者へ、確認していない下書きをそのまま保存しないよう周知することです。更新前後の作業で一律に全ページを開いて保存する運用は避けます。既存の正しい本文や過去の版と差分を比較し、不審な変更があれば作業を止め、対象ページ・時刻・確認者を記録します。

履歴の保存者が正規の社員でも、その人が変更内容を作成したとは限りません。今回の問題では、後から保存した人の名前で履歴が残り得ることが明示されています。監査では保存者を直ちに攻撃者と決めつけず、共同編集の利用状況と、本人が確認した差分を照合してください。

下書きが正しいかを確認するために機密ページの本文を無制限にエクスポートすると、別の漏えい経路を作ります。点検権限を限定し、記録には必要な識別情報を中心に残し、本文の保管先もアクセス制御します。不審な内容の削除と調査資料の保全は、担当者間で順序を決めて実施します。

更新後は権限の異なるアカウントで確認する

更新作業では、現行版と構成を記録し、バックアップと復元手順を確認したうえで開発元の手順に従います。複数のアプリインスタンスを運用しているなら、古い版が一部に残っていないことまで確認します。修正済みイメージを取得したことと、すべての稼働プロセスが切り替わったことを分けて扱ってください。

検証は管理下の環境で、機密情報を含まない専用ページとテストアカウントを用意して行います。編集可能、読み取り専用、ゲスト、停止中など、実際に使う権限の組み合わせで、閲覧できるページと編集できるページが一致すべき範囲を確認します。実在する第三者のページのIDを使って試す必要はありません。

合格条件は、正規の編集が成功することに加え、閲覧専用の利用者が共同編集へ接続して下書きを変更できないこと、別ページの版を指定しても権限を越えて本文やコメントを取得できないことです。具体的な試験は利用するAPIと修正版の仕様に合わせ、実施条件と結果を記録します。

CVSSと悪用状況を混同しない

JVNが示すCVSS v4.0は、ページ表示・コメント機能とタグ更新・ページ更新APIがそれぞれ2.3、同時編集機能が6.9です。本稿と構造化メタに単一の値を示す場合は、主題である同時編集のCVE-2026-115624の6.9を指します。3件すべてが6.9という意味ではありません。

今回確認した開発元告知とJVNの記載から、実環境での悪用発生を断定はできません。一方、悪用の公表を待たず更新する理由はあります。社内Wikiには手順や構成情報が集まりやすく、情報の読み取りと下書きの改変では点検対象も異なります。自社の公開範囲と権限構成に応じて優先順位を決めてください。

すぐ更新できない場合は、共同編集についてゲストアクセスの拒否と、該当ユーザーが閲覧できるページの範囲の制限を検討します。ただし、読み取り側とコピー側の詳細勧告は回避策なしとして更新を求めています。ゲストを拒否しただけで3件すべての対策が完了したと扱わず、更新予定と残る影響を管理します。

点検の担当は、アプリ更新の担当者だけにまとめず、ページの所有者と通知連携の管理者も含めます。機密本文が別ページへコピーされた可能性と、既存の下書きが変更された可能性を別の確認項目にし、どこまで調べたかを記録します。更新完了の記録には適用版だけでなく、残る確認作業と担当者を併記すると、修正の適用を調査完了と取り違えずに済みます。