CVE-2026-80191 in Growi
Summary
by MITRE • 08/26/2026
GROWI applies its page-viewer permission check to attachment requests only when the request carries an authenticated user. retrieveAttachmentFromIdParam in apps/app/src/server/routes/attachment/get.ts guards the check with a condition requiring the user to be non-null, so a request that carries no session skips the check entirely and the handler returns the file. The routes reached this way, /attachment/:id and /download/:id, take the attachment identifier from the path, so an unauthenticated caller who has an attachment identifier receives the file regardless of whether the page owning it is private and regardless of whether that caller would be permitted to view the page. Identifiers can be retained by a user whose access was later removed, or recovered from anywhere the identifier was previously exposed. Version 8.0.2 runs the check for authenticated and unauthenticated requests alike, skipping it only where a valid share link has already bound the requested file to that link's page.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability in GROWI represents a critical authentication bypass within its attachment retrieval mechanism, specifically affecting versions prior to 8.0.2. The core technical flaw resides in the implementation of the retrieveAttachmentFromIdParam function located in apps/app/src/server/routes/attachment/get.ts. This handler is responsible for serving files associated with wiki pages but contains a logical error regarding permission enforcement. The code explicitly guards its page-viewer permission check by requiring that the current user object be non-null. Consequently, when an HTTP request arrives without any session data or authentication tokens, the system fails to instantiate a valid user context and treats the requester as anonymous. Because the conditional logic only executes the authorization verification for authenticated sessions, unauthenticated requests bypass this security control entirely. This design oversight allows any external actor who possesses a direct attachment identifier to download sensitive files without needing credentials or explicit permissions.
The operational impact of this flaw is significant because it undermines the confidentiality guarantees provided by GROWI’s access control policies. The affected endpoints, /attachment/:id and /download/:id, accept an attachment identifier directly from the URL path parameters rather than resolving it through a page context that would enforce view restrictions. An attacker who obtains such an identifier can retrieve the associated file regardless of whether the parent page is configured as private or restricted to specific user groups. The persistence of this risk stems from how identifiers are managed; even if a user’s access rights are revoked, they may retain knowledge of previously exposed attachment IDs. Furthermore, these identifiers might be leaked through various vectors such as browser history, server logs, email notifications containing direct links, or third-party integrations that reference the file directly. This creates a persistent attack surface where historical data exposure leads to ongoing unauthorized access capabilities for any party aware of the identifier structure.
From a classification perspective, this vulnerability aligns with CWE-284, which describes Improper Access Control, specifically illustrating how authorization checks are not applied uniformly across all request types. It also maps closely to ATT&CK technique T1078, Valid Accounts, although in this case, the exploitation relies on the absence of valid accounts rather than their presence, effectively exploiting a gap in anonymous access handling. The flaw highlights a common architectural pitfall where security logic is tightly coupled with authentication state without considering edge cases involving unauthenticated traffic. Developers often assume that sensitive operations require login, but when APIs or file handlers are exposed publicly, they must explicitly deny access to unauthorized entities rather than skipping checks for them.
Mitigation strategies focus on immediate patching and architectural review. The primary remediation is upgrading GROWI to version 8.0.2 or later, where the permission check logic has been corrected to apply uniformly to both authenticated and unauthenticated requests. In this updated implementation, the system only skips the page-viewer check if a valid share link already binds the requested file to that specific link’s context, ensuring that public sharing is handled via explicit token-based authorization rather than by omitting checks entirely. For organizations unable to patch immediately due to operational constraints, temporary mitigations include restricting direct access to these endpoints at the web server or reverse proxy level if possible, and auditing logs for unusual patterns of attachment downloads from unauthenticated sources. Additionally, implementing strict rate limiting on file download endpoints can help mitigate bulk scraping attempts by attackers who have obtained multiple identifiers through reconnaissance activities.