Unauthenticated file reads in GROWI become a model for auditing attachment permission checks

An unauthenticated file read in GROWI

GROWI, the wiki software, has patched a flaw that allowed remote, unauthenticated attackers to read files attached to non-public pages. According to a dev.to walkthrough published alongside the fix, the vulnerability — tracked as CVE-2026-100727 — affects versions before v7.5.5, but only when the file upload setting is configured to use "Local" storage. The Japanese advisory JVN#24352487 classifies the issue as CWE-552, describing it as improper access control, and scores it 6.9 under CVSS 4.0 and 5.3 under CVSS 3.0. The vendor shipped the fix in version 7.5.5 on 2026-10-05, after a coordinated report through JPCERT/CC.

The mismatch at the center of the bug

The dev.to author frames the CVE as a clean specimen of a wider class of defect: an application applies a permission check to the page, while the stored file that page references gets a weaker check, or none at all. The article's central question for any endpoint that returns stored bytes is which permission decision gates it, and which object that decision is evaluated against. The right answer names the owning record, not the storage path. A path-based check answers a different question — whether the requester can name the object — and being able to name something does not establish the right to read it.

Where the pattern hides

The walkthrough lists five places this page-versus-file gap tends to appear:

• Static file routes registered outside the application's request pipeline, which never pass through the middleware carrying the session
• Download endpoints that accept an object identifier and read from it directly
• Signed-URL features whose signature covers the path but not the current permission state, leaving links usable after access has been revoked
• Attachment rendering inside editors, which may fetch referenced files through a separate handler
• Archived or exported content bundles that carry copies of the original paths but not the original access checks

A repeatable review

The audit the author proposes has five steps:

1. Enumerate every route that can return file-like content, including routes mounted by libraries and static handlers.
2. For each route, record the gating decision and the object that decision reads.
3. Compare that object with the object the user interface protects.
4. Test anonymously against a private-page attachment and record the outcome.
5. Repeat after every upgrade that changes file handling, since a refactor can shift where the check sits even if the check itself still exists.

For this CVE, the affected combination is specifically GROWI before v7.5.5 with local uploads enabled. The author notes that other platforms need their own mapping of checks to endpoints, but the review method transfers unchanged.

Scale of exposure and remediation

A ZoomEye query on 2026-10-05 for hosts whose page title displays the product name returned 401 records. The author cautions that this figure describes product surfaces, not vulnerable instances, and cannot report which upload backend each host runs.

Remediation is to patch to v7.5.5 and confirm the fix by retesting the anonymous request path. Where local storage remains in use, the configuration should be verified after every future upgrade, and keeping an inventory of attachments current makes it easier to scope any disclosure window quickly.

Why it matters

This bug class needs no exploit chain and no credentials: a single request to the wrong endpoint exposes private files. It recurs in any system where access-controlled records reference stored bytes — wikis, CMSes, ticketing tools, note-taking apps — because developers naturally protect the record and forget the file it points to. As the dev.to article argues, running this review costs far less than learning about the gap during an incident, and a route-by-route audit with anonymous testing against a private attachment is small enough to fold into an upgrade checklist rather than treated as a one-off security project.