CVE-2026-55067 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} allows the request body project_view_id value to be mass assigned by Bucket.Update in pkg/models/kanban.go. The permission check validates that the bucket currently belongs to the URL project and view but does not validate the body selected destination view, allowing any authenticated user to relocate an attacker-owned bucket into another tenant’s Kanban view. The injected bucket retains attacker-controlled content and ownership, enabling cross-tenant defacement. This issue is fixed in version 2.4.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
Vikunja serves as a prominent open-source self-hosted task management platform designed to facilitate project organization through Kanban boards and other view types. A critical security flaw was identified in versions prior to 2.4.0, specifically within the API endpoint POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}. This vulnerability stems from a flawed implementation of permission checks during bucket relocation operations. The core technical issue lies in how the Bucket.Update function handles mass assignment parameters, particularly regarding the project_view_id field found in the request body. While the system correctly validates that the source bucket currently belongs to the specified URL project and view, it fails to validate whether the destination view provided in the request body is accessible or authorized for the requesting user within a different tenant context.
This logic error creates a significant cross-tenant security breach allowing authenticated users to perform unauthorized data manipulation across organizational boundaries. An attacker can exploit this by crafting a malicious API request that specifies a project_view_id belonging to another tenant's Kanban view. Because the server only verifies the origin of the bucket and not the destination, it permits the relocation operation without ensuring the target environment is appropriate for the user making the change. Consequently, an attacker can move a bucket they own into a workspace or board controlled by a different organization within the same Vikunja instance.
The operational impact of this vulnerability is severe due to its potential for cross-tenant defacement and data integrity compromise. Once relocated, the injected bucket retains all original content and ownership attributes associated with the attacker's account. This means that malicious actors can inject arbitrary task items, comments, or attachments into a victim organization’s workflow without their knowledge. The presence of this foreign bucket disrupts legitimate operations, potentially causing confusion among team members who expect specific workflows to be present in their project views. Furthermore, because the bucket retains its original ownership metadata, it may appear as if the attacker has direct access to that space, complicating forensic analysis and trust within multi-tenant deployments.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in authorization logic where user input is not adequately validated against security policies before processing. It also maps closely to MITRE ATT&CK technique T1530 Data from Information Repositories, as the attacker leverages legitimate API functionality to exfiltrate or inject data into unauthorized storage locations within a shared infrastructure. The flaw represents a classic case of insecure direct object references combined with broken access control mechanisms in multi-tenant SaaS architectures.
To mitigate this risk, organizations running Vikunja must upgrade immediately to version 2.4.0 or later, where the developers have corrected the permission validation logic to ensure that both source and destination contexts are properly authorized for the requesting user. Until an upgrade is feasible, administrators should consider implementing strict API gateway rules that validate project_view_id ownership against the authenticated user’s tenant context before allowing bucket modification requests. Additionally, enabling comprehensive audit logging can help detect anomalous relocation patterns indicative of exploitation attempts, although this serves only as a compensatory control rather than a fix for the underlying code defect.