GROWI Authorization Bypass Vulnerabilities

Missing authorization in GROWI's collaborative editing (Yjs) connection allows unauthenticated guests on 'Readonly' guest-access pages, logged-in read-only users, and non-active users (pending, suspended, or invited) with view access to modify page drafts without edit permission. The tampered content persists only as the page's editing draft and is committed to page history under a legitimate user's name when that user later opens the editor and saves, while the page update API still rejects the attacker's own save. Affected versions v7.0.0 through v8.0.6 are fixed in v8.0.7; no public exploit was identified at time of analysis, and the flaw is integrity-only (CWE-862) with a moderate this-month priority.

Authenticated read-permission bypass in GROWI versions 3.2.10 through 8.0.6 lets any logged-in user, including read-only accounts without edit permission, read the body or comments of a revision belonging to a page they cannot view by pairing that revision ID with the ID of a page they can view. The flaw is a CWE-639 authorization bypass in the page view, GET /_api/v3/page, and GET /_api/comments.get paths; share-link access is unaffected. It is low severity (CVSS 4.0: 2.3), fixed in v8.0.7, and no public exploit was identified at time of analysis.

Authorization bypass in GROWI v4.5.5 through v8.0.6 lets an authenticated, non-read-only user copy the body of a page revision they cannot read into a page they can edit, via the tags.update API and, under specific editor conflict-check conditions, PUT /_api/v3/page. The attacker must know or guess the target revision's MongoDB ObjectId, which is not secret by design but is not trivially enumerable, making this a low-severity, monitor-level issue. No public exploit was identified at time of analysis, and the vendor fixed the flaw in v8.0.7.