CVE-2026-84205: GROWI Access Control Bypass Vulnerability

CVE-2026-84205 Overview

CVE-2026-84205 is an access control vulnerability in GROWI, an open-source collaborative wiki platform. The flaw resides in the GET /_api/v3/revisions/:id endpoint, which validates caller access against a pageId query parameter but returns the revision identified by the path parameter. The two identifiers are never cross-checked. Authenticated attackers can pair a page they legitimately access with an arbitrary revision identifier to read revision content from pages they lack permission to view. The issue is classified as CWE-639: Authorization Bypass Through User-Controlled Key and affects GROWI through version 8.0.2.

Critical Impact
Authenticated users can read the contents of revisions belonging to restricted pages, resulting in confidentiality loss across the wiki.

Affected Products

GROWI collaborative wiki platform through version 8.0.2
The apps/app/src/server/routes/apiv3/revisions.js route handler
The apps/app/src/server/routes/apiv3/attachment.js route handler (related fix in the same patch)

Discovery Timeline

2026-09-01 - CVE-2026-84205 published to NVD
2026-09-02 - Last updated in NVD database

Technical Details for CVE-2026-84205

Vulnerability Analysis

GROWI exposes GET /_api/v3/revisions/:id to return a specific revision of a wiki page. The handler receives two user-controlled identifiers: a pageId from the query string and a revisionId from the URL path. The handler performs an access control check against pageId to confirm the caller has permission to view that page. It then retrieves the revision by revisionId and returns it in the response, without confirming the revision belongs to the authorized page.

An authenticated attacker who can view any single page can substitute an arbitrary revisionId referencing a restricted page. The server treats the pageId authorization decision as sufficient and returns the unrelated revision content. The impact is confined to confidentiality, as the endpoint reads revisions only.

Root Cause

The root cause is a missing referential integrity check between two user-controlled identifiers. GROWI treats authorization for one object as authorization for another related object without validating the relationship. This pattern is characterized by [CWE-639] as authorization bypass through user-controlled key. The upstream fix in commit d298e0b1 explicitly compares revision.pageId to the query-supplied pageId and returns a forbidden-page error when they differ.

Attack Vector

Exploitation requires an authenticated session with access to at least one page. The attacker enumerates or guesses revision identifiers from restricted pages, then issues a request that pairs an accessible pageId with the target revisionId. The server returns the revision body, including author metadata and page content, bypassing GROWI page-level access controls.

javascript

// Patch: apps/app/src/server/routes/apiv3/revisions.js
// Source: https://github.com/growilabs/growi/commit/d298e0b1dbbf568c99db657fa0f7e90f72ddc59b
          include: { author: true },
        });

+       // The pageId access check above only proves the caller may view the
+       // page identified by the query param — it says nothing about the
+       // revision fetched by the path param. Without this check, a caller
+       // could pair an accessible page's pageId with an arbitrary
+       // revisionId to read another page's revision.
+       if (revision == null || revision.pageId !== pageId) {
+         return res.apiv3Err(
+           new ErrorV3(
+             'Current user is not accessible to this page.',
+             'forbidden-page',
+           ),
+           403,
+         );
+       }
+
        if (revision.author != null) {
          revision.author = serializeUserSecurely(revision.author);
        }

A companion change in attachment.js propagates the isSharedPage context to the attachment handler, closing a parallel access control gap on revision attachments.

Detection Methods for CVE-2026-84205

Indicators of Compromise

Application logs showing GET /_api/v3/revisions/:id requests where the queried pageId and the returned revision.pageId do not match.
Repeated requests from a single authenticated session iterating over sequential or randomized revision identifiers.
Elevated request rates against the revisions API from accounts that historically access only a small set of pages.

Detection Strategies

Instrument the revisions route to log both the pageId query parameter and the pageId associated with the returned revision, and alert on mismatches.
Correlate authenticated user identity with the set of pages accessed via the revisions API to surface access patterns inconsistent with role-based permissions.
Review reverse proxy or WAF logs for high-volume enumeration against /_api/v3/revisions/.

Monitoring Recommendations

Ingest GROWI application and access logs into a centralized log platform and retain query-string parameters for the revisions endpoint.
Build dashboards tracking per-user request counts against /_api/v3/revisions/:id and flag deviations from baseline.
Alert on 403 forbidden-page responses appearing after patch deployment, which indicate blocked exploitation attempts.

How to Mitigate CVE-2026-84205

Immediate Actions Required

Upgrade GROWI to a version that includes commit d298e0b1 from Pull Request #11810.
Audit application logs for prior revisions API calls where the query pageId does not correspond to the returned revision's page.
Rotate or review any credentials, tokens, or secrets that may have been stored in wiki pages accessible only through restricted access controls.

Patch Information

The fix is committed to the GROWI repository as commit d298e0b1 and merged via Pull Request #11810. It adds an explicit equality check between revision.pageId and the query-supplied pageId in apps/app/src/server/routes/apiv3/revisions.js and adds shared-page context handling in apps/app/src/server/routes/apiv3/attachment.js. See the VulnCheck advisory for additional detail.

Workarounds

Restrict access to the GROWI instance to trusted, authenticated users while patching, since exploitation requires an authenticated account.
Place the /_api/v3/revisions/:id route behind a reverse proxy rule that logs both pageId and :id parameters for post-hoc analysis.
Temporarily disable or restrict the revisions API at the proxy layer if immediate patching is not feasible.

bash

# Example NGINX log format capturing revisions API parameters for auditing
log_format growi_revisions '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           'pageId=$arg_pageId revId=$uri';

location ~ ^/_api/v3/revisions/ {
    access_log /var/log/nginx/growi_revisions.log growi_revisions;
    proxy_pass http://growi_backend;
}