A critical flaw in Vikunja task manager allows attackers with any share link to access sensitive data from unrelated projects via unvalidated view IDs.
Key points
- CVE-2026-68582 affects Vikunja versions 0.24.0 through 2.3.0.
- Attackers can extract user details and bucket titles from other tenants.
- Vendor released version 2.4.0 to patch the authorization bypass.
Vikunja has released version 2.4.0 to address a critical insecure direct object reference vulnerability. The flaw allows unauthorized access to task data across different projects within the same instance.
What happened
The vulnerability, tracked as CVE-2026-68582, exists in the `TaskCollection.ReadAll` function of the Vikunja API. According to GitHub advisory GHSA-rj9j-8772-4h6c, the code resolves project views from URL parameters before verifying caller permissions. This occurs in versions 0.24.0 through 2.3.0 of the software.
When a user accesses the endpoint using a link-share token, the system correctly restricts task scope to the token's specific project. However, it fails to validate that the requested view belongs to that same project. An attacker can supply a view ID from a different tenant in the URL path. The application then returns bucket records and full user objects for that foreign view.
The exposed data includes bucket titles and the `created_by` user object. This object contains the username, name, and ID of the user who created the task. The flaw also creates an existence oracle, allowing attackers to determine if specific project or view IDs exist by observing HTTP 404 responses versus successful requests.
Why it matters
This issue enables horizontal privilege escalation within multi-tenant Vikunja deployments. An attacker needs only a valid share link for any single project to probe other projects. They can enumerate views and extract user identity information without needing administrative credentials.
The root cause lies in `GetProjectViewByIDAndProject`, which filters by ID and project ID but performs no authorization check. The function returns the view object if the pair exists, regardless of whether the caller has permission to access it. This design flaw allows link-share holders to bypass project boundaries entirely.
The fix
- Upgrade Vikunja to version 2.4.0 immediately to apply the vendor patch.
- Review access logs for requests to the tasks endpoint with mismatched view IDs.
- Rotate share links that may have been exposed or used during the vulnerable period.
- Monitor for unusual 404 responses that indicate enumeration attempts by attackers.
What to do and how to stay safe: Vikunja
- Audit your Vikunja version to ensure you are not running a vulnerable release.
- Restrict network access to the API endpoint to trusted internal networks only.
- Monitor server logs for requests containing view IDs that do not match the source project.
- Educate users on the risks of sharing links with external parties until patched.
Step-by-step guide: Patch Testing: How to Verify Fixes Without Breaking Your Systems
General security guidance from the Crypt Weekly newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What specific data is exposed by this vulnerability?
The flaw exposes bucket titles and full user objects including username, name, and ID for tasks in unauthorized views.
Which versions of Vikunja are affected by CVE-2026-68582?
Versions 0.24.0 through 2.3.0 are vulnerable. Version 2.4.0 contains the fix.
Do attackers need admin access to exploit this issue?
No, an attacker only needs a valid share link for any project to probe other views and extract data.
