【ITニュース解説】Auditing file-serving permission checks, using CVE-2026-100727 as the model

この文書では、ウェブアプリケーションにおけるファイル提供時のアクセス権限チェックの重要性と、それに潜む脆弱性のパターンについて解説する。システムエンジニアを目指す上で、ユーザーがアップロードするファイルや、アプリケーションが生成するファイルをどのように安全に管理するかは非常に重要な知識となる。特に、ファイルへのアクセス権限が適切に管理されていないと、機密情報が外部に漏洩するなどの深刻なセキュリティ事故につながる可能性がある。

今回取り上げるのは、GROWIというオープンソースのWikiシステムで見つかった「CVE-2026-100727」という脆弱性をモデルケースとした解説である。この脆弱性は、GROWIのバージョン7.5.5より前のシステムにおいて、ファイルアップロードの設定が「ローカル」になっている場合に発生した。具体的には、認証されていない外部の攻撃者が、本来であれば非公開ページに添付されているはずのファイルを閲覧できてしまうという問題だった。この脆弱性は、セキュリティ評価基準であるCVSS 4.0で6.9点、CVSS 3.0で5.3点と評価されており、情報の機密性が損なわれるリスクがあることを示している。ベンダーはこの問題をJPCERT/CCへの報告後、2026年10月5日にリリースされたバージョン7.5.5で修正した。

このGROWIのケースは、多くのウェブアプリケーションプラットフォームで共通して見られる種類のバグを明確に示している。それは、「アプリケーションがページ自体に適用する権限チェック」と、「そのページが参照している保存されたファイルに対する権限チェック」が異なっている、あるいはファイルに対するチェックが弱すぎるか、全く行われていないというパターンだ。このような問題は、実際にセキュリティインシデントが発生してから発見するよりも、事前にシステムを監査して見つける方がはるかにコストを抑えられるため、積極的に調査すべき対象となる。

では、どのような権限チェックが本当に重要なのか。ファイルのようなデータを返す全ての機能（「エンドポイント」と呼ばれる、特定の機能にアクセスするためのURLのこと）について、どの権限決定の基準が適用され、その決定がどの「オブジェクト」に対して評価されているかを問いかける必要がある。ここでいう「オブジェクト」とは、ファイルそのものではなく、そのファイルが属する「所有レコード」、つまりファイルが紐づいている親となる情報やページを指すべきだ。単に「ファイルの保存パス」に基づいて権限チェックを行うのは、異なる質問に答えているに過ぎない。パスによるチェックは、単に「要求者がそのオブジェクトの名前を知っているか」という問いに答えるものであり、アクセスを許可するかどうかの「認証・認可」の判断ではない。例えば、ウェブサーバーが特定のディレクトリ以下のファイルを無条件に提供している場合、そのファイルパスを知っていれば誰でもアクセスできてしまう可能性があるが、これはそのファイルの内容にアクセスする権限があるかどうかとは全く別の話である。

このような脆弱性のパターンは、アプリケーションの様々な場所に隠れている場合がある。一つは、アプリケーションのメインの処理の流れ（「リクエストパイプライン」と呼ばれる、ウェブアプリケーションがリクエストを受け取ってからレスポンスを返すまでの一連の処理）の外で登録されている静的なファイル配信ルートである。これらのルートは、ユーザーのセッション情報や権限情報を持つ「ミドルウェア」（ウェブアプリケーションの処理の途中で共通の機能を提供する部分）を通らないため、適切な権限チェックが行われないままファイルを提供してしまう可能性がある。次に、ファイル識別子（ID）を受け取って直接ファイルを読み込んで返すダウンロード機能も注意が必要だ。この機能が、ユーザーがそのファイルにアクセスする権限があるかどうかを、ファイルIDだけでなく、そのファイルを所有するオブジェクトの権限情報と照らし合わせて確認しない場合、問題が生じる。また、「署名付きURL」という、一時的に特定のファイルへのアクセスを許可する機能も、署名がファイルのパスだけをカバーし、その時点のアクセス権限の状態をカバーしていない場合、所有者がアクセス権限を剥奪した後もリンクが有効なままでいられるリスクがある。さらに、ウェブエディタ内で添付ファイルを表示する際、参照されるファイルを別のハンドラ（処理機能）が取得する場合があり、このハンドラが独立して権限チェックを行わないと、脆弱性につながることがある。最後に、過去のアーカイブやエクスポートされたコンテンツのバンドルが、元のファイルパスをそのまま再現しつつも、本来適用されていたはずの権限チェックを伴わない形で提供される場合も、情報漏洩のリスクがある。

このような種類の脆弱性を見つけるためには、繰り返し実行できるレビュー（監査）プロセスを確立することが重要である。まず、ライブラリや静的ファイルハンドラによってマウントされるルートを含め、ファイルのようなコンテンツを返すすべてのURL（ルート）を洗い出す。次に、それぞれのルートに対して、どのような権限決定が作用しているのか、そしてその決定がどのオブジェクト（ファイルそのものではなく、その親となる情報）に対して評価されているのかを記録する。そして、そのオブジェクトが、ユーザーインターフェース上でユーザーに保護されていると認識されているオブジェクトと一致するかどうかを比較する。具体的なテストとしては、非公開ページの添付ファイルに対して匿名ユーザーからのアクセスを試み、その結果（アクセスできるか、拒否されるか）を記録する。このテストは、ファイルの処理方法が変更されるようなアップグレードの後も、繰り返し実行すべきである。なぜなら、システムの改修（リファクタリング）によって権限チェックの場所が移動したり、意図せず失われたりする可能性があるからだ。

今回のCVE-2026-100727の例では、GROWIバージョン7.5.5より前で、ファイルアップロード設定が「ローカル」の場合にのみ影響があった。しかし、このレビュー方法は他のプラットフォームにも変更なしで適用できるため、それぞれのシステムに合わせて権限チェックとエンドポイントのマッピングを行うことで、同様の脆弱性を特定可能である。

この脆弱性に関連して、2026年10月5日時点で、検索エンジンZoomEyeで「title="GROWI"」という検索クエリを実行すると、401件のシステムが検出された。この数字は、GROWIという製品を使用している可能性のあるシステム数を示しており、直ちに脆弱なインスタンスの数や、各ホストがどのファイルアップロードバックエンドを使用しているかを報告するものではないが、潜在的な影響の広さを示唆している。

このような脆弱性への対処法と緩和策は明確である。GROWIの場合、バージョン7.5.5へのパッチ適用が必須となる。修正が適用されたことを確認するためには、先述の匿名ユーザーによるリクエストパスのテストを再度実行し、期待通りの結果（アクセスが拒否されること）が得られるかを検証すると良いだろう。もし引き続きローカルストレージを使用している場合は、その設定が将来のアップグレード後も適切に機能しているかを確認すべき設定項目として扱い、定期的に検証を続けることが重要である。また、万が一情報漏洩が発生した場合に迅速に対応できるよう、添付ファイルのインベントリ（一覧）を常に最新の状態に保ち、影響範囲を素早く特定できるようにしておくべきである。