CVE-2026-109848 and the Governance of Sensitive Wiki History

The remediation for CVE-2026-109848 is a GROWI upgrade to 8.0.7 or later, but the incident also raises a governance question. Organizations often control access to the current version of a page while treating old revisions as a lower-priority archive.

GROWI 4.5.5 through 8.0.6 broke that assumption when an update request could use a revision ID without proving the revision belonged to the target page.

History is live data

A revision is live content with its own access history. The advisory states that tags.update could save a restricted revision's body as a new revision of a page the attacker could edit and return it in savedPage.

A user with a normal editing account could therefore bring old or restricted text into a page they controlled. That changes how organizations should classify wiki history.

Removed credentials, incident notes, customer details, source code, and unpublished security findings may still exist in earlier revisions. If those revisions are covered by a different access policy than the current page, the authorization model needs to reflect that distinction.

The access-control lesson

An application can perform two checks in the wrong order or at the wrong object. GROWI checked whether the caller could view the page but did not verify that the revision was part of that page.

CWE-639 describes the pattern as authorization bypass through a user-controlled key. The key is not necessarily secret; it is an identifier the request can select.

The fixed release adds the relationship check. For tags.update, a foreign revision is rejected. The page update route ignores it in the conditional diff path described by the advisory.

This is the right boundary: permission on a parent object plus ownership of the child object. Security teams should ask for that same check when reviewing APIs that accept nested IDs.

Preconditions still define risk

The attacker must be authenticated and must not be read-only. They also need to know or guess the restricted revision ID. Revision IDs are MongoDB ObjectIds rather than secret tokens, but the attacker still needs a starting point.

JVN rates the issue 2.3 under CVSS 4.0 and 4.2 under CVSS 3.0, reflecting those conditions. The reviewed sources do not report known exploitation.

Low severity scores can lead an organization to postpone action. A better prioritization uses content sensitivity. A page with a public product description may present little concern. A page that contains access procedures, incident response notes, or customer data may justify immediate patching and a review of editing rights.

Governance controls around the patch

1. First, inventory every GROWI deployment and confirm that the running artifact is 8.0.7 or later. Do not accept a container tag alone; capture the image digest and version evidence.
2. Second, review who can edit pages and who can see revision history. Broad editing rights increase both the location where copied content can be stored and the number of accounts that can exercise the vulnerable workflow.
3. Third, reduce unnecessary identifier exposure where practical. Do not treat this as a fix. It is a defense-in-depth measure that makes targeted revision selection harder.
4. Fourth, preserve enough application and collaboration logs to investigate a mismatched page and revision if one is suspected.
5. Finally, review current governance for sensitive pages. Use separate access boundaries for highly sensitive material, minimize historical copies, and remove credentials or personal data when retention is no longer required.

This work supports the vendor patch.

External exposure and scope

ZoomEye's title="GROWI" query returned 401 title matches on 2026-11-14. The CVE filter returned 0. The title count is product-exposure context, not confirmed vulnerable installations. Internal inventory and version checks remain necessary.

The technical fix is small compared with the governance work around it. GROWI 8.0.7 enforces the page-revision relationship. Organizations still need to decide which history is sensitive, who may edit it, how long it is retained, and how a copy outside the original page is detected and handled.

References

• [1] JVN#51223238: Multiple vulnerabilities in GROWI
• [2] GROWI vulnerability notice
• [3] GitHub advisory GHSA-pqx5-gx68-83h4
• [4] GROWI v8.0.7 release
• [5] ZoomEye GROWI title query