GROWIに脆弱性2件、非公開ページ名が漏れる

国産のオープンソース社内Wiki「GROWI」に、認可の不備による脆弱性が2件公表されました（JVN#42348352、2026年8月28日公表）。影響を受けるのは v8.0.0 およびそれ以前の全バージョンで、修正版は v8.0.1 です。任意コード実行のような派手な脆弱性ではありませんが、閲覧権限のないページのパスとタイトルが第三者に取得できるという、社内Wikiとしては見過ごせない内容を含みます。自社で GROWI を運用しているなら、まずバージョンを確認してください。

この記事でわかること

  • GROWI とは何をするツールで、なぜ情シスの管理外に存在しがちなのか
  • 公表された2件（CVE-2026-53620 / CVE-2026-68951）の中身と影響範囲
  • 「ブックマークの脆弱性」が実質的な情報漏えいになる理由
  • 自社が該当するかの確認手順と、JVNの2件だけで判断すると危ない理由

GROWI とは何をするツールなのか

GROWI とは、Markdown で書けるチーム・社内向けのWiki（ナレッジ共有）ツールです。議事録、業務マニュアル、企画書、手順書などを1か所にまとめ、複数人で同時編集・全文検索するために使われます。開発元は GROWI, Inc. で、MITライセンスのOSSとして GitHub（growilabs/growi）で公開されています。

情シスにとって重要なのはここからです。GROWI はDocker イメージが公開されており、公式サイトの記載によればイメージのプル数は120万回を超えています。「情シスが正式に導入した覚えがない」場合でも、開発チームや事業部が自前のサーバやクラウド上に立てていることが十分にあり得ます。SAML / LDAP / OAuth による認証連携にも対応するため、社内の認証基盤とつないだまま資産管理台帳に載っていない状態が起こりやすいツールです（クラウド版の GROWI.cloud も提供されています）。「うちは使っていない」と即断せず、後述の手順で社内に稼働インスタンスがないかを確認してください。

何が起きたのか

JPCERT/CC と IPA が運営する脆弱性情報ポータル JVN に、2026年8月28日付で JVN#42348352 が公表されました。開発元も同日、自社サイトで脆弱性対応のお知らせを公開しています。内容は、いずれもブックマーク機能まわりのAPIにおける認可（権限チェック）の不備です。

CVE 種別（CWE） CVSS v3.0 CVSS v4.0 想定される影響
CVE-2026-53620 権限チェック回避（CWE-639、IDOR） 6.3 5.3 ログイン済みの攻撃者が他ユーザーのブックマークを取得・改ざん・削除
CVE-2026-68951 認可処理の不備（CWE-863） 5.3 6.9 アクセス可能な攻撃者が他ユーザーのブックマークを取得

CVE-2026-53620：他人のブックマークフォルダを操作できる

開発元の説明によると、ブックマークフォルダの作成・更新・削除、およびブックマーク追加の各APIで、操作対象のフォルダがリクエスト元ユーザーのものかを確認していません。その結果、ログイン済みの一般ユーザーが他ユーザーのブックマークフォルダを削除・名称変更・移動でき、配下にフォルダやブックマークを追加することもできます。開発元は「自動化により、全ユーザーのブックマークデータを一括で破壊・改変することも可能」と明記しています。

いわゆるIDOR（Insecure Direct Object Reference、安全でない直接オブジェクト参照）で、リクエストに含まれるIDを他人のものに差し替えるだけで成立する典型的な型です。攻撃に特別な技術は要りません。

CVE-2026-68951：閲覧権限のないページの「名前」が見えてしまう

こちらがより厄介です。指定したユーザーのブックマークを取得するAPIで、ブックマーク対象ページの閲覧権限と、管理者が設定したページ一覧の表示設定が適用されていません。そのため、閲覧権限のないページの情報（ページパス・タイトル等）を取得できます。開発元によれば、対象には次が含まれます。

  • 特定のグループに限定公開されたページ
  • 「リンクを知っている人のみ」で公開されたページ
  • ユーザーページが無効化されている場合のユーザーページ

さらに、ゲストユーザーの閲覧を許可する設定にしている場合、未ログインのゲストからも実行可能とされています。CVSS v3.0 で PR:N（権限不要）と評価されているのはこのためです。社外からアクセスできる場所に GROWI を置き、かつゲスト閲覧を許可している環境は、優先度を上げて対応すべきです。

なぜ「ブックマークだけ」で済まないのか

この脆弱性は「ブックマークが漏れる・壊れる」と要約されがちですが、社内Wikiという文脈では意味合いが変わります。漏れるのはページの中身ではなくパスとタイトルです。そして社内Wikiでは、パスとタイトルそのものが機密であることが珍しくありません。

実際の社内Wikiには、こうしたページ名が並びます。

  • /経営企画/2026年度_○○社_買収検討
  • /人事/懲戒処分_検討メモ
  • /情シス/インシデント対応_ランサム疑い
  • /開発/未発表製品_コードネーム

本文を読めなくても、これらのページ名が一覧で取れれば「何が進行中か」はかなりの精度で推測できます。とくに、グループ限定公開ページや「リンクを知っている人のみ」のページは、まさに「見せたくない相手がいるから権限を絞った」ページです。そこが対象に含まれている点が、この脆弱性の実質的な深刻さだと考えます。ページ名から所属や案件名が割れれば標的型メールの精度も上がるため、CVSS の数値だけで「中程度だから後回し」と判断すると、この文脈が抜け落ちます。

自社の GROWI は影響を受けるのか

影響を受けるのは GROWI v8.0.0 およびそれ以前です。以下の順で確認してください。

  1. 稼働インスタンスの洗い出し：情シス管理外の可能性があるため、社内のコンテナ基盤・検証用サーバ・クラウドを確認します。Docker で立てられることが多いので、docker ps や docker compose images でイメージ名とタグを見るのが早いです。
  2. バージョン確認：管理者としてログインし、管理画面（/admin）に表示されるバージョンを確認します。Docker 運用ならイメージタグでも判別できます。
  3. 公開範囲の確認：インターネットから到達可能か、リバースプロキシやVPNの内側かを確認します。到達可能なら優先度を上げます。
  4. ゲスト閲覧設定の確認：ゲスト閲覧を許可している場合、CVE-2026-68951 は未認証で成立します。ここが最優先の判断材料です。
  5. アップデート：v8.0.1 以降へ更新します。後述の理由から、可能なら最新版まで上げることを勧めます。

なお、クラウド版 GROWI.cloud の扱いについては開発元の告知に明記がありません。利用している場合は提供元に対応状況を確認してください（本記事では未確認です）。

JVNの2件だけを見て判断すると危ない

ここが今回いちばん伝えたい点です。GitHub 上の GROWI のリリースノートを確認すると、修正版である v8.0.1 は 2026年8月10日にリリースされており、JVN公表（8月28日）より約3週間早いことが分かります。そして v8.0.1 には、今回CVE番号が付いた2件（PR #11478）以外にも、セキュリティに関わる修正が複数含まれています。

  • GROWI お引越し機能（G2G転送）の受信側における認証バイパスとパストラバーサルの防止（#11631）
  • GROWI Vault で、リクエスト元の閲覧範囲外にあるオブジェクトへのリクエストを拒否（#11604）

さらに、続く v8.0.2（2026年8月25日リリース）にも認可まわりの修正が入っています。

  • 添付ファイルの取得で、ゲストからのリクエストにもページの閲覧権限を適用（#11756）
  • ページの書き込み系ルートで、存在しない場合と権限が無い場合の応答を一律404に統一（#11762。応答の差から非公開ページの存在を推測されるのを防ぐ変更です）

つまり、CVE番号が付いて公表されたものは、そのバージョンで直った認可の穴の一部にすぎません。「CVSSが6点台のブックマークの話だから急がない」と判断すると、CVE番号の付かなかった認証バイパスやパストラバーサルの修正まで先送りすることになります。パッチの適用判断をCVE単位ではなくリリースノート単位で行うべき、という分かりやすい実例です。

もうひとつ。開発元のお知らせ一覧を見ると、2025年10月から2026年8月までの約10か月間にJVN公表が8件あります。脆弱性が継続的に発見・修正・公表されているのは健全な状態でもあり、製品が危険という意味ではありません。要はGROWI は「入れて終わり」ではなく定期的なアップデート運用を前提とする製品だということです。導入部門に運用を任せきりにしている場合、この前提が共有されていない恐れがあります。

現場目線の所感

正直なところ、この手のツールがいちばん厄介なのは「誰が管理者なのか分からない」状態にあることです。社内Wikiは、たいてい現場が自発的に立てて自発的に育てます。便利だからこそ全社に広がり、気づけば人事や経営企画の資料まで載っている。それでもサーバの管理者は最初に立てた1人のまま、という光景は珍しくありません。

今回のように「修正版は3週間前に出ていた」ケースでは、リリースノートを追う担当者がいるかどうかで対応の速さが決まります。しかしOSSのリリースノートを毎回読む余力は、たいていの情シスにはありません。だからこそ、自前で追うのではなく、JVNやIPAの注意喚起を受け取る導線を整えたうえで、対象製品の一覧（＝資産管理台帳）を先に作っておくことが現実的だと感じます。台帳に載っていないものは、どんなに良い注意喚起が来ても紐づきません。なお、シャドーIT化した社内Wikiは技術的に潰すより先に「どこに何があるか申告してもらう」ほうが早く、責める運用にすると隠されるだけだという点も申し添えておきます。

情シスはどうすべきか

個別のチェックリストを長々と並べるより、まずは公的機関の指針を土台にするのが確実です。

  • 資産の把握とアップデート運用の基本は、IPA「中小企業の情報セキュリティ対策ガイドライン」が土台になります。規模を問わず、資産管理と更新の考え方は参考になります。
  • 脆弱性情報を受け取る導線としては、JPCERT/CC と IPA が運営する JVN の購読が基本です。今回の GROWI のように、国産製品・国産OSSは JVN に載ります。
  • 万一「非公開ページの情報が外部から見えていた」と分かった場合の初動は、IPA「セキュリティインシデント対応 机上演習教材」で事前に流れを確認しておくと動きやすくなります。

あわせて、地道な啓発も効きます。「社内Wikiのページタイトルに、それ単体で機密になる固有名詞（社名・案件名・個人名）を書かない」という運用ルールは、今回のような一覧漏えい型に対する現実的な緩和策であり、技術的対策が間に合わない期間の保険にもなります。

関連記事

まとめ

  1. GROWI v8.0.0 以前に認可不備の脆弱性が2件（CVE-2026-53620 / CVE-2026-68951）。修正版は v8.0.1。ゲスト閲覧を許可している環境では未認証でも成立し得ます。
  2. 漏れるのは本文ではなくページのパスとタイトルですが、社内Wikiではページ名自体が機密です。グループ限定公開や「リンクを知っている人のみ」のページが対象に含まれる点が実質的な深刻さです。
  3. v8.0.1・v8.0.2 にはCVE番号の付かない認証バイパスやパストラバーサルの修正も入っています。判断はCVE単位ではなくリリースノート単位で行い、最新版まで上げるのが安全です。

出典

タイトルとURLをコピーしました