CVE-2026-33676: 
NixOS vulnerability analysis and mitigation

CVE-2026-33676 is a cross-project information disclosure vulnerability in Vikunja, an open-source self-hosted task management platform, caused by a missing authorization check on related task reads. When the Vikunja API returns tasks, it populates the related_tasks field with full task objects without verifying whether the requesting user has read permission on those tasks' projects. All versions up to and including 2.2.0 are affected; version 2.2.1 patches the issue. The vulnerability was published on March 23, 2026, and carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory).

The root cause is classified as CWE-863 (Incorrect Authorization). The flaw resides in the addRelatedTasksToTasks() function at pkg/models/tasks.go:496-548, which is invoked during every task read operation — both project task listings (GET /api/v1/projects/{id}/views/{id}/tasks) and single task reads (GET /api/v1/tasks/{id}). The function fetches all related tasks directly from the database using s.In("id", relatedTaskIDs).Find(&fullRelatedTasks) with no permission filtering; the web.Auth parameter is only used to determine favorites, never for access control. By contrast, the addBucketsToTasks() function in the same file correctly scopes results to projects the user can access, illustrating that the omission was inconsistent rather than systemic. Exploitation requires only a low-privileged authenticated account and network access to the API (Github Advisory, Github PR).

Successful exploitation allows any authenticated user to read the full metadata of tasks in projects they have no access to, as long as a cross-project task relation exists from a task they can legitimately read. Leaked fields include title, description, due dates, start dates, priority, percent completion, project ID, hex color, task index, done status, repeat configuration, cover image attachment ID, and creation/update timestamps. The project_id field additionally discloses the existence and internal IDs of private projects, enabling project structure enumeration. There is no integrity or availability impact; the vulnerability is purely a confidentiality breach affecting multi-tenant or team Vikunja deployments with cross-project task relations (Github Advisory).

A proof-of-concept exploit consisting of concrete curl commands is publicly available in the GitHub Security Advisory, demonstrating the full attack flow with high confidence (Github Advisory). There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.028% (0.000280), indicating a low near-term exploitation probability. Exploitation requires a valid user account but no elevated privileges, and no user interaction beyond the initial relation setup by a higher-privileged user (Github Advisory).

1. Reconnaissance: Identify a Vikunja instance running version 2.2.0 or earlier. Obtain credentials for two accounts — User A (with access to both a shared project and a private project) and User B (with access only to the shared project).
2. Identify target tasks: As User A, enumerate tasks in both projects to obtain the task IDs — Task 1 in the shared project and Task 2 in the private project.
3. Create cross-project relation: As User A, create a task relation linking Task 1 (shared) to Task 2 (private) using the API:

curl -X PUT "http://<vikunja-host>/api/v1/tasks/TASK1_ID/relations" \
  -H "Authorization: Bearer USER_A_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"other_task_id": TASK2_ID, "relation_kind": "related"}'

4. Leak private task data: As User B (no access to the private project), read tasks from the shared project:

curl "http://<vikunja-host>/api/v1/projects/PROJECT_SHARED_ID/views/VIEW_ID/tasks" \
  -H "Authorization: Bearer USER_B_TOKEN"

5. Extract unauthorized data: Parse the JSON response — the related_tasks field of Task 1 will contain the full Task 2 object including its title, description, due dates, priority, percent completion, project ID, and other metadata from the private project, despite User B having no access to it (Github Advisory).

• Network: Repeated API calls to GET /api/v1/projects/{id}/views/{id}/tasks or GET /api/v1/tasks/{id} from accounts that do not have membership in the projects containing related tasks.
• Logs: Vikunja API access logs showing a low-privileged user account querying task endpoints and receiving responses with related_tasks objects belonging to project IDs the user is not a member of.
• Behavioral: A privileged user account creating task relations (PUT /api/v1/tasks/{id}/relations) between tasks in different projects with varying access scopes, followed shortly by reads from lower-privileged accounts — particularly if the lower-privileged account has no history of accessing the related project.
• Application: Presence of cross-project task relations in the database (task_relations table) where the two tasks belong to projects with different access control lists (Github Advisory).

Upgrade Vikunja to version 2.2.1 or later, which patches the issue by adding a SQL-level accessibleProjectIDsSubquery filter in addRelatedTasksToTasks() to restrict related tasks to only those in projects the requesting user can access (Github Advisory, Github PR). No official configuration-based workaround is available for unpatched versions. As an interim measure, administrators can audit existing cross-project task relations and remove those that span projects with different access scopes until the upgrade can be applied. After upgrading, review API access logs to determine whether unauthorized task data was accessed prior to patching.

The vulnerability was published by Vikunja maintainer kolaente via a GitHub Security Advisory on March 23, 2026, and was patched the same day via pull request #2449 (Github PR). The issue was picked up by automated vulnerability tracking services including Qualys, VulnDB, and ENISA's EUVD shortly after disclosure. No significant broader media coverage or notable independent researcher commentary has been identified beyond standard vulnerability database aggregation.