Engineering Lessons From GROWI's CVE-2026-115624 Authorization Fix
CVE-2026-115624 is a small authorization bug with a broad engineering lesson. GROWI's page update API enforced edit rights, while the collaborative editing connection enforced only page visibility. The inconsistency existed in two write paths for the same content.
Vulnerability overview
GROWI versions 7.0.0 through 8.0.6 are affected and version 8.0.7 fixes the issue. JVN identifies it as CWE-862 missing authorization and assigns CVSS 4.0 score 6.9 and CVSS 3.0 score 5.3.
The real-time Yjs connection accepted an unauthenticated guest on a publicly viewable page with read-only guest access. It also accepted a logged-in read-only user, or a pending, suspended, or invited user, when that person could view the page. The connection could change the page's editing draft.
The authorization model had two write paths
The page update API checked more than visibility. It required a logged-in active user who was not read-only. The collaborative editing path skipped that check. The patch applies the update API's rule to the collaboration connection while retaining the page-view decision.
This is a common design pressure in applications that add live collaboration. The new path has its own transport, session lifecycle, and synchronization library. Those differences do not change the underlying resource policy. A page edit remains a page edit whether it arrives through an HTTP update or a Yjs connection.
Why the bug produced persistent changes
The guest could not save through the page update API. The collaborative draft could still hold the modified content. A legitimate user who later opened the editor and saved could commit the draft under their own account name. Real-time participants could also see the change before it was committed.
That behavior makes authorization testing insufficient if it examines only a normal save action. A secure implementation needs one decision for the page, the actor, and the requested action, and every editing path should apply that decision.
Affected versions and operational scope
All GROWI releases from 7.0.0 through 8.0.6 are in scope. The temporary vendor guidance is asymmetric because the actor classes differ. Setting guest access to Deny blocks the unauthenticated guest path. It does not prevent logged-in read-only or non-active users with view access from using the vulnerable connection. Restrict those page grants and review drafts before saving.
The selected sources do not report exploitation in the wild. They describe a vulnerable authorization path and a verified fix, not a campaign.
Exposure context
ZoomEye's title="GROWI" query returned 401 matches and its exact CVE filter returned 0. The product count helps identify possible deployments but does not confirm version or vulnerable configuration.
Regression testing lessons
Upgrade to 8.0.7 or later. Build tests that cover every actor class named in the advisory. For each one, confirm that page visibility still works but an editing connection cannot modify the draft. Verify a legitimate active editor can collaborate and save.
Add a parity test between the page update API and every collaborative write protocol. The test should assert the same authorization outcome for the same user, page, and action. Include guest access, logged-in read-only, pending, suspended, and invited accounts, because those were the conditions with demonstrated impact.
Finally, keep temporary workarounds tied to their actual scope. Deny guest access is useful but incomplete. The durable fix is shared authorization logic and tests that prevent a new transport from becoming a weaker second write path.
