CVE-2026-33676: Cross-Project Information Disclosure in Vikunja API

Vikunja is an open-source, self-hosted task management platform designed to handle multi-tenant project organization. The application exposes a comprehensive REST API to facilitate client interactions, including the retrieval of complex task structures. Tasks within Vikunja can establish relationships with other tasks, such as marking one task as "blocking" or "duplicated by" another, which introduces cross-entity data dependencies.

The vulnerability, identified as CVE-2026-33676, exists in the API's data hydration logic responsible for populating these task relationships. When a client requests a task, the API automatically fetches and appends related task metadata to the response payload. The implementation of this feature lacked adequate authorization boundaries, categorizing the flaw as an Incorrect Authorization issue (CWE-863).

Because the API does not enforce project-level access controls during this hydration phase, an authenticated user can bypass intended data isolation mechanisms. If a task the user is authorized to view possesses a relationship with a task in a restricted, private project, the API will inadvertently disclose the private task's full details in the response.

The fundamental flaw lies in how the addRelatedTasksToTasks and addBucketsToTasks functions construct database queries to retrieve related entities. During the processing of an API request for a specific task, the application determines which other tasks are linked to the primary object. It then extracts the IDs of these related tasks to perform a subsequent data fetch.

The original implementation executed this secondary fetch by querying the database using only the extracted task IDs in a SQL IN clause. It failed to include a contextual authorization filter to verify if the session's user possessed read permissions for the projects containing those related tasks. This oversight decoupled the data retrieval process from the application's access control model.

By operating strictly on object identifiers without verifying the relationship between the requesting principal and the requested resource, the API effectively created an Insecure Direct Object Reference (IDOR) condition within the hydration routine. The application trusted the existence of the database relationship as an implicit authorization grant, which breaks multi-tenant data boundaries.

The vulnerability was addressed in commit 833f2aec006ac0f6643c41872e45dd79220b9174 by refactoring the query building process to incorporate database-level authorization constraints. Prior to the patch, the code retrieved related records using an unfiltered query based solely on the task_id array.

The patch introduces the accessibleProjectIDsSubquery function, which dynamically generates a SQL subquery evaluating the requesting user's permissions. This subquery is then appended to the original WHERE clause using an AND condition. This ensures that the database only returns records if the related task resides in a project the user is authorized to view.

The relevant modifications in pkg/models/tasks.go enforce this constraint directly at the data access layer:

// Refactored to use database-level authorization check
buckets := make(map[int64]*Bucket)
err = s.
    Where(builder.In("id", builder.Select("bucket_id").
        From("task_buckets").
        Where(builder.In("task_id", taskIDs)))).
    And(builder.In("project_view_id", builder.Select("id").
        From("project_views").
        Where(accessibleProjectIDsSubquery(a, "project_views.project_id")))). // Database-level filter added here
    Find(&buckets)

By pushing the authorization logic into the SQL query, the application eliminates the possibility of data leakage in memory. If a related task belongs to an unauthorized project, the database simply omits it from the result set, and the API hydration function behaves securely by default.

Exploiting CVE-2026-33676 requires the attacker to hold a valid, authenticated session on the target Vikunja instance. The attacker must also possess read access to at least one project or task within the system. No administrative privileges or special network positions are necessary to trigger the flaw.

The attacker begins by identifying or establishing a task relationship that crosses project boundaries. If the attacker has permission to modify tasks in their own project, they can create a relation (such as "blocks" or "related to") targeting a specific task ID they suspect exists in a private project. Alternatively, they can target existing tasks that already contain cross-project relationships established by other users.

Once the relationship is established or identified, the attacker issues a standard GET request to the API endpoint for their authorized task (e.g., /api/v1/tasks/{id}). The server processes the request, passes the initial authorization check for the primary task, and proceeds to the vulnerable hydration routine.

The server responds with a JSON payload containing the primary task data along with a populated related_tasks array. This array dumps the full metadata of the target task, exposing fields such as description, due_date, priority, and percent_done. The attacker successfully reads data from a project they explicitly lack authorization to access.

The primary impact of CVE-2026-33676 is a substantial breach of data confidentiality. Organizations utilize self-hosted task management platforms to track sensitive internal operations, software development pipelines, and strategic planning. Exposing task descriptions and metadata across unauthorized project boundaries compromises the application's core data isolation guarantees.

The vulnerability carries a CVSS v3.1 base score of 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). The High confidentiality metric reflects the complete exposure of task data, while the Low privileges metric underscores that any authenticated user, regardless of their role, can execute the attack. The integrity and availability of the application remain unaffected, as the flaw does not permit unauthorized modification or deletion of data.

The Exploit Prediction Scoring System (EPSS) assigns this vulnerability a score of 0.00028, placing it in the 7.746th percentile. This indicates an extremely low probability of automated or mass exploitation in the wild. The primary threat model for this vulnerability involves targeted exploitation by malicious insiders attempting to perform unauthorized horizontal privilege escalation to gather intelligence on restricted internal projects.

The definitive remediation for CVE-2026-33676 is updating the Vikunja application to version 2.2.1 or later. The patch provided in pull request #2449 effectively eliminates the vulnerability by enforcing robust project-level authorization checks directly within the database queries responsible for task hydration.

If immediate patching is not technically feasible, administrators cannot reliably mitigate the issue via external mechanisms like Web Application Firewalls (WAFs). The exploitation occurs through legitimate, expected API request structures, making it indistinguishable from benign traffic at the network layer. Disabling the task relations feature entirely, if supported by the configuration, serves as the only viable temporary workaround.

Security and development teams should conduct an audit of application access logs to identify anomalous task retrieval patterns, specifically looking for users querying tasks with known cross-project relations. Furthermore, this vulnerability highlights the architectural necessity of ensuring that Object-Relational Mapping (ORM) and data hydration routines strictly inherit the authorization context of the initiating API request.