CVE-2026-68582: Vikunja Auth Bypass Vulnerability

CVE-2026-68582 Overview

CVE-2026-68582 is a broken object level authorization (BOLA) vulnerability in Vikunja, an open-source task management application. The flaw exists in the task-collection endpoint GET /api/v1/projects/{project}/views/{view}/tasks in versions >= 0.24.0 and <= 2.3.0. The endpoint loads the requested project view from the URL path without verifying that the caller is authorized for it. Any holder of a project link-share token can read kanban bucket records from any other tenant's project view. Exposed data includes bucket titles and the full created_by user object containing username, name, and ID. The issue is fixed in Vikunja 2.4.0.

Critical Impact
A link-share token holder can enumerate kanban bucket metadata and identifying user information for every view across the entire Vikunja instance, breaking multi-tenant isolation.

Affected Products

Vikunja >= 0.24.0 up to and including 2.3.0
Vikunja API endpoint GET /api/v1/projects/{project}/views/{view}/tasks
Any Vikunja instance issuing project link-share tokens

Discovery Timeline

2026-08-02 - CVE-2026-68582 published to NVD
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-68582

Vulnerability Analysis

The vulnerability is a classic BOLA flaw classified as [CWE-639]: Authorization Bypass Through User-Controlled Key. The task-collection endpoint accepts two path parameters, {project} and {view}, and returns the tasks and kanban bucket data for that combination. For link-share tokens, the server correctly pins the task scope to the share's own project. However, the server loads the view object referenced by {view} from the URL path without checking that the view belongs to the caller's authorized project. The loaded view object is then serialized into the response along with its associated kanban buckets. This exposes bucket titles and the complete created_by user object, including username, name, and id, for any view in the instance.

Root Cause

The root cause is missing pre-authorization on the view object. The handler resolves {project} against the caller's share scope but treats {view} as trusted input. No ownership or membership check is performed between the view and either the calling user or the share's pinned project. This same missing check also creates a project and view existence oracle: requests to valid IDs return non-404 responses, while invalid IDs return 404. Both link-share holders and ordinary authenticated users can abuse this oracle to enumerate resource identifiers.

Attack Vector

An attacker only needs a valid link-share token for any project on the target Vikunja instance. Such tokens are commonly shared by URL and are unauthenticated from the recipient's perspective. The attacker iterates numeric view IDs against the vulnerable endpoint. Task contents themselves remain constrained to the share's own project and are not disclosed, but the returned bucket metadata and user identity fields leak cross-tenant. The attack requires no user interaction, no elevated privileges, and can be scripted against the network-accessible API.

No verified public proof-of-concept code is available at the time of writing. Refer to the GitHub Security Advisory GHSA-rj9j-8772-4h6c and the VulnCheck Advisory on Vikunja for authoritative technical detail.

Detection Methods for CVE-2026-68582

Indicators of Compromise

Bursts of GET /api/v1/projects/{project}/views/{view}/tasks requests where the same authenticated session or link-share token iterates sequential {view} identifiers.
Requests to the task-collection endpoint that return kanban bucket data referencing users or projects unrelated to the caller's own share scope.
Elevated 404 rates on /api/v1/projects/*/views/*/tasks paths, consistent with ID enumeration against the existence oracle.

Detection Strategies

Parse Vikunja API access logs and correlate {view} identifiers per token or user; alert when a single principal accesses more distinct view IDs than they own.
Compare the project and view IDs in each request against the caller's known authorized set stored in the application database.
Detect link-share tokens issuing requests to task-collection paths where {view} does not resolve to the token's pinned project.

Monitoring Recommendations

Forward Vikunja reverse-proxy and application logs to a centralized analytics platform and retain full request URIs.
Baseline normal request volume per link-share token and alert on deviations that indicate scripted enumeration.
Monitor egress from the Vikunja host for large or unusual response payloads correlated with the vulnerable endpoint.

How to Mitigate CVE-2026-68582

Immediate Actions Required

Upgrade Vikunja to version 2.4.0 or later, which contains the fix for the missing view authorization check.
Rotate or revoke existing project link-share tokens after upgrade, since token holders may have already enumerated data.
Audit application logs for prior access patterns matching the enumeration behavior described above.

Patch Information

The Vikunja maintainers released the fix in version 2.4.0. The patch adds a pre-authorization step that validates the requested {view} belongs to the {project} in the URL path and that the caller, whether a link-share token holder or an authenticated user, is authorized for both. Details are published in the GitHub Security Advisory GHSA-rj9j-8772-4h6c.

Workarounds

If immediate upgrade is not possible, disable the link-share feature by revoking all outstanding share tokens through the Vikunja admin interface.
Place the Vikunja API behind a reverse proxy and block or rate-limit requests matching GET /api/v1/projects/*/views/*/tasks from untrusted networks.
Restrict Vikunja access to authenticated internal users via network segmentation until the upgrade to 2.4.0 is completed.

bash

# Configuration example: upgrade Vikunja via Docker Compose
# Edit docker-compose.yml to pin the fixed release
# image: vikunja/vikunja:2.4.0

docker compose pull
docker compose up -d
docker compose exec vikunja vikunja version