Vikunja CVE-2026-68581

The attacker must hold a valid, authenticated Vikunja user account with write access to at least one project (required to create link shares). The link-share feature must be enabled on the instance (it is enabled by default). The attacker must be able to discover the target user's numeric ID, which is possible via the authenticated user search endpoint - this limits attacks to users who are searchable within the instance. The core operational constraint is that the attacker must create link shares sequentially until the link-share ID counter matches the target user's numeric ID; this is practical for low-numbered user IDs (e.g., IDs 1-50 require at most a few dozen share creations) but becomes progressively expensive for high user IDs on active instances where the link-share counter may already exceed the target. No special server configuration, non-default settings, or elevated privilege beyond a standard authenticated account is required beyond the link-share write access described.

The CVSS 4.0 score of 8.6 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N reflects the high-impact outcome once the ID collision is achieved, and the network-accessible attack surface. However, the attack carries a sequential prerequisite: the attacker must create link shares on a project they control until the link-share ID counter reaches the target user's numeric ID. This adds meaningful operational friction - targeting high-numbered user IDs could require hundreds or thousands of share creations - suggesting the effective attack complexity is higher than AC:L implies in practice, particularly for users registered later in a large instance. For small or lightly-used instances with low user IDs, exploitation is far more feasible. No EPSS score was provided; absent KEV listing and public POC, immediate mass-exploitation risk is low, but the impact ceiling (API-level account takeover with arbitrary token scopes) is severe for targeted attacks. The confidentiality and integrity impacts are both high - the attacker can exfiltrate existing token metadata and issue new tokens with full permission scopes under the victim's identity. No availability impact applies.

An authenticated attacker with a low-privilege Vikunja account uses the authenticated user search API to identify a target user's numeric ID - for example, ID 7. The attacker then creates link shares on a project they own in a loop until the link-share auto-increment sequence assigns ID 7 to a new share, then extracts the resulting link-share JWT. Presenting this JWT to PUT /api/v1/tokens, the attacker mints a new API token under the victim's identity with read_all and update scopes on tasks, achieving persistent API-level access to the victim's data without any interaction from the victim.