CVE-2026-84204: GROWI Auth Bypass Vulnerability

CVE-2026-84204 Overview

CVE-2026-84204 is a missing authorization vulnerability [CWE-862] in GROWI, an open-source collaborative wiki platform. The GET /_api/v3/attachment/:id endpoint fails to validate page access permissions before returning attachment metadata. Authenticated users can retrieve metadata for attachments belonging to pages they lack permission to view. Attackers only need a valid low-privileged account and knowledge of an attachment identifier to exploit the flaw. GROWI versions through 8.0.2 are affected.

Critical Impact
Authenticated attackers can enumerate and retrieve attachment metadata from restricted pages, breaking tenant and workspace confidentiality boundaries in GROWI deployments.

Affected Products

GROWI collaborative wiki platform through version 8.0.2
Deployments exposing the /_api/v3/attachment/:id endpoint
Self-hosted GROWI instances with multi-user access control

Discovery Timeline

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

Technical Details for CVE-2026-84204

Vulnerability Analysis

The vulnerability resides in the attachment retrieval route defined in apps/app/src/server/routes/apiv3/attachment.js. The handler accepts an attachment identifier via the URL parameter and returns the associated document without verifying that the caller has read access to the parent page. GROWI enforces per-page access controls, but this route bypasses those checks entirely.

An authenticated attacker who obtains or guesses a valid attachment ID can query the endpoint and receive metadata such as file name, size, creator information, and page linkage. This exposes sensitive content stored in private or group-restricted pages.

A related issue in apps/app/src/server/routes/apiv3/revisions.js allowed pairing an accessible pageId query parameter with an arbitrary revisionId path parameter to read revisions from other pages. Both defects share the same root cause: authorization was performed on the wrong identifier.

Root Cause

The attachment handler resolves the record directly from Attachment.findById(attachmentId) and serializes it back to the caller. It never invokes the page permission service against attachment.page before responding. The revisions handler similarly validated pageId but not the linkage between the requested revisionId and that page.

Attack Vector

Exploitation requires network access to the GROWI API and a valid low-privileged authenticated session. The attacker issues an HTTP GET request to /_api/v3/attachment/{id} with a known or enumerated attachment identifier. No user interaction is required and the request completes in a single API call.

javascript

// Security patch in apps/app/src/server/routes/apiv3/attachment.js
     async (req, res) => {
       try {
         const attachmentId = req.params.id;
+        const { isSharedPage } = req;
 
         const attachment = await Attachment.findById(attachmentId)
           .populate('creator')

// Source: https://github.com/growilabs/growi/commit/d298e0b1dbbf568c99db657fa0f7e90f72ddc59b

The companion patch in the revisions route enforces that the revision belongs to the page identified by the caller:

javascript

// Security patch in apps/app/src/server/routes/apiv3/revisions.js
           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);
         }

// Source: https://github.com/growilabs/growi/commit/d298e0b1dbbf568c99db657fa0f7e90f72ddc59b

Detection Methods for CVE-2026-84204

Indicators of Compromise

Bursts of GET /_api/v3/attachment/:id requests from a single authenticated session iterating over sequential or randomized attachment identifiers.
API access patterns where a user retrieves attachments for pages they never rendered via the normal /page UI flow.
HTTP 200 responses to attachment metadata requests preceding no corresponding page view events for the same user.

Detection Strategies

Correlate application logs to compare attachment API access with page view telemetry for the same user and page identifier.
Alert on high-volume enumeration of /_api/v3/attachment/ or /_api/v3/revisions/ endpoints by non-administrative accounts.
Deploy Web Application Firewall (WAF) rules that rate-limit repeated attachment ID lookups per session.

Monitoring Recommendations

Ingest GROWI application logs and reverse proxy access logs into a centralized log platform for behavioral analysis.
Monitor authentication logs for account creation followed immediately by broad API enumeration activity.
Track anomalies in per-user attachment retrieval volume against historical baselines.

How to Mitigate CVE-2026-84204

Immediate Actions Required

Upgrade GROWI to a release containing commit d298e0b1dbbf568c99db657fa0f7e90f72ddc59b from Pull Request #11810.
Audit access logs for anomalous requests to /_api/v3/attachment/:id and /_api/v3/revisions/:id since deployment.
Rotate or invalidate any credentials for accounts observed enumerating attachment identifiers.

Patch Information

The fix is delivered in GROWI commit d298e0b, merged via Pull Request #11810. The patch adds page access validation before returning attachment records and enforces revision.pageId === pageId for revision retrieval. Refer to the VulnCheck advisory for vendor coordination details.

Workarounds

Restrict the /_api/v3/attachment/:id and /_api/v3/revisions/:id endpoints at the reverse proxy layer to administrative users until patched.
Reduce the population of authenticated users on the instance and require approval for new account registrations.
Front the GROWI application with a WAF that blocks unauthenticated or excessive enumeration of numeric or hashed identifiers.

bash

# Example nginx restriction blocking direct attachment API access at the proxy
location ~ ^/_api/v3/(attachment|revisions)/ {
    allow 10.0.0.0/8;      # internal admin range only
    deny all;
    proxy_pass http://growi_upstream;
}