BuildNot yet confirmed elsewhere1 publisher2 min readPublished
GROWI 7.5.5 closes an anonymous file read on wikis that store uploads locally
GROWI, Inc. shipped GROWI 7.5.5 to close CVE-2026-100727, a flaw letting visitors with no account read files from non-public pages on local-upload wikis. Because the read needs no login, any reachable Local-mode instance on an older release is a patch-now item.
The Engineer · Build desk
What happened
- Exposure needs two things at once: a GROWI release earlier than 7.5.5 and the file upload setting configured as Local; instances on an external storage backend fall outside it.
- Japan's JVN published the coordinated advisory, JVN#24352487, on October 5, with JPCERT/CC coordinating the report.
- A ZoomEye search for GROWI in page titles returned 401 hosts on October 5, a count that shows neither their versions nor their upload backends.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Operators who cannot upgrade immediately have one stopgap: move attachments off the Local backend to external storage, because the affected code path is tied to that setting.
- cost Every credential or token stored as an attachment on a non-public page has to be rotated, because the dev.to post says an anonymous read of it is indistinguishable from the owner's.
- constraint With no account involved, incident review cannot attribute access to a person, so it narrows to which files were reachable and for how long.
GROWI lets the administrator choose where attachments live when the instance is configured [8]. Under the Local option, the application writes uploads into directories it owns and serves them back to readers itself [9]. Permissions attach to the page that references a file [10]. For that permission to protect the file, the code serving the file has to look it up on every request. According to a dev.to write-up of the JVN advisory, in Local mode a stored file's reachability followed where the file was stored, and the referencing page's permission check did not decide who got it [10]. JVN records the weakness as CWE-552, Files or Directories Accessible to External Parties [5].
The vector strings show where the moderate scores come from. Under CVSS 4.0 the advisory gives "AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N", and under CVSS 3.0 it gives "AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N" [19]. Confidentiality is the only impact rated above N in either [19]. The dev.to post confirms there is no write primitive and no execution primitive [7]. A score built that way measures the type of harm. The size depends on the files, and the post lists what wiki attachments tend to be: files on draft pages, internal runbooks, meeting notes, scanned contracts and exported configuration [17].
I'd schedule this ahead of higher-scored bugs that require an account. PR:N, AC:L and UI:N mean the only precondition is a network path to a Local-mode server running an old release [19][3].
The disclosure was handled well. JVN credits GROWI, Inc. as the reporter [18]. Of the ways a vendor can learn about an anonymous file read, finding it in-house is the cheap one. The fixed release and the advisory are both dated October 5, 2026, so operators got the description and the fix together [20].
After upgrading, the post says to go back over the attachment settings from before the upgrade and confirm that any page that used to expose files now refuses a reader who has no session [13]. The instance reporting 7.5.5 shows the code changed [13]. A refused anonymous request for a known attachment on a non-public page shows the behaviour changed.
What to watch
- Whether GROWI or JVN publishes request patterns that let operators tell from logs if a non-public attachment was fetched without a session.
- A follow-up scan of the 401 self-identified GROWI hosts that reads their versions and counts how many remain below 7.5.5.
- Whether GROWI's 7.5.5 release notes describe how file requests are now checked against page permissions.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption30
- Hype gap+5
- Incentives
- Insufficient
- Confidence50
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
GROWI, the wiki and collaboration platform published by GROWI, Inc., received a security fix in version 7.5.5 on October 5, 2026.
- [2]
GROWI 7.5.5 closes CVE-2026-100727, an access-control defect that lets an unauthenticated visitor read files kept by pages the platform does not expose publicly.
- [3]
A deployment is exposed when two conditions hold at once: it runs a GROWI version earlier than 7.5.5, and the file upload setting is configured as 'Local'. An instance that keeps uploads in an external storage backend does not match the affected configuration.
- [4]
Japan's JVN published the coordinated advisory as JVN#24352487 on 2026/10/05; JPCERT/CC coordinated the report.
- [5]
The weakness is recorded as CWE-552, Files or Directories Accessible to External Parties.
- [6]
The advisory lists a CVSS 4.0 base score of 6.9 and a CVSS 3.0 base score of 5.3.
- [7]
The attacker reaches the service over the network, holds no account and needs no user interaction; impact stays inside confidentiality, with no write primitive and no execution primitive.
- [8]
GROWI builds file upload on a configurable storage backend; administrators decide where attachments live when they configure the instance.
- [9]
Under the Local option the application writes uploaded content into directories it owns and serves the content back to readers.
- [10]
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.
- [11]
A ZoomEye query for hosts whose HTML title contains GROWI (title="GROWI") returned 401 records collected on 2026-10-05; the figure does not show which run a vulnerable version or which upload backend each uses.
- [12]
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.
- [13]
After the instance reports the new version, re-check the attachment settings in place before the upgrade and confirm that pages which previously exposed files can no longer be reached without a session.
- [14]
According to the dev.to write-up, the advisory offers no reliable way to tell whether a read occurred.
- [15]
Operators should review which non-public pages held attachments during the exposure window and rotate any credential or token stored as an attachment on those pages, because a read of that object is indistinguishable from a read by its owner.
- [16]
Many access-control bugs need a valid low-privilege account, which 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.
- [17]
On a wiki, the exposed objects are often attachments on draft pages, internal runbooks, meeting notes, scanned contracts, or exported configuration.
- [19]
The CVSS 4.0 vector is AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N and the CVSS 3.0 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.
- [20]
The fixed release (7.5.5) and the JVN advisory carry the same date, October 5, 2026.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toCVE-2026-100727: unauthenticated file read in GROWI's local upload mode
1 article · October 9, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Access Control VulnerabilitiesFollow
- Wiki software securityFollow
- Coordinated Vulnerability DisclosureFollow