CVE-2026-80191: GROWI before 8.0.2 Missing Authorization on Attachment Retrieval for Unauthenticated Requests
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
GROWIto a version that resolves this vulnerability.Fixed in 8.0.2 - Configuration
Remove/adjust the condition that currently requires the user to be non-null in retrieveAttachmentFromIdParam so that unauthenticated requests to /attachment/:id and /download/:id do not bypass the permission check (allow only when the requested file is already bound by a valid share link).
GROWI route handler (apps/app/src/server/routes/attachment/get.ts; retrieveAttachmentFromIdParam) Attachment retrieval authorization check condition = Run permission check for both authenticated and unauthenticated requests; skip only when a valid share link has already bound the requested file to that share link's page
Event History
Frequently Asked Questions
Who can retrieve a private attachment?
Any unauthenticated remote caller who knows an attachment identifier can retrieve the corresponding file through /attachment/:id or /download/:id. The caller does not need permission to view the page that owns the attachment.
What does an attacker need to exploit this issue?
The attacker needs an attachment identifier. Identifiers may be retained by users whose access was later removed or recovered from places where they were previously exposed; no account, session, or user interaction is required.
Are share-link downloads affected in the fixed behavior?
Version 8.0.2 applies the permission check to both authenticated and unauthenticated requests. It skips the check only when a valid share link has already bound the requested attachment to that share link's page.
How can I determine whether an instance is vulnerable?
Versions before 8.0.2 are affected. On an affected instance, an unauthenticated request to /attachment/:id or /download/:id with an identifier for an attachment on a private page returns the file even though the requester cannot view that page.