Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T05:18:26.283Z",
  "pubdate": "2026-08-26T05:18:26.283Z",
  "executiveSummary": "A broken access control vulnerability exists in GROWI that permits unauthenticated users to retrieve restricted file attachments. The vulnerability stems from an insecure conditional check within the attachment retrieval process, which fails to enforce page-viewer permissions when a session is absent.\nThis flaw allows any network-adjacent attacker who possesses a valid attachment identifier to bypass authorization protocols. By targeting the /attachment/:id and /download/:id routes, an attacker can access sensitive documents belonging to private pages regardless of the user's actual permission level. The impact is a critical compromise of confidentiality, as private information, potentially containing sensitive enterprise data, is exposed to unauthorized entities. The vulnerability affects GROWI versions prior to 8.0.2. Remediation requires an upgrade to version 8.0.2 or higher, which correctly enforces access control policies for both authenticated and unauthenticated request contexts.",
  "technicalDetails": "The root cause of the vulnerability resides in the implementation of the retrieveAttachmentFromIdParam function located within apps/app/src/server/routes/attachment/get.ts. Analysis of the source code reveals that the authorization middleware responsible for verifying page-viewer permissions is gated by a conditional check that validates the presence of an authenticated user session. Specifically, the function logic explicitly skips the permission enforcement step if the 'user' object is null.\nIn the affected versions, the application design fails to apply a default-deny policy for anonymous requests. Consequently, when a request is made to the /attachment/:id or /download/:id endpoints without a session, the application bypasses the standard access control list (ACL) verification associated with the page that owns the attachment. Because the attachment identifier is provided directly via the URL path, an attacker does not require a valid session or elevated privileges to retrieve the file resource.\nThe attack flow proceeds as follows: An attacker identifies or captures an attachment identifier, which may have been previously exposed via logs, browser history, or metadata from past access. The attacker then submits a GET request to either /attachment/:id or /download/:id using the target identifier. Since the request lacks an authentication header or session cookie, the server-side code evaluates the condition in retrieveAttachmentFromIdParam, finds no user context, and proceeds to serve the requested file stream to the client. This bypasses the security boundary that should verify if the requestor has 'viewer' rights on the parent document.\nThis behavior persists regardless of whether the target page is marked as private. The risk is compounded by the fact that identifiers may be salvaged from users whose access rights were revoked, effectively rendering permission management ineffective for static file assets. The vulnerability is addressed in version 8.0.2, which refines the logic to ensure that authorization checks are performed consistently across all requests, including anonymous ones, except in cases where a valid share link has explicitly authorized access to the associated resource."
}