The Integrity Risk Behind CVE-2026-115624
The Integrity Risk Behind CVE-2026-115624 Confidentiality gets most of the attention in access-control incidents. CVE-2026-115624 is primarily a reminder that integrity failures can be harder to notice. An unauthorized
The Integrity Risk Behind CVE-2026-115624
Confidentiality gets most of the attention in access-control incidents. CVE-2026-115624 is primarily a reminder that integrity failures can be harder to notice. An unauthorized actor could alter a GROWI page draft through a connection that was supposed to preserve editorial boundaries.
What the vulnerability is
The CVE affects GROWI versions 7.0.0 through 8.0.6 and is fixed in 8.0.7. It is classified as CWE-862, missing authorization, with CVSS 4.0 score 6.9 and CVSS 3.0 score 5.3.
GROWI's collaborative editing connection authorized by page visibility. It did not require edit permission. According to the vendor, an unauthenticated guest on a publicly viewable page, a logged-in read-only user, or a pending, suspended, or invited user with view access could modify the draft.
Why content integrity is the central issue
The normal page update API rejected a guest's direct revision save. The collaborative draft still accepted changes. If a legitimate editor opened the page later and saved, the content could become a revision under that editor's account name. Other users in the session could see the change immediately.
That creates a provenance problem. Teams often use document history to answer who changed a policy, runbook, incident note, or procedure. In this case, the author of the save may be the person who committed the draft rather than the person who introduced every line.
The impact is narrower than arbitrary account takeover. The advisory does not describe a route to read hidden pages, execute code, or gain administrative rights. Its practical weight comes from unauthorized content changes and the possibility that trusted collaborators will preserve them.
Conditions that increase business risk
The highest-value review targets pages that broad groups can view but only trusted editors should change. A read-only guest setting is directly named, but logged-in read-only and non-active users also matter regardless of that setting. Internal policy pages, approval records, and operational runbooks deserve scrutiny because a small text change can alter a decision.
The reviewed sources do not report active exploitation. That limit should be stated plainly. It does not remove the need to patch affected installations or inspect drafts created before the fix.
Exposure context
The ZoomEye Search Dork title="GROWI" returned 401 product-title matches. The exact CVE filter returned 0. The count is useful for finding possible public deployments, but it does not show version, access configuration, or whether any draft was changed.
Remediation and content assurance
Upgrade to 8.0.7 or later. The fix requires a logged-in active user who is not read-only in addition to the page-view check, matching the page update API's authorization model.
Before the patch is applied, set guest access to Deny, restrict visibility for read-only and non-active accounts, and review drafts on pages those groups can see. Deny is only a partial workaround because it leaves the logged-in actor paths untouched.
After patching, test the authorization boundary and review drafts that predate the change. Preserve evidence for any suspicious draft or revision. A clean patch result and a clean content review answer different questions, and both belong in the closure record.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.