CVE-2026-33700: 
NixOS vulnerability analysis and mitigation

CVE-2026-33700 is an Insecure Direct Object Reference (IDOR) vulnerability in Vikunja, an open-source self-hosted task management platform, affecting all versions prior to 2.2.1. The DELETE /api/v1/projects/:project/shares/:share endpoint fails to verify that the targeted link share belongs to the project specified in the URL, allowing an attacker with admin access to any project to delete link shares from other projects. The vulnerability was published on March 23–24, 2026, and patched in version 2.2.1. It carries a CVSS v3.1 score of 4.9 (Medium) and a CVSS v4.0 score of 6.9 (Medium) (GitHub Advisory, Vikunja Advisory).

The root cause is an authorization bypass through a user-controlled key (CWE-639). The permission check in canDoLinkShare (pkg/models/link_sharing_permissions.go:53-70) correctly validates that the requesting user has admin access to the project specified in the :project URL parameter, but the Delete method at pkg/models/link_sharing.go:305 executes a database query using only WHERE id = ? — without also filtering by project_id. This means any valid share ID can be deleted regardless of which project it belongs to. Because link share IDs are sequential integers, an attacker can trivially enumerate them. The same vulnerability class was previously identified in task attachments (GHSA-jfmm-mjcp-8wq2) and task comments (GHSA-mr3j-p26x-72x4) (GitHub Advisory, Vikunja Advisory).

Successful exploitation allows a malicious authenticated user with admin access to any project to delete link shares belonging to any other project in the Vikunja instance, disrupting collaboration and revoking shared access links without authorization. There is no confidentiality or availability impact — the vulnerability is limited to an integrity impact on share management data. While lateral movement or data exfiltration are not directly enabled, the ability to silently remove access links across projects could be used to sabotage workflows or deny access to shared resources for other users (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of active in-the-wild exploitation as of the time of publication (Feedly). The vulnerability requires the attacker to already hold admin-level access to at least one project within the Vikunja instance, limiting the attack surface. The EPSS score is approximately 0.036–0.047%, placing it in the 15th percentile for exploitation likelihood. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Obtain admin access: Register or gain admin-level access to any project within the target Vikunja instance (e.g., by creating a new project, which grants admin rights by default).
2. Enumerate share IDs: Since link share IDs are sequential integers, iterate through candidate share IDs (e.g., 1, 2, 3, ...) to identify valid share IDs belonging to other projects.
3. Craft the DELETE request: Construct an HTTP DELETE request using your own project ID in the :project parameter and the target share ID in the :share parameter:

   DELETE /api/v1/projects/{your_project_id}/shares/{target_share_id}
   Authorization: Bearer <your_token>

4. Bypass authorization: The permission check validates admin access on your project (which passes), but the delete query executes WHERE id = {target_share_id} without checking project ownership.
5. Delete the target share: The link share belonging to another project is deleted, revoking shared access for users relying on that link (Vikunja Advisory, GitHub Advisory).

• Network: Repeated HTTP DELETE requests to /api/v1/projects/<project_id>/shares/<share_id> where the project ID in the URL does not match the project that owns the share; requests originating from a single user account targeting a wide range of sequential share IDs.
• Logs: API access logs showing a single authenticated user issuing DELETE requests against share IDs across multiple different projects; HTTP 200 or 204 responses to DELETE requests on shares not owned by the requesting user's project.
• Application Behavior: Unexpected disappearance of link shares from projects; users reporting that previously valid share links are no longer functional without any administrative action by the project owner (Vikunja Advisory).

Upgrade Vikunja to version 2.2.1 or later, which patches the issue by adding a project_id constraint to the delete query (WHERE id = ? AND project_id = ?). If immediate patching is not possible, restrict admin project access to trusted users only and monitor API logs for suspicious cross-project share deletion activity. The vendor also recommends applying the same fix defensively to the ReadOne method at line 203 of pkg/models/link_sharing.go (Vikunja Advisory, GitHub Advisory).

The vulnerability was published by Vikunja maintainer kolaente via a GitHub Security Advisory on March 23, 2026. The advisory notes this is part of a recurring pattern of IDOR vulnerabilities in the Vikunja codebase, referencing two prior similar issues (GHSA-jfmm-mjcp-8wq2 and GHSA-mr3j-p26x-72x4). No significant broader media coverage or notable external researcher commentary has been identified beyond standard vulnerability database aggregation (Vikunja Advisory).