CVE-2026-68581: Vikunja Auth Bypass Vulnerability

CVE-2026-68581 Overview

CVE-2026-68581 is an authorization flaw in Vikunja, an open-source to-do list and project management application. Vikunja versions 0.22.0 through 2.3.0 fail to validate the principal type when handling API token management requests. User IDs and link-share IDs are independent numeric sequences, yet both resolve through the same generic web.Auth.GetID() interface. An authenticated attacker can create link shares until a link-share JWT ID collides with a target user's numeric ID, then use that JWT to manipulate the victim's API tokens through the /api/v1/tokens endpoints. The issue is fixed in version 2.4.0 and is classified under [CWE-863: Incorrect Authorization].

Critical Impact
An authenticated attacker can list, create, and delete another user's API tokens, effectively taking over the target account with attacker-chosen scopes.

Affected Products

Vikunja 0.22.0 through 2.3.0
Self-hosted Vikunja API server deployments
Vikunja instances exposing /api/v1/tokens endpoints

Discovery Timeline

2026-08-02 - CVE-2026-68581 published to NVD
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-68581

Vulnerability Analysis

The vulnerability stems from ambiguous principal identity resolution in Vikunja's authentication layer. The API token management endpoints under /api/v1/tokens rely on web.Auth.GetID() to identify the calling principal. This interface returns a numeric ID without distinguishing whether the caller is a registered user or a link-share principal.

Because user IDs and link-share IDs are drawn from independent auto-incrementing sequences, their numeric values can overlap. When a link-share JWT presents an ID matching a real user's ID, the token endpoints treat the link-share as that user. The attacker can then perform full CRUD operations on the victim's API tokens, including minting a new token with elevated scopes under the victim's identity.

Root Cause

The root cause is missing type validation on the principal returned by the authentication middleware. The code compares only numeric IDs when authorizing API token operations, as illustrated by the fixed permission check in pkg/models/api_tokens_rights.go:

func (t *APIToken) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {
    token, err := GetAPITokenByID(s, t.ID)
    if err != nil {
        return false, err
    }

    if token.OwnerID != a.GetID() {

Source: go-vikunja/vikunja commit e6b25bd5

Without also verifying that a represents a User and not a LinkSharing principal, any authenticated principal whose numeric ID matches token.OwnerID passes the check.

Attack Vector

Exploitation requires low-privileged authenticated access to a Vikunja instance and proceeds in three stages:

The attacker enumerates the target's numeric user ID via the authenticated user search endpoint.
The attacker creates link shares on an attacker-writable project, incrementing the link-share sequence until it reaches the target user's ID.
The attacker authenticates using the resulting link-share JWT and invokes /api/v1/tokens to list, create, or delete the victim's API tokens.

A newly minted token can carry attacker-selected APIPermissions scopes, granting persistent access to the victim's projects and data.

Detection Methods for CVE-2026-68581

Indicators of Compromise

Rapid sequential creation of link shares on a single project by one authenticated user, indicating sequence-walking behavior.
Requests to /api/v1/tokens endpoints authenticated with a link-share JWT rather than a user JWT.
Unexpected new API tokens appearing on user accounts with scopes the account holder did not request.
Deletion of legitimate API tokens followed immediately by creation of new tokens on the same account.

Detection Strategies

Correlate the sub or principal-type claim in JWTs against the endpoint accessed; link-share JWTs should never reach /api/v1/tokens.
Alert on API token CRUD activity where the authenticating principal is not a user account.
Baseline the rate of link-share creation per user and flag outliers that create dozens of shares in short succession.

Monitoring Recommendations

Enable verbose access logging on the Vikunja API and forward logs to a centralized analytics platform for correlation.
Track the delta between the highest link-share ID and the highest user ID; a shrinking gap indicates possible exploitation attempts.
Audit the api_tokens table for tokens created outside expected user workflows.

How to Mitigate CVE-2026-68581

Immediate Actions Required

Upgrade Vikunja to version 2.4.0 or later, which enforces principal type validation on API token endpoints.
Rotate all existing API tokens after upgrading to invalidate any tokens minted through exploitation.
Review link shares and delete any that appear to have been created as part of sequence-walking activity.
Audit user accounts for unexpected API tokens and revoke unknown entries.

Patch Information

The fix is delivered in Vikunja 2.4.0. The relevant commits add proper CRUD authorization checks that verify both the numeric owner ID and the principal type before permitting API token operations. See the GitHub Security Advisory GHSA-vvcv-vpph-h844, the remediation commit 95b7e673, and the VulnCheck Advisory for full technical detail.

Workarounds

If immediate upgrade is not possible, restrict who can create link shares by limiting project write permissions to trusted users only.
Place the Vikunja API behind a reverse proxy that blocks link-share JWTs from reaching /api/v1/tokens paths.
Disable API token functionality for the tenant until the upgrade is applied if operationally acceptable.

bash

# Example nginx rule to block link-share principals from token endpoints
# Requires JWT inspection at the proxy layer
location /api/v1/tokens {
    if ($jwt_claim_type = "link_share") {
        return 403;
    }
    proxy_pass http://vikunja_backend;
}