CVE-2026-68581
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk36th percentile - higher than 36% of all known CVEs
Summary
Vikunja versions 0.22.0 through 2.3.0 fail to validate the principal type in API token management. A link-share JWT with a matching ID can be used to manage another user's tokens.
Risk Assessment
An authenticated attacker can obtain a victim's API tokens with arbitrary scopes, leading to unauthorized access to data and operations.
Recommendation
Upgrade Vikunja to version 2.4.0, which includes a fix for this vulnerability.
Other vulnerabilities in Vikunja
See all- CVE-2026-56765Critical
A vulnerability in Vikunja before version 2.2.1 allows unauthorized access to share hashes and downloading/deleting all file attachments across the instance. An authorization flaw in the LinkSharing.ReadAll and GetTaskAttachment endpoints enables privilege escalation to admin-level shares.
- CVE-2026-62376High
Vikunja versions prior to 2.4.0 store password-reset, email-confirmation, and account-deletion tokens in the user_tokens table in plaintext. An attacker with read access to the database can immediately use pending tokens to take over user accounts without knowing passwords. Version 2.4.0 fixes the issue.
- CVE-2026-62367High
Vikunja versions 1.0.0 through 2.3.0, when an administrator enables the per-provider emailfallback option on an OpenID Connect provider, links an SSO login to a pre-existing local account using only the email claim from the IdP, without checking email_verified or requiring the account password. An attacker with a token carrying a victim's email can log in as that victim without consent. Version 2.4.0 fixes the issue.
- CVE-2026-57458High
Vikunja version 2.3.0 allows a scoped API token limited to the oauth.authorize permission to call POST /api/v1/oauth/authorize, obtain an OAuth authorization code, and exchange it for a normal bearer JWT and refresh token. The resulting credentials are not restricted by the original token's permissions, granting access to routes outside its declared scope. Version 2.4.0 fixes the vulnerability.
- CVE-2026-91985High
Vikunja before 2.6.0 fails to properly restrict access to the link-share hash field in single-share read endpoints, allowing read-only members to obtain the share's secret credential. Attackers can exchange the disclosed hash for a link-share JWT at the share's permission level to escalate privileges and perform unauthorized writes or administrative actions.
- CVE-2026-91984Medium
Vikunja before 2.6.0 fails to validate that user-supplied project_view_id in task-position requests belongs to the task's project. Authenticated attackers can insert task position rows into arbitrary other tenant project views via POST or PUT task-position endpoints.
- CVE-2026-91983Medium
Vikunja before 2.6.0 contains an API token scope bypass vulnerability in task read endpoints where authorization fails to inspect query string parameters. Attackers with limited token scopes can use the expand parameter to access restricted data like comments, reactions, and time entries without proper permission verification.
- CVE-2026-91982Medium
Vikunja before 2.6.0 continues to expose the raw TOTP shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without re-authentication. Attackers with a valid access token can read the secret, import it into their own authenticator, and generate valid codes indefinitely to defeat the second factor and enable account takeover.
- CVE-2026-91981Medium
Vikunja versions before 2.6.0 fail to properly validate link-share tokens in the v2 API user search endpoints. Attackers with a read-only share link can enumerate project users via the projects endpoint and confirm arbitrary usernames exist via the global search endpoint.
- CVE-2026-91980Medium
vikunja before 2.6.0 fails to validate team access when attaching teams to projects, allowing authenticated users to enumerate all teams and members. Attackers can attach arbitrary team IDs via the project teams endpoint to retrieve complete team rosters including member names and admin flags for unauthorized teams.
Original NVD description (English source)
Vikunja versions 0.22.0 through 2.3.0 fail to validate the principal type in API token management. Because user IDs and link-share IDs are independent numeric sequences and both resolve through a generic web.Auth.GetID() interface, a link-share JWT whose numeric ID equals a target user's ID is treated as that user by the /api/v1/tokens endpoints. An authenticated attacker can obtain a target's numeric user ID via authenticated user search, then create link shares on an attacker-writable project until the link-share sequence reaches that value, and use the resulting link-share JWT to list, create, and delete the target user's API tokens (including issuing a new token with attacker-chosen scopes under the target's permissions). Fixed in version 2.4.0.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

