CVE-2026-33700: Vikunja Auth Bypass Vulnerability

CVE-2026-33700 Overview

CVE-2026-33700 is an Insecure Direct Object Reference (IDOR) vulnerability affecting Vikunja, an open-source self-hosted task management platform. Prior to version 2.2.1, the DELETE /api/v1/projects/:project/shares/:share endpoint fails to verify that the link share belongs to the project specified in the URL. This authorization bypass allows an attacker with admin access to any project to delete link shares from other projects by providing their own project ID combined with the target share ID.

Critical Impact

Attackers with project admin privileges can delete link shares from projects they do not own, potentially disrupting collaboration workflows and removing authorized access for legitimate users across the platform.

Affected Products

• Vikunja versions prior to 2.2.1
• Self-hosted Vikunja instances with link sharing enabled
• Vikunja deployments using the affected REST API endpoint

Discovery Timeline

• 2026-03-24 - CVE-2026-33700 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-33700

Vulnerability Analysis

This vulnerability stems from insufficient authorization checks in the project share deletion endpoint (CWE-639: Authorization Bypass Through User-Controlled Key). The API endpoint accepts two path parameters: a project ID and a share ID. While the endpoint verifies that the requesting user has admin privileges on the specified project, it neglects to validate that the share ID actually belongs to that project.

This creates a scenario where an attacker can leverage their legitimate admin access on Project A to delete link shares that belong to Project B, C, or any other project on the system. The attack requires only the share ID of the target, which may be enumerable or obtained through other means.

Root Cause

The root cause is a missing ownership validation check in the API's delete handler. When processing a deletion request, the application verifies user permissions against the project ID provided in the URL path but does not confirm the association between the share ID and the project ID. This allows the share ID to reference resources outside the attacker's authorized scope.

Attack Vector

The attack is network-based and requires authenticated access with admin privileges on at least one project within the Vikunja instance. An attacker would craft a DELETE request to /api/v1/projects/:project/shares/:share, substituting their own project ID (where they have admin rights) while specifying a share ID belonging to a different project. The server processes the deletion without validating the share-to-project relationship.

The vulnerability mechanism involves:

1. Attacker obtains or enumerates a target share ID from another project
2. Attacker constructs a DELETE request using their own project ID and the target share ID
3. Server validates admin permissions against the attacker's project (passes)
4. Server deletes the share without checking project ownership
5. Target project's link share is removed without authorization

For technical implementation details, see the GitHub Security Advisory.

Detection Methods for CVE-2026-33700

Indicators of Compromise

• Unexpected deletion of link shares reported by project administrators
• API logs showing DELETE requests to /api/v1/projects/:project/shares/:share where the project ID and share ID do not correspond
• Audit trails indicating share deletions by users who are not admins of the affected project
• User complaints about lost access to shared projects

Detection Strategies

• Implement correlation rules to detect DELETE requests where the authenticated user's project admin scope does not match the share's actual parent project
• Monitor for anomalous patterns of share deletion activity, particularly from single users affecting multiple projects
• Review API access logs for DELETE operations against the share endpoint with mismatched resource identifiers

Monitoring Recommendations

• Enable verbose API logging for all share management endpoints
• Configure alerting for share deletion events that cross project boundaries
• Implement database-level auditing to track share resource modifications and their originating requests
• Establish baseline metrics for normal share deletion patterns to identify anomalies

How to Mitigate CVE-2026-33700

Immediate Actions Required

• Upgrade Vikunja to version 2.2.1 or later immediately
• Audit recent API logs for potential exploitation of the vulnerable endpoint
• Review all link share configurations to ensure no unauthorized deletions have occurred
• Temporarily restrict API access if immediate patching is not possible

Patch Information

Vikunja version 2.2.1 addresses this vulnerability by implementing proper ownership validation on the share deletion endpoint. The patch ensures that the server verifies the share ID belongs to the specified project before processing the deletion request.

For patch details and release information, see the Vikunja Release Changelog. Additional security information is available in the GitHub Security Advisory.

Workarounds

• Implement reverse proxy rules to add additional validation on the share deletion endpoint
• Temporarily disable link share functionality if the feature is not critical to operations
• Restrict admin role assignments to trusted users only until the patch is applied

# Example: Update Vikunja using Docker
docker pull vikunja/vikunja:2.2.1
docker stop vikunja
docker rm vikunja
docker run -d --name vikunja -p 3456:3456 vikunja/vikunja:2.2.1