GROWI EUVD-2026-69292

Exploitation requires an active authenticated session on the GROWI instance - any account with login access suffices, including low-privilege contributor or viewer roles (CVSS PR:L confirms this). The attacker must also be able to enumerate or guess at least one valid MongoDB ObjectId for a revision belonging to a restricted page; this is a non-trivial but not insurmountable barrier, especially in instances with high revision counts or predictable ID patterns. The targeted page must have page-level access controls configured (GRANT_OWNER or group-restricted) - public pages without restrictions are not meaningfully exposed. No special server-side configuration is required; the flaw exists in the default GROWI API routing. Exploitation is limited to confidentiality: no write or administrative operations are exposed through this endpoint.

The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N places this as a straightforward network-reachable, low-complexity exploit requiring only a valid authenticated session - no special privileges or user interaction. Real-world risk is moderate-to-high for organizations using GROWI with page-level access controls: any contributor or viewer account can bypass those controls entirely, reading page history (revision content) regardless of grant settings. There is no KEV listing and no public exploit code confirmed, keeping the immediate exploitation risk lower than the CVSS alone suggests. EPSS data is not provided; absent active exploitation, risk is primarily insider-threat or credential-compromise-driven rather than mass automated scanning. The VulnCheck advisory covers all versions through 8.0.2, with a patch now available, so unpatched instances represent the full exposed population. The scope is confidentiality-only: no write, delete, or privilege escalation path is identified from this flaw.

An authenticated GROWI user with read access to a single public page discovers the revision ID of a private page through indirect means - for example, by observing revision IDs in URLs of accessible pages and incrementing or guessing adjacent IDs. The attacker calls GET /_api/v3/revisions/<private_revision_id>?pageId=<accessible_public_page_id>, supplying their accessible page's ID as the query parameter. The server authorizes the request against the accessible page, then returns the full revision document from the private page, exposing its historical text content without triggering an access-denied response.