GHSA-3hc7-r24j-rpwc: Cross-Project Task Disclosure via Subtask Expansion in Vikunja

Vikunja is an open-source task management platform written in Go (code.vikunja.io/api). The application provides REST API endpoints for managing tasks, projects, views, and attachments. Within Vikunja, users can create subtask relationships where a parent task in one project references a child task residing in another project.

A cross-project information disclosure vulnerability exists in all Vikunja versions prior to 2.6.0. When querying tasks using project view endpoints or account-wide task listings, the API accepts the expansion query parameter ?expand[]=subtasks to dynamically populate nested subtasks.

While primary task queries enforce strict access control checks based on the requesting user's project permissions, the subtask expansion routine recursively fetches child tasks without validating project permissions. Consequently, an authenticated attacker with access to a single project can read full details of linked subtasks belonging to private projects where they have no authorization.

> [!WARNING] > This vulnerability exposes complete task structures, including task titles, full descriptions, start and due dates, assigned users, labels, and attachment metadata across unauthorized project boundaries.

The fundamental flaw stems from missing authorization checks during relational expansion in the HTTP handling and service layer. Vikunja allows tasks in Project P to link to subtasks in Project Q. Creating this link originally requires appropriate permissions in both projects. However, permission rights can change, or tasks can remain linked after user access to Project Q is revoked.

When a client issues an HTTP request with ?expand[]=subtasks, the API router parses the expansion list and invokes relational expansion helpers. The query execution pipeline proceeds in two distinct steps:

First, the primary task database query executes and applies access control filters. For instance, querying /api/v1/projects/1/views/1/tasks ensures that only tasks assigned to Project 1 (and accessible by the requesting user) are returned.

Second, the expansion engine detects the subtasks parameter and walks the relational hierarchy to fetch associated child task records by ID. During this recursive walk, the expansion logic omitted project authorization validation. It retrieved and serialized the full subtask entity directly from the database based solely on foreign key relationships, skipping any checks against the requesting user's permissions for the subtask's host project.

In affected versions of Vikunja, the subtask resolution mechanism operated without contextual permission filtering. The subtask fetching logic queried the database for child tasks matching parent identifiers without wrapping the result set in project boundary checks.

The logic flow can be illustrated as follows:

The patch in pull request #3688 modifies the resource expansion pipeline. Before attaching child subtask entities to the JSON response payload, the handler evaluates the parent project ID of each subtask against the permissions matrix of the requesting context. If the user lacks read permission for the subtask's project, the subtask object is omitted from the expansion array.

Exploitation requires valid user credentials and read-level authorization on at least one project containing a parent task linked to a subtask in a restricted project.

An attacker can trigger unauthorized data disclosure by sending an HTTP GET request to either the project view endpoint or the global tasks endpoint while setting the expansion parameter:

GET /api/v1/projects/101/views/1/tasks?expand%5B%5D=subtasks HTTP/1.1
Host: vikunja.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Alternatively, an attacker can query the account-wide task endpoint:

GET /api/v1/tasks?expand%5B%5D=subtasks HTTP/1.1
Host: vikunja.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

If a task in Project 101 links to a subtask in restricted Project 202, the JSON response structure exposes the full subtask entity:

{
  "id": 501,
  "title": "Public Parent Task in Project 101",
  "project_id": 101,
  "subtasks": [
    {
      "id": 902,
      "title": "Confidential Internal Subtask in Project 202",
      "description": "Restricted architectural notes and API keys",
      "project_id": 202,
      "assignees": [{"id": 12, "username": "admin"}]
    }
  ]
}

Because the expansion logic functions recursively, nested subtasks beneath subtask ID 902 in Project 202 are also fully populated and leaked.

The security impact of GHSA-3hc7-r24j-rpwc is rated with a CVSS v4 score of 6.8 (Medium/High depending on deployment context). The vulnerability affects the confidentiality impact metric (VC:H), as unauthorized authenticated users gain access to sensitive organization data.

leaked information includes complete task content such as titles, technical specifications, internal discussions in task descriptions, user assignment mappings, project timelines, label categorizations, and metadata for attached files.

This flaw is particularly relevant in multi-tenant or enterprise environments where project-level isolation is enforced to segregate departments, teams, or client accounts. Former members whose project access was partially revoked can still leverage remaining access in shared or public projects to extract updates from restricted projects.

The primary remediation for this vulnerability is upgrading the Vikunja backend API instance to version 2.6.0 or later.

To update a standalone or containerized Vikunja instance, apply the patched binary or update the container image tag:

docker pull vikunja/api:v2.6.0
docker-compose up -d

If immediate upgrading is not feasible, administrators can apply network-level or Web Application Firewall (WAF) mitigations by filtering requests containing subtask expansion parameters:

> [!NOTE] > Inspect incoming GET requests to /api/v1/projects/*/views/*/tasks and /api/v1/tasks. Block or strip query strings containing expand[]=subtasks or expand%5B%5D=subtasks.