CVE-2026-68582: Vikunja 2.4.0 Patches Critical IDOR Exposing User Data via Share Links

Vikunja version 2.4.0 resolves a critical identity and access control flaw that allowed unauthorized users to extract task data from any project on a server. The vulnerability, tracked as CVE-2026-68582, exists in the Go-based API code for versions 0.24.0 through 2.3.0. GitHub advisory GHSA-rj9j-8772-4h6c details how the application failed to validate view permissions when processing requests from share link tokens.

How does the vulnerability work technically?

The root cause lies in the `TaskCollection.ReadAll` function within `pkg/models/task_collection.go`. This code resolves the requested view from URL parameters before performing any permission checks. The function `GetProjectViewByIDAndProject` filters data only by ID and project ID, returning the view object or a 404 error without verifying if the caller has access. This behavior creates an existence oracle that reveals whether specific project or view IDs are valid.

Why do share links lead to data leaks?

When a request uses a link-share token, the code correctly restricts the task scope to the project associated with that token. However, it reuses the attacker-supplied view ID from the URL path. This view is never validated against the share token’s project ID. Consequently, a holder of a share link for one project can point the endpoint at any other tenant’s kanban view to retrieve its data.

What specific data can attackers access?

An attacker can retrieve bucket records for every view in the instance, including bucket titles and full `created_by` user objects. These user objects contain the username, name, and ID for every task creator. This exposure occurs because the application loads the foreign view and returns its associated task data without cross-referencing the share token’s authorized project boundaries.

Is there a fix available?

Yes, the vendor has released Vikunja version 2.4.0 to address this issue. This update patches the vulnerable `go code.vikunja.io/api` package. Users running versions 0.24.0 through 2.3.0 must upgrade to 2.4.0 or later to mitigate the risk. No other fixes or workarounds are mentioned in the advisory material.

Background: Data leaks

Data leaks often begin with subtle shifts in network behavior or unexpected file access. You must monitor for unusual outbound traffic, strange login patterns, and missing files. Immediate isolation of affected systems prevents further loss while you investigate the root cause.

Read the full guide: Warning Signs of Data Leaks: What to Watch For and How to React

What to do and how to stay safe: Vikunja

• Update Vikunja installations to version 2.4.0 immediately to close the authorization gap in the task collection endpoint.
• Audit share link usage logs for requests targeting project or view IDs that do not match the token’s original project.
• Monitor server access logs for unusual patterns of 404 errors followed by successful data retrieval from different project IDs.
• Review user object exposure in API responses to ensure sensitive fields like user IDs are not leaked via shared links.

Step-by-step guide: Patch Management Checklist: Secure Systems Without Breaking Them

General security guidance from the Firewall Scoop newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Vikunja are affected by CVE-2026-68582?

Versions 0.24.0 through 2.3.0 of the go code.vikunja.io/api package are vulnerable. Version 2.4.0 contains the fix.

Can an attacker use this flaw to read task content?

The advisory states attackers can receive bucket records, including titles and creator user objects, but does not explicitly confirm full task body content access.

Does this vulnerability require authentication?

No, it can be exploited by anyone holding a valid share link to any project, as well as by ordinary authenticated users.