GROWI CVE-2026-109848

Requires an authenticated GROWI user who is NOT read-only (edit capability), per PR:L. The attacker must additionally know or guess the target revision's MongoDB ObjectId - composed of a timestamp, per-process random value, and counter, so not secret by design but not trivially enumerable (this is the AT:P attack requirement). Exploitation is via POST /_api/tags.update (API v1), or via PUT /_api/v3/page where the previous revision is looked up from a client-supplied revisionId; the PUT path is reachable only when the editor's conflict check is skipped (origin=editor and the latest revision's origin is editor or view), and its cross-page diff can also leak via the Slack update notification when isSlackEnabled and slackChannels are set. Limiting factors: authentication and non-read-only privilege are mandatory, the attacker needs a usable foreign revision ID, and the PUT variant depends on the specific editor/conflict-check state.

This is a genuine but low-priority issue, and the signals are consistent rather than conflicting. The vendor/CVE CVSS 4.0 base is 2.3 (Low) and the vuln.today decision label is 'monitor' - both point to low urgency. There is no CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation. The CVSS vector shows network reach (AV:N) but PR:L, meaning exploitation requires an authenticated, non-read-only account, and AT:P reflects a real attack requirement: the attacker must know or guess the target revision's identifier. Impact is bounded - VC:L/VI:L and VA:N: an attacker can read one unauthorized page revision's body at a time (confidentiality) and overwrite a page they can already edit with that body (integrity, which also destroys the editable page's prior content), with no availability effect. One nuance that modestly raises feasibility above the raw score: the advisory notes revision IDs are MongoDB ObjectIds (timestamp + per-process random + counter), so IDs created around the same time by the same process are somewhat more guessable than a random value - but this is a predictability note, not confirmed exploitation. No EPSS data is available to quantify exploitation probability; absent it, the KEV-absence, low CVSS, 'monitor' label, and authentication requirement all align on low real-world risk.

A logged-in GROWI user who lacks read permission on a sensitive page learns or guesses the MongoDB ObjectId of one of that page's revisions, then calls POST /_api/tags.update supplying that foreign revisionId together with a pageId they are allowed to edit. The API returns the restricted revision's body in the response and stores it as a new revision of the attacker's page, leaving the stolen content readable there. No public exploit code was identified; the attack requires an authenticated non-read-only account and knowledge of a revision ID that is not secret by design but is not trivially enumerable (AT:P).