DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

Auditing file-serving permission checks, using CVE-2026-100727 as the model

#cybersecurity #infosec #security

Auditing file-serving permission checks, using CVE-2026-100727 as the model

Why this audit is worth running

CVE-2026-100727 affects GROWI versions before v7.5.5 and allows a remote unauthenticated attacker to read files contained in non-public pages when the file upload setting is configured as "Local". The advisory JVN#24352487 classifies it as CWE-552 and scores it 6.9 on CVSS 4.0 and 5.3 on CVSS 3.0. The vendor fixed it in version 7.5.5, released on 2026/10/05, after a coordinated report through JPCERT/CC.
The GROWI case is a clean example of a class of bug that appears across many platforms: an application applies a permission check to the page and a weaker one, or none, to the stored file the page references. Reviewing for that pattern is cheap compared with discovering it through an incident.

The check that matters

For every endpoint that returns stored bytes, ask which permission decision gates it and which object that decision is evaluated against. The correct answer names the owning record, not the storage path. A path-based check answers a different question, namely whether the requester can name the object, and naming an object is not an authorisation decision.

Where the pattern hides

  • Static file routes registered outside the application's request pipeline, which never pass through the middleware that carries the session
  • Download endpoints that accept an object identifier and read it directly
  • Signed-URL features whose signature covers the path but not the current permission state, so a link stays valid after the owner revokes access
  • Attachment rendering inside editors, which may fetch referenced files through a separate handler
  • Archived or exported content bundles that reproduce the original paths without the original checks

A repeatable review

  1. Enumerate every route that can return file-like content, including routes mounted by libraries and by 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 the test after each upgrade that changes file handling, since a refactor can move the gate without removing it.

Affected products and scope

For this CVE specifically, the affected combination is GROWI before v7.5.5 with the file upload setting configured as "Local". Other platforms require their own mapping of the check to the endpoint, and the review method above applies to them without modification.

Exposure context

On 2026-10-05 a ZoomEye query for hosts that display the product name in the page title returned 401 records:
Search Dork: title="GROWI"
The figure describes product surfaces, not vulnerable instances, and it cannot report which upload backend each host uses.

Remediation and mitigations

Patch to GROWI v7.5.5. Confirm the fix by testing the anonymous request path. Where local storage remains in use, treat it as a configuration to verify after every future upgrade, and keep the attachment inventory current so a disclosure window can be scoped quickly.

References

Top comments (0)