Executive Summary

CVE-2026-35594 is a vulnerability in Vikunja, an open-source self-hosted task management platform, affecting versions prior to 2.3.0. The issue lies in the link share authentication mechanism, where JSON Web Tokens (JWTs) issued for link shares are constructed solely from JWT claims without any server-side database validation.

Because of this, when a project owner deletes a link share or downgrades its permissions, all previously issued JWTs continue to grant the original permission level for up to 72 hours (the default token time-to-live). This means revoked or permission-changed link shares remain accessible until the token expires.

The vulnerability occurs because the function GetLinkShareFromClaims builds authorization objects purely from JWT claims without querying the database to confirm the current state of the link share. This allows stale tokens to retain access even after revocation or permission changes.

The issue was fixed in version 2.3.0 by adding database validation on every request using a link share JWT, ensuring tokens are immediately revoked or permissions updated if the link share is deleted or downgraded.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact you by allowing revoked or downgraded link shares to remain functional for up to 72 hours after the change. This means that anyone possessing a previously issued JWT token for a link share can continue to access resources with the original permission level during this window.

The severity of the impact depends on the permission level of the link share. For example, if the token grants Admin-level access, an attacker or unauthorized user could maintain full control over the project for up to 72 hours after revocation.

This undermines the ability of project owners to immediately revoke access or respond to leaked URLs, potentially exposing sensitive data or allowing unauthorized modifications.

The vulnerability has a CVSS v3.1 base score of 6.5, indicating a moderate severity with low attack complexity and no required privileges or user interaction.

Useful 0 Not Useful 0

Detection Guidance

Detection of this vulnerability involves verifying whether JWT tokens issued for link shares remain valid after the associated link share has been deleted or its permissions downgraded. Since the vulnerability allows previously valid JWTs to grant access for up to 72 hours without server-side validation, one way to detect it is to test if revoked or modified link share tokens are still accepted by the system.

A practical approach is to perform a test similar to the regression test described in the fix: 1) Obtain a JWT token for a link share; 2) Delete the link share or downgrade its permissions in the database; 3) Attempt to access resources using the previously issued JWT token; 4) Check if access is still granted or if an error indicating token invalidation is returned.

While no explicit commands are provided in the resources, you can use HTTP request tools like curl or Postman to send requests with the JWT token in the Authorization header to the Vikunja API endpoints that require link share authentication. Observe the response to determine if the token is still accepted after revocation.

Useful 0 Not Useful 0

Mitigation Strategies

The primary immediate mitigation step is to upgrade Vikunja to version 2.3.0 or later, where this vulnerability is fixed by adding server-side database validation of link share JWT tokens on every request.

Until the upgrade can be applied, consider reducing the default JWT token TTL (service.jwtttl) for link shares to a shorter duration to limit the window during which revoked tokens remain valid.

Alternative mitigations include implementing token blocklists or session tracking mechanisms similar to those used for user JWTs, to allow immediate revocation of link share tokens.

Additionally, monitor and audit link share usage and permissions closely to detect any unauthorized access resulting from stale tokens.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability in Vikunja allows link share JWT tokens to remain valid for up to 72 hours after the associated share has been deleted or its permissions downgraded. This means that access revocation is delayed, potentially allowing unauthorized access to sensitive data during that window.

Such delayed revocation can impact compliance with standards and regulations like GDPR and HIPAA, which require timely control over access to personal or sensitive data. The inability to immediately revoke access or respond to leaked URLs could lead to unauthorized data exposure, violating principles of data protection and access control mandated by these regulations.

The fix introduced in version 2.3.0 enforces server-side validation of link share tokens against the current database state, enabling immediate revocation of access when a share is deleted or permissions are changed, thereby improving compliance with access control requirements.

Useful 0 Not Useful 0