CVE-2026-35594: Vikunja Auth Bypass Vulnerability

CVE-2026-35594 Overview

CVE-2026-35594 is an authorization bypass vulnerability in Vikunja, an open-source self-hosted task management platform. The vulnerability exists in the link share authentication mechanism, specifically in the GetLinkShareFromClaims function located in pkg/models/link_sharing.go. This function constructs authorization objects entirely from JWT claims without performing any server-side database validation, allowing revoked or downgraded link shares to maintain their original permission levels.

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 service.jwtttl configuration value). This creates a window where unauthorized access can persist despite administrative actions to revoke access.

Critical Impact

Users who have had their link share access revoked or downgraded can continue accessing projects with their original permissions for up to 72 hours, potentially exposing sensitive task data and allowing unauthorized modifications.

Affected Products

• Vikunja versions prior to 2.3.0

Discovery Timeline

• 2026-04-10 - CVE CVE-2026-35594 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2026-35594

Vulnerability Analysis

This vulnerability represents a classic Insufficient Session Expiration issue (CWE-613) where server-side permission changes are not properly synchronized with active tokens. The GetLinkShareFromClaims function trusts JWT claims as the sole source of truth for authorization decisions without validating that the underlying link share still exists with the claimed permissions in the database.

The attack surface is exposed over the network and requires no authentication, as link shares are inherently designed to provide access without user accounts. The vulnerability allows both confidentiality and integrity impacts since attackers with previously valid tokens can read project data and potentially make modifications depending on the original permission level.

Root Cause

The root cause is the absence of server-side validation when processing JWT claims for link share authentication. The application relies entirely on the cryptographic integrity of the JWT token without checking whether the link share referenced in the token claims still exists or maintains the same permission level in the database. This design assumes that once a token is issued, the permissions encoded within it are immutable for the token's lifetime.

Attack Vector

An attacker who obtains a valid link share JWT (either legitimately shared or through other means) can continue using that token even after the project owner:

1. Deletes the link share entirely
2. Downgrades the link share from write to read-only access
3. Changes other permission attributes of the link share

The attack requires network access to the Vikunja instance and possession of a previously valid JWT token. The vulnerability persists for the duration of the JWT's time-to-live, which defaults to 72 hours.

The exploitation flow involves capturing or retaining a link share token, then continuing to use it after the server-side permissions have been modified or revoked. The server accepts the token based solely on JWT signature verification without confirming the current state of the link share in the database.

Detection Methods for CVE-2026-35594

Indicators of Compromise

• API requests to project endpoints using link share tokens that reference deleted or modified link shares
• Access patterns continuing after administrative link share revocation actions
• Discrepancies between database link share records and active session permissions
• Unusual project access from tokens associated with link shares that no longer exist

Detection Strategies

• Implement logging correlation between link share deletion/modification events and subsequent API access using those share IDs
• Monitor for API requests to projects where the referenced link share ID no longer exists in the database
• Alert on link share token usage after administrative permission changes
• Review access logs for patterns indicating stale token exploitation

Monitoring Recommendations

• Enable detailed audit logging for link share management operations (create, modify, delete)
• Correlate authentication logs with link share lifecycle events
• Set up alerts for access attempts using tokens referencing non-existent link shares after upgrading
• Monitor for unusual access patterns during the 72-hour window following permission changes

How to Mitigate CVE-2026-35594

Immediate Actions Required

• Upgrade Vikunja to version 2.3.0 or later immediately
• Review and audit all active link shares in your Vikunja instance
• Consider regenerating all link shares after upgrading to invalidate potentially compromised tokens
• Reduce the JWT TTL configuration (service.jwtttl) to minimize the exposure window if immediate upgrade is not possible

Patch Information

The vulnerability is fixed in Vikunja version 2.3.0. The fix is available through the GitHub Release v2.3.0. The specific commit addressing this issue can be found in the GitHub Commit Update.

For additional technical details, refer to the GitHub Security Advisory GHSA-96q5-xm3p-7m84 and the associated GitHub Pull Request.

Workarounds

• Reduce the service.jwtttl configuration value to minimize the window of exposure for revoked tokens
• Delete and recreate link shares rather than modifying permissions to ensure new tokens are issued
• Implement network-level access controls to restrict who can access link share URLs
• Consider disabling link share functionality entirely until the upgrade can be applied if sensitive projects are involved
• Monitor access logs closely for any suspicious activity related to recently modified or deleted link shares

# Configuration example - reduce JWT TTL in Vikunja config
# Edit config.yml or set via environment variable
service:
  jwtttl: 3600  # Reduce from default 72 hours to 1 hour (3600 seconds)