Vikunja EUVD-2026-78652

Exploitation requires possession of a valid read-only link-share token for a project on the target Vikunja instance (the CVSS vector's PR:L reflects that low-privileged, token-bearing context rather than an anonymous request), plus network reachability to the v2 API endpoints. The instance must be running a Vikunja version before 2.6.0, and the affected routes - the project users endpoint and the global user search endpoint - must be reachable by the token holder. What limits real-world exploitation: no valid share token means no access at all, so instances with public link sharing disabled, with link shares restricted to trusted collaborators, or with tokens that have expired/been revoked are not exploitable in practice; the impact is confined to confidentiality (usernames and project membership), is not automatable into data modification or code execution, and the enumeration is only useful as a precursor to other attacks.

CVSS 3.1 scores this 4.3 with AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N - network-reachable and trivial to execute, but gated behind a low-privilege prerequisite and producing only limited confidentiality impact with no integrity or availability effect. The PR:L metric is the decisive real-world constraint: an attacker must already possess a valid read-only share token, which materially narrows the population of viable attackers to those who received, intercepted, or found a leaked/shared link. No EPSS score, no CISA KEV listing, and no confirmed POC were supplied, so there is no signal of active or widespread exploitation; this should be treated as a hygiene/defense-in-depth patch rather than an emergency. The main risk is not the disclosure itself but its use as reconnaissance: confirmed usernames and project membership lists feed credential-stuffing, password-spray, and targeted phishing campaigns. Note that the vulnerability class (user enumeration) frequently evades detection because the requests are well-formed and authorized at the token level, so detection depends on log volume anomalies rather than error responses. Data gaps: EPSS percentile, exploit maturity, and whether the share token alone (without any account) is sufficient are not independently confirmed from the supplied references.

An attacker obtains a read-only project share link - through a leaked URL, a public board, a chat message, or a shared browser session - and replays its token against the Vikunja v2 API. Using the project users endpoint they dump the membership list of projects visible to that token, then query the global search endpoint repeatedly to confirm which guessed usernames exist on the instance. The confirmed account inventory is then used for credential stuffing, password spraying, or convincing phishing that references the victim's real project context.