GROWI EUVD-2026-66213

The attacker must possess a valid GROWI attachment identifier (a MongoDB ObjectID exposed in the /attachment/:id or /download/:id URL path). No authentication, special headers, or specific configuration is required - the bypass applies to all default GROWI deployments running versions before 8.0.2. Exploitation is limited to information disclosure: the attacker cannot write, modify, or delete content. The realistic limiting factor is identifier availability: former authorized users retain identifiers from their access period, and the identifiers may also have been exposed in browser history, server logs, or shared links. The vulnerability is not exploitable by a fully blind attacker who has never interacted with the GROWI instance and has no other path to obtain an identifier.

The CVSS 4.0 score of 8.7 with AV:N/AC:L/PR:N/UI:N accurately reflects that exploitation requires no authentication and no special technical complexity once an attachment identifier is in hand. The sole practical barrier to exploitation is identifier possession: an attacker needs to know or recover a valid attachment ID, which is feasible for former employees, leaked URLs, or browser history. EPSS data is not provided, limiting probabilistic exploitation forecasting. The vulnerability is not in the CISA KEV catalog and no public exploit code has been disclosed, suggesting it has not yet seen broad automated exploitation. Despite the high score, real-world risk is gated by identifier accessibility - organizations whose GROWI instances are only reachable internally, or whose attachment IDs have never leaked externally, face lower practical exposure than those serving GROWI publicly. The confidentiality-only impact (no integrity or availability) bounds the blast radius to information disclosure from private wiki pages.

A former GROWI user whose account was deprovisioned retains browser history containing an attachment URL of the form https://wiki.example.com/attachment/64a3f2b1c8e9d0001234abcd. That user submits a GET request to the URL without any session cookie; because retrieveAttachmentFromIdParam skips the permission check for unauthenticated requests, the server responds with the file contents from the now-private page. The attacker extracts confidential documents without any credentials or active account.