CVE-2026-55066 in Vikunja
Summary
by MITRE • 08/28/2026
Vikunja is an open-source self-hosted task management platform. Prior to 2.4.0, POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks accepts a body supplied task_id but TaskBucket.CanUpdate in pkg/models/kanban_task_bucket.go authorizes only the project, view, and bucket from the URL. updateTaskBucket then calls Task.ReadOne without a separate task permission check, returns the victim task contents, and can update the task done state when the attacker chooses a done bucket. Because task identifiers are global sequential values, an authenticated user can enumerate cross-tenant tasks and modify their completion metadata through both the v1 and v2 routes that share this model. This issue is fixed in version 2.4.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
Vikunja is a widely adopted open-source self-hosted task management platform designed to facilitate project organization and workflow coordination for individuals and teams. A critical security flaw was identified in versions prior to 2.4.0, specifically within the API endpoint responsible for managing Kanban board buckets. The vulnerability resides in the POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks route, where the server accepts a task_id parameter within the request body. This design choice introduces a significant authorization bypass because the backend logic relies exclusively on TaskBucket.CanUpdate to determine access rights. This function validates permissions based solely on the project, view, and bucket identifiers extracted from the URL path parameters, completely ignoring the task_id provided in the payload.
The technical root cause of this vulnerability is an insecure direct object reference combined with a failure to perform proper authorization checks at the resource level. When updateTaskBucket processes the request, it invokes Task.ReadOne using the supplied task_id without verifying whether the authenticated user has permission to access or modify that specific task. This oversight allows an attacker who possesses valid credentials for one tenant or project to manipulate tasks belonging to other tenants or unrelated projects within the same instance. Since the system does not enforce strict ownership validation on the target resource, the application effectively trusts client-supplied identifiers without cross-referencing them against user-specific access control lists.
The operational impact of this flaw is severe due to two compounding factors: information disclosure and unauthorized state modification. First, because task identifiers in Vikunja are implemented as global sequential values rather than random or tenant-scoped unique identifiers, an authenticated attacker can perform enumeration attacks. By iterating through sequential integer IDs, the attacker can discover tasks belonging to other users or organizations within the same instance. Second, once a target task is identified, the attacker can modify its completion status by submitting requests that specify a done bucket in the URL while providing arbitrary task_ids in the body. This allows for unauthorized updates to task metadata, potentially disrupting workflows and compromising data integrity across multiple tenants sharing the self-hosted infrastructure.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves insufficient verification of user authorization before performing actions on a specific resource. It also maps to ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials to access resources they are not authorized to view or modify. Furthermore, the ability to enumerate sequential identifiers relates to CWE-200 Information Exposure and CWE-640 Weak Password Recovery Mechanisms for Enumeration if such patterns were used for authentication recovery, though here it specifically facilitates unauthorized data discovery. The issue affects both v1 and v2 API routes because they share the underlying model logic that lacks granular permission checks on individual task objects.
To mitigate this vulnerability, organizations running Vikunja must upgrade to version 2.4.0 or later immediately. This release includes patches that enforce strict authorization checks at the task level, ensuring that users can only access and modify tasks they own or are explicitly permitted to edit by project administrators. For environments where immediate upgrading is not feasible due to operational constraints, implementing a reverse proxy with advanced request inspection capabilities may help detect anomalous patterns of sequential ID enumeration, although this is not a substitute for fixing the underlying application logic. Regular security audits focusing on object-level authorization checks in RESTful APIs are recommended to prevent similar flaws involving insecure direct object references in other components of the platform.