CVE-2026-84205 in GROWI
Summary
by MITRE • 09/01/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability in GROWI represents a critical failure in server-side access control logic, specifically within the API endpoint responsible for retrieving document revisions. This flaw allows authenticated users to bypass intended permissions by exploiting a mismatch between path parameters and query parameter validation. The GET /_api/v3/revisions/:id endpoint is designed to return specific revision data based on an identifier provided in the URL path. However, the underlying implementation validates access rights against a separate page identifier passed via a query parameter rather than deriving or verifying that the requested revision actually belongs to the permitted page. This architectural oversight creates a direct path for unauthorized data disclosure, as the system fails to enforce consistency between the resource being accessed and the permissions granted to the user.
From a technical perspective, this is a classic example of insecure direct object references combined with broken access control logic. The application assumes that if a user has permission to view page A, they should only be able to retrieve revisions associated with page A. However, because the validation step checks the query parameter for authorization while the retrieval step uses the path parameter for data selection, an attacker can manipulate these inputs independently. By supplying a valid page identifier in the query string that corresponds to a resource they are authorized to view, and simultaneously providing an arbitrary revision ID from a restricted or private document in the URL path, the server processes the request without verifying ownership. This decoupling of authorization checks from data retrieval logic is the root cause of the vulnerability, allowing for horizontal privilege escalation where users can access sensitive information belonging to other pages they do not own or have permission to view.
The operational impact of this vulnerability is significant, particularly in environments where GROWI is used as a collaborative knowledge base containing confidential corporate documents, intellectual property, or personal data. An authenticated attacker with low-level privileges could potentially exfiltrate revision history from high-security pages, including deleted content that might have been removed for compliance reasons but remains stored in the database. This leads to unauthorized information disclosure and violates the principle of least privilege. In a multi-tenant setup or within an organization using strict access control policies, this flaw undermines trust in the platform's security model. Attackers could use this capability to gather intelligence on internal processes, discover sensitive configuration details embedded in past edits, or identify inconsistencies between published content and historical revisions that might reveal strategic plans or vulnerabilities.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to properly restrict access to resources for unauthorized actors. It also maps closely to CWE-639 Authorization Bypass Through User-Controlled Key, where the application relies on user-supplied input (the query parameter) for authorization decisions while using different user-controlled input (the path parameter) to identify the resource. In terms of offensive security frameworks, this behavior is consistent with MITRE ATT&CK technique T1078 Valid Accounts, as it requires authentication but exploits misconfigured permissions within that authenticated session. It also reflects aspects of T1530 Data from Cloud Storage Object Misconfiguration if viewed through the lens of improper resource isolation in cloud-native applications.
To mitigate this vulnerability, developers must enforce strict consistency checks between authorization parameters and resource identifiers. The application should validate that the page ID associated with the revision matches the page ID provided for access control verification before returning any data. Implementing server-side ownership validation ensures that a user can only retrieve revisions if they have explicit permission to view the specific document from which those revisions originated. Additionally, adopting parameterized queries and ensuring that all resource lookups are tied directly to authorized objects will prevent this type of bypass. Regular security audits focusing on access control logic in API endpoints are essential to identify similar patterns where authorization checks do not align with data retrieval mechanisms.