GROWIの脆弱性3件：閲覧制限の回避・下書き改変を防ぐ8.0.7への更新と点検

確認日：2026年10月27日16時台（日本時間）。JVNと開発元告知に基づく解説です。今回、編集部はGROWIへの攻撃再現や実環境の更新を行っていません。参照した一次資料で、実際の悪用や漏えい被害が発生したとの確認情報は見つかっていません。これは被害がなかったという証明ではありません。

8.0.7が今日初めて配布されたわけではありません。リリース記録と本日の勧告を分けて読みます。既に更新済みでも、古いコンテナや別拠点のインスタンスが残っていないかが点検対象です。開発元は8.0.7以降への更新を案内しています。

対象版はJVNの対応表によります。「8.0.7未満ならすべてのCVEが同じ条件で成立する」とは判定しません。改変版や独自の修正適用では、その修正内容を配布元の根拠と照合します。今回の表より古い版を、ほかの脆弱性も含めて安全だと認定する表でもありません。

CVSSは攻撃条件や影響を一定の規則で表す尺度で、被害の発生確率ではありません。ここでは発表元をJVN、版を4.0と3.0として区別しました。社外向けにページを公開している環境、部門ごとに機密情報を分けている環境では、点数だけで対応を後回しにしないことを勧めます。

認証は「誰か」を確かめる処理、認可は「その人に何を許すか」を確かめる処理です。さらに、ページには過去の内容を表す「版（リビジョン）」があります。入口のページを読めることに加え、指定された版が本当にそのページのものかも確かめる必要があります。

ページ表示・コメント側の勧告では、この対応付けの確認不足を説明しています。ログインでき、対象の版を識別できることが前提で、読み取り専用ユーザーも本文取得の対象条件に含まれます。修正では、別ページの版をそのまま使わないようにしています。

更新側の勧告は、読み取り専用ではないログインユーザーと、対象の版を識別できることを前提にしています。権限外の本文が別のページに複製されて残る経路があるため、更新作業に加えて、内容の不自然な置き換えがないかを確認する観点が必要です。

同時編集の勧告によると、共同編集用の接続では閲覧の可否は確認していましたが、編集を許すかの検査が不足していました。一般の保存APIが拒否していても、別の入口である同時編集の下書きが変わる場合があります。

ゲストが直ちに正式な版を保存できる、という説明ではありません。変更が下書きに残り、正規の編集者が後で保存すると、その編集者名で履歴に入る場合があります。共同編集している人にも変更が見えるため、「自分名義の履歴だから、自分だけが書いた内容」とは限りません。

• 管理者：対象インスタンス、稼働版、ゲスト設定、閲覧専用・非アクティブな利用者の閲覧範囲を記録する。公開Wikiも社内限定Wikiも確認する。
• 編集者：公開ページの下書きは、保存前に不審な追記やリンク、手順の変更がないか確認する。疑わしい内容を見つけたら、保存で上書きせず運用担当へ状況を伝える。
• 管理者：更新までの間、ゲストアクセスを「拒否」にすることを検討する。ただし公開範囲が変わるので、業務影響を確認して実施する。
• 管理者：閲覧専用ユーザー等が見られるページも必要な範囲へ絞る。ゲスト設定だけを変更して、全3件への対策完了とは記録しない。

ゲスト拒否と閲覧範囲の制限は、同時編集の公式暫定策です。本文・コメント取得側と更新側の勧告には回避策なしと記されており、修正版への更新が必要です。ユーザー登録を止めるだけでも、未ログインのゲスト経路の対策にはなりません。

以下は編集部が整理した運用手順です。環境を一律のコマンドで上書きせず、公式アップグレードガイドで現在の系列から必要な作業を確認します。古い系列では、データ移行とMongoDB等の依存環境の対応も関係します。

1. 1自社運用なら管理画面のトップまたはフッターで稼働版を記録する。GROWI.cloudはアプリ詳細画面の版と管理者の更新状況を確認する。
2. 2自社運用ではMongoDBのバックアップを取得する。添付ファイル等の保存先、復元手順、戻し方も自社構成に合わせて確認する。バックアップを外部LLMへ渡さない。
3. 3検証環境で、現在の系列に対応する公式の移行手順を確認する。GROWI本体と依存環境の対応を保ち、必要なメンテナンス時間を決める。
4. 48.0.7以降の修正を含む、採用する版へ更新する。取得した配布物だけでなく、実行中のすべてのインスタンスに反映する。
5. 5通常の閲覧・編集・検索・添付ファイル・通知を確認する。検証用ページと許可されたテストアカウントで、閲覧専用ユーザーが編集できないなど、期待する権限動作を確認する。攻撃用のリクエストを本番へ送らない。
6. 6担当者、更新後の稼働版、検証結果、未確認事項を台帳に残す。更新は過去の不正取得を取り消さないので、必要に応じて別途調査を続ける。

読み取りの問題について、開発元は本文取得で新しい版が作られないことを説明しています。ページ編集履歴だけでは、不正取得の有無は判断できません。取得済みのアクセスログ、アプリのログ、アカウント状態の記録を、保存期間と記録範囲を明記して確認します。ログがない部分は「未確認」です。

編集部としては、不自然な本文の複製、下書きの変更、普段と異なる権限でのアクセスを調査の入口にすることを勧めます。ただし、これらだけで攻撃と断定したり、疑わしい通信が見つからないことを安全の証明にしたりしません。調査前にログや疑わしい下書きを消す操作は避けます。

LLMには版・設定・証拠の抜けを整理させます。Wiki本文、認証情報、Cookie、生ログをそのまま投入しません。次の指示文は製品の検証結果ではなく、管理者が使うための教材です。点検用プロンプトをダウンロードできます。

対応の進め方は脆弱性ウォッチの基本手順も参照できます。GROWIを動かすNode.js等の依存部品の点検はNode.js・Brotliの記事で扱っています。本記事のGROWIの修正と、実行基盤の更新はそれぞれ確認してください。