CVE-2026-100727: unauthenticated file read in GROWI's local upload mode
GROWI, the wiki and collaboration platform published by GROWI, Inc., received a security fix in version 7.5.5 on October 5, 2026. The release closes CVE-2026-100727, an access-control defect that lets an unauthenticated visitor read files kept by pages the platform does not expose publicly. The defect applies to deployments that store uploads with the local file system option.
Vulnerability overview
Japan's JVN published the coordinated advisory as JVN#24352487 on 2026/10/05. JPCERT/CC coordinated the report, and JVN credits GROWI, Inc. as the reporter. The weakness is recorded as CWE-552, Files or Directories Accessible to External Parties. The advisory lists two scoring vectors:
- CVSS 4.0:
AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N, base score 6.9 - CVSS 3.0:
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, base score 5.3 Both describe one situation. The attacker reaches the service over the network, holds no account, and needs no user interaction, while the resulting impact stays inside confidentiality. Integrity and availability are untouched, so this is a disclosure bug rather than a route to remote code execution.
Mechanism and exploitation conditions
GROWI builds file upload on a configurable storage backend. Administrators decide where attachments live when they configure the instance, and the advisory focuses on the case where that choice is the local option. Under that arrangement the application writes uploaded content into directories it owns and serves the content back to readers.
The defect is that reachability of a stored object follows the location of the file instead of the permission check attached to the page that references it. A remote unauthenticated attacker can request files belonging to non-public pages and receive their contents. Two conditions must hold at the same time for a deployment to be exposed:
- GROWI runs a version earlier than 7.5.5
- The file upload setting is configured as "Local" An instance that keeps uploads in an external storage backend does not match the affected configuration the advisory describes.
Impact
The attacker gains read access to files the operator never published. On a wiki, those objects are often attachments on draft pages, internal runbooks, meeting notes, scanned contracts, or exported configuration. The advisory scores confidentiality only, and that matches the outcome: no write primitive, no execution primitive, and no authenticated session required.
The missing login requirement changes the operational picture. Many access-control bugs need a valid low-privilege account, which at least leaves an audit trail tied to a known identity. Here the request can arrive anonymously, so the useful question after detection is which files were reachable and for how long.
Affected products and scope
The advisory names GROWI versions prior to v7.5.5 and notes that exposure depends on the "Local" upload setting. It does not enumerate individual page-level configurations beyond that. Operators should treat the version as the first filter and the storage configuration as the second. A deployment on an older release that uses an external upload backend falls outside this specific CVE even though its version number sits below the fix.
Exposure context
A ZoomEye query for hosts whose HTML title contains the product name returned 401 records, collected on 2026-10-05:
Search Dork: title="GROWI"
That figure counts assets that identify themselves as GROWI through the page title. It does not show that any of them run a vulnerable version, and it says nothing about which upload backend each one uses. Treat the number as a starting inventory for verification rather than a count of confirmed vulnerable hosts.
Remediation and mitigations
Update to GROWI v7.5.5. After the instance reports the new version, re-check the attachment settings that were in place before the upgrade and confirm that pages which previously exposed files can no longer be reached without a session. Where an immediate upgrade is not possible, the effective short-term control is to move uploads off the local backend, because the affected code path is the one tied to that setting.
Two follow-up checks are worth running after patching. Review which non-public pages held attachments during the exposure window, since the advisory offers no reliable way to tell whether a read occurred. Rotate any credential or token that was stored as an attachment on those pages, because a read of that object is indistinguishable from a read by its owner.
Top comments (0)