GROWI CVE-2026-25083

Attacker must hold a valid authenticated GROWI session (PR:L) on the target instance and must know - or be able to enumerate - the identifier of a shared AI assistant whose threads/messages they want to access; the OpenAI assistant integration must be enabled and in use on the instance, since the vulnerable endpoints only exist when that feature is configured. Limiting factors: deployments that do not enable the OpenAI assistant feature are not exposed, instances restricted to a small trusted user set materially reduce abuse potential, and the bug grants peer-level cross-user access rather than privilege escalation to admin. No user interaction is required (UI:N) and attack complexity is low (AC:L) once those preconditions are met.

Signals diverge meaningfully and should be weighed together. CVSS 4.0 rates this 8.7 (High) driven by AV:N/AC:L/PR:L/UI:N with VC:H/VI:H, reflecting that any low-privilege authenticated account can both read and tamper with other users' AI conversations over the network without user interaction. EPSS is 0.04% (12th percentile) and the vulnerability is not on the CISA KEV list, indicating no observed mass exploitation. The PR:L requirement is the principal limiter - exploitation requires a valid GROWI login plus knowledge of a shared AI assistant identifier (which is enumerable inside an organization), so this is primarily an insider/multi-tenant confidentiality risk rather than an internet-spray target. For deployments where the wiki holds sensitive business conversations with the AI assistant (HR, legal, source-code prompts), the real-world impact is high despite low EPSS; for small single-team installs it is materially lower. No conflicting data was observed in CVSS vs. description.

An employee logs into the corporate GROWI wiki with their normal account, learns a colleague's shared AI assistant identifier from a wiki page or by enumeration, and then issues direct API calls to the OpenAI thread/message endpoints using that identifier to read confidential prompts (e.g., draft contracts, code snippets, personnel matters) and silently inject misleading messages into the conversation. No public exploit code is identified, but because the bug is a missing authorization check on a documented REST surface, weaponization requires only standard HTTP tooling once an attacker has a valid session.