Description

GROWI contains an access control vulnerability in the GET /_api/v3/revisions/:id endpoint that validates access against a query parameter but returns the revision identified by the path parameter without confirming they reference the same page. Authenticated attackers can pair a page identifier they can access with an arbitrary revision identifier to read revision content from pages they lack permission to view.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-01T16:17:35.470Z",
  "pubdate": "2026-09-01T16:17:35.470Z",
  "executiveSummary": "The vulnerability is an Improper Access Control flaw within the GROWI application's API endpoint GET /_api/v3/revisions/:id.\nThis vulnerability allows authenticated attackers to bypass authorization checks and retrieve sensitive revision data from pages they are not authorized to access.\nThe root cause is a failure in the validation logic where the system performs authorization checks against a page identified via a query parameter, while simultaneously serving content from a revision identifier provided in the URI path parameter without verifying a mapping between the two.\nThe impact is significant, as it leads to unauthorized disclosure of protected revision content, potentially exposing sensitive information, intellectual property, or confidential organizational data.\nThe flaw is exploitable by any authenticated user of the system. There are no additional complex requirements other than the possession of valid session credentials and the ability to craft HTTP requests that manipulate the discrepancy between the query and path parameters.\nThe risk implication is critical, as it undermines the fundamental access control model of the platform, potentially allowing for systematic data scraping of revisions across restricted namespaces.",
  "technicalDetails": "The vulnerability exists within the logic of the GROWI backend API, specifically the GET /_api/v3/revisions/:id endpoint. The application is designed to retrieve document revision data based on a revision ID provided as a path parameter. However, the access control mechanism is decoupled from the content retrieval logic.\nThe root cause is a validation mismatch. When a request is made to this endpoint, the application performs a permission check based on a page identifier supplied in the query string (e.g., ?pageId=...). Upon confirming that the authenticated user possesses sufficient read permissions for the page referenced in the query parameter, the system proceeds to fetch the content associated with the :id path parameter.\nThe critical security flaw is the failure to enforce an integrity check between the page context (query parameter) and the specific revision (path parameter). The application assumes that the revision belongs to the authorized page without validating this association. Consequently, an attacker can supply the identifier of a page they have legitimate access to in the query string to satisfy the authorization middleware, while providing the ID of a sensitive revision from a restricted page in the path parameter.\nThe exploitation flow follows these steps: 1) The attacker identifies a target revision ID belonging to a private page. 2) The attacker identifies a public or permitted page ID that they are authorized to access. 3) The attacker crafts a request to GET /_api/v3/revisions/[TARGET_REVISION_ID]?pageId=[PERMITTED_PAGE_ID]. 4) The API validates the user's access to the permitted page, passes the authorization gate, and subsequently retrieves the revision content specified by the path ID.\nBecause the application does not perform a secondary lookup to confirm that the requested revision is actually a child of the page validated via the query parameter, the internal API service returns the contents of the unauthorized revision directly to the attacker. This bypasses the intended security boundary of the GROWI document management system.\nThe exposure is network-based, requiring the attacker to interact with the API interface. Post-exploitation, an attacker can iteratively harvest unauthorized revision history by enumerating valid revision IDs, leading to large-scale data exfiltration of private document history."
}