GROWIに脆弱性3件 閲覧だけの人が下書きを書き換え、v8.0.7で修正

社内のwikiにGROWIを使っているなら、10月7日に出たv8.0.7より前の版は更新が要ります。

公表したのは、JPCERT/CCとIPAのJVNです。10月27日に3件をまとめて載せ、開発元の株式会社GROWIも、同じ日にお知らせとGitHubの勧告を出しています。

いちばん気をつけたいのは、同時編集の脆弱性です。閲覧しか許していない人が、ページの下書きを書き換えられます。

しかも、その中身は、あとから保存した正規の編集者の名前で履歴に残ります。

3件の脆弱性と悪用できる人

表で見てほしいのは、深刻度の数字より「悪用できる人」の列です。どれも社外の攻撃者というより、すでにページを見られる人が出発点になります。

読み取りの2件は、ページの版（リビジョン）が、そのページのものかを確認していなかったものです。見られるページのIDと、見られないページの版のIDを組み合わせると、見られない版の中身が返ってきました。

写す方の脆弱性では、写した先のページの中身が、写した本文で置き換わります。読み取りと書き換えが一度に起きる形です。

下書きの書き換えが厄介な理由

同時編集の脆弱性は、同時編集の接続を始めるとき、閲覧できるかだけを見て、編集できるかを確認していなかったものです。

書き換えた本人は、ページを保存できません。保存の処理は、正しく断るからです。

ただ、書き換えた中身は下書きとして残ります。正規のユーザーがあとでエディタを開いて保存すると、そのユーザーの名前でページの履歴に入ります。同じページを編集中のほかの人にも、その場で見えます。

履歴を見ても、書いたのは正規の社員。

手順書の連絡先やリンクを書き換えられたら、だれも気づかないまま社内に広がるでしょう。

ゲストのアクセスを「閲覧のみ」にして、ログインしていない人にページを見せている会社では、ログインしていない人も書き換えられます。ユーザー登録を止めていても防げない、と開発元はGitHubの勧告に書いています。

うちの会社が対象になる条件

分かれ目は、動いている版です。

• GROWIを自社のサーバーやDockerで動かし、版がv8.0.6以前なら対象です。ログインできる人がいれば、読み取りの2件が当たります。v7.0.0以降は、閲覧だけのユーザーや承認待ちなどのユーザーがいるだけで、下書きの書き換えも当たります。
• ゲストのアクセスを「閲覧のみ」にしていると、ログインしていない人まで書き換えの対象に入ります。
• v8.0.7以降に上げていれば、対象外です。

GROWI.cloudについて、10月27日のお知らせは触れていません。

ただ、10月22日に出たNode.jsの件のお知らせでは、GROWI.cloudの利用者にv8.0.8への更新を求め、安定版には1週間以内に反映するとしています。v8.0.8はv8.0.7より新しい版なので、v8.0.8に上がっていれば今回の修正も入っているはずです。

更新までに確認すること

1. 動いている版を確認します。Dockerで動かしているなら、使っているイメージのタグも見ておきます。v8.0.6以前なら、更新の日を決めます。
2. 上げる先は、v8.0.8がよいでしょう。v8.0.7の公式のDockerイメージは、10月21日に直ったNode.jsの脆弱性を含まない版で組まれていると、株式会社GROWIが案内しています（Node.jsが脆弱性10件を修正）。
3. すぐに上げられないなら、管理画面のセキュリティ設定（/admin/security）で、ゲストのアクセスを「拒否」にします。防げるのは、ログインしていないゲストだけです。
4. 残るのは、閲覧だけのユーザーと、承認待ち、停止中、招待中のユーザーです。この人たちが見られるページの範囲を絞るよう、開発元は勧めています。停止中のユーザーまで入っている点は、見落としやすいところです。
5. ゲストが見られるページの下書きは、保存する前に中身を確認します。これも開発元の求めです。あわせて、公開しているページの最近の履歴に、心当たりのない変更が無いかも見ておくと安心です。

GROWIの脆弱性は今年7回目

株式会社GROWIのお知らせの一覧を見ると、JVNの公表は2026年だけで7回あります。前回は10月5日のファイルのアクセス制限不備で、3週間しか空いていません。

救いは、直す側が早いことです。今回も、修正版のv8.0.7は公表の20日前に出ていました。

社内のwikiには、手順書から問い合わせ先まで、社員が頼りにする情報が集まります。更新の担当と、JVNのお知らせを見る人を決めておくと、次の公表で慌てずに済むでしょう。