CVE-2026-33680 in vikunja
Summary
by MITRE • 03/24/2026
Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.2, the `LinkSharing.ReadAll()` method allows link share authenticated users to list all link shares for a project, including their secret hashes. While `LinkSharing.CanRead()` correctly blocks link share users from reading individual shares via `ReadOne`, the `ReadAllWeb` handler bypasses this check by never calling `CanRead()`. An attacker with a read-only link share can retrieve hashes for write or admin link shares on the same project and authenticate with them, escalating to full admin access. Version 2.2.2 patches the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/30/2026
The vulnerability described in CVE-2026-33680 affects Vikunja, an open-source self-hosted task management platform that enables users to organize and manage their tasks and projects. This issue represents a critical authorization flaw that undermines the security model of the application's link sharing functionality. The vulnerability exists in versions prior to 2.2.2 and stems from a fundamental misconfiguration in how the application handles access control for shared resources. The core problem lies within the `LinkSharing.ReadAll()` method which fails to properly validate user permissions when retrieving lists of shared links for a given project.
The technical implementation of this vulnerability demonstrates a classic broken access control scenario where the application's authorization logic is inconsistent across different API endpoints. While the `LinkSharing.CanRead()` method correctly implements access controls to prevent unauthorized reading of individual link shares, the `ReadAllWeb` handler deliberately bypasses this security check by never invoking the `CanRead()` validation function. This design flaw creates a pathway for privilege escalation where users with read-only access to a project's link shares can enumerate all existing shares within that project, including the secret hashes for write and administrative shares. The vulnerability aligns with CWE-285, which addresses improper authorization in software systems, and specifically manifests as an authorization bypass through insufficient access control validation.
The operational impact of this vulnerability is severe and can lead to complete system compromise when exploited by malicious actors. An attacker who gains read-only access to a project through any legitimate means can leverage this flaw to discover all link share credentials for that project, regardless of their actual permission levels. This enables the attacker to authenticate as users with higher privileges, potentially gaining write access to project data, administrative capabilities, or even full system control depending on the implementation details. The vulnerability essentially allows for privilege escalation from read-only to full administrative access within the affected project scope. From an adversarial perspective, this represents a significant risk because it requires minimal initial access to potentially gain maximum system control, making it particularly dangerous in multi-tenant or collaborative environments where different users have varying permission levels.
The security implications extend beyond simple access control violations and demonstrate a fundamental flaw in the application's security architecture. The vulnerability exploits the principle of least privilege by allowing enumeration of resources that should remain hidden from unauthorized users. This type of issue commonly appears in applications that implement complex permission models where different endpoints have inconsistent security checks. The fix implemented in version 2.2.2 addresses this by ensuring that the `ReadAllWeb` handler properly calls the `CanRead()` validation function, thereby maintaining consistent access control across all API endpoints. Organizations using Vikunja should immediately upgrade to version 2.2.2 or later to mitigate this risk, as the vulnerability can be exploited without requiring additional privileges beyond initial read access to a project. This remediation aligns with ATT&CK technique T1078 which covers valid accounts and privilege escalation, as the vulnerability allows attackers to leverage existing legitimate credentials to assume higher privilege roles within the system.