CVE-2026-100727 in GROWI
Summary
by MITRE • 10/05/2026
An improper access control vulnerability exists in GROWI, which allow an unauthenticated attacker to read files contained in non-public pages of the affected product when the file upload setting is configured as "Local".
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The identified security flaw resides within the GROWI wiki platform and represents a critical failure in access control mechanisms. This vulnerability specifically impacts environments where the file storage configuration is set to Local, meaning files are stored directly on the server's filesystem rather than in an external object store or cloud service. The core issue stems from how the application handles requests for static assets associated with pages that have restricted visibility settings. In a properly secured system, any attempt by an unauthenticated user to access resources belonging to private or non-public content should be denied at the authentication and authorization layer before the resource is served. However, in this instance, the server fails to enforce these restrictions when serving files via its static file handler, effectively bypassing the page-level permissions that are otherwise enforced for HTML rendering and API endpoints.
From a technical perspective, this vulnerability allows an unauthenticated attacker to read arbitrary files contained within non-public pages of the affected GROWI installation. By constructing specific HTTP requests targeting the local storage paths associated with private documents, such as PDFs, images, or text files uploaded by users on restricted wiki spaces, an external actor can retrieve their contents without valid credentials. This bypass occurs because the static file serving component likely operates independently from the main application's authentication middleware, treating all incoming file requests as public unless explicitly checked against user session data, which it fails to do for this specific endpoint or path structure. The attacker does not need prior knowledge of a valid username or password; they only require an understanding of the URL patterns used by GROWI to serve local files, often derived from inspecting network traffic on publicly accessible pages that reference private assets.
The operational impact of this vulnerability is significant, particularly for organizations relying on GROWI for sensitive internal documentation, intellectual property storage, or confidential project planning. Since an unauthenticated user can access these files, it leads to a direct compromise of data confidentiality. Sensitive information such as proprietary code snippets, strategic business plans, personal identifiable information, or secure credentials stored within documents could be exfiltrated by malicious actors scanning the internet for vulnerable instances. This exposure undermines trust in the platform and may violate regulatory compliance requirements regarding data protection, such as GDPR or HIPAA, depending on the nature of the leaked content. Furthermore, if these files contain metadata or embedded information that reveals internal network structures or user identities, it can facilitate further reconnaissance and targeted attacks against the organization's infrastructure.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce proper restrictions on unauthenticated users regarding sensitive resources. It also maps to MITRE ATT&CK technique T1078 Valid Accounts if we consider that while no account is needed for this specific exploit, the attacker gains access to data typically protected by valid accounts, effectively bypassing authentication controls. In some contexts, it may also relate to CWE-538 Insertion of Sensitive Information into Log File or similar exposure issues depending on how logs are handled, but primarily it is a classic authorization failure where security boundaries defined at the application logic level do not extend to the static resource serving layer.
To mitigate this risk, administrators must immediately apply any available patches provided by the GROWI development team that address this access control bypass in local file storage handling. If patching is not immediately feasible, temporary mitigations should include restricting direct access to the directory where local files are stored via web server configuration, such as Nginx or Apache, ensuring that only authenticated proxies can serve these assets. Additionally, reviewing and hardening the static file serving configurations to ensure they inherit authentication checks from the main application is crucial. Organizations should also audit their GROWI instances for this specific vulnerability by attempting to access known private page attachments using unauthenticated requests in a controlled manner during maintenance windows. Long-term strategies involve considering migration away from local storage if possible, as external object stores often have more robust and standardized authentication integrations that reduce the attack surface associated with direct file serving vulnerabilities. Regular security assessments and penetration testing should be conducted to identify similar misconfigurations across other web applications in the environment.