CVE-2026-33700: Insecure Direct Object Reference (IDOR) in Vikunja Link Share Deletion

CVE-2026-33700 identifies a critical authorization bypass vulnerability within the open-source task management platform, Vikunja. The flaw resides specifically in the link share management component, which exposes the DELETE /api/v1/projects/:project/shares/:share API endpoint. This endpoint allows authorized users to revoke previously generated external access links for project resources.

The vulnerability is classified as CWE-639: Authorization Bypass Through User-Controlled Key. The application performs access control checks using the project ID parameter but fails to correlate the requested share ID with that specific project. This oversight breaks the fundamental security requirement that an authenticated user must only access or modify resources within their authorized domain.

Successful exploitation allows an authenticated user with administrative rights in a single project to arbitrarily delete link shares across the entire instance. This issue affects all Vikunja installations running versions prior to 2.2.1. The maintainers addressed the vulnerability in version 2.2.1 by implementing strict cross-ownership validation.

The root cause of CVE-2026-33700 stems from a decoupled authorization and resource retrieval implementation. When a client issues a DELETE request to the affected endpoint, the application's routing layer extracts both the :project and :share identifiers. The request first passes through an authorization middleware responsible for validating the user's permissions.

This middleware queries the database to confirm that the authenticated user holds administrative privileges for the specified :project ID. Once this check passes, the application routes the request to the deletion handler. The handler then processes the :share ID to execute the deletion query against the underlying database.

The critical flaw occurs during this database operation. The application executes the DELETE query using only the user-supplied :share ID, omitting any conditional clauses that would bind the share to the previously validated :project ID. Consequently, the application implicitly trusts the user-provided share ID based on the success of an unrelated access control check.

In the pre-patch state, the application logic processes the deletion request by extracting the share identifier and passing it directly to the database interface. The handler assumes that the preceding middleware has fully validated the contextual boundaries of the request. This assumption creates a direct object reference vulnerability.

The patched implementation in version 2.2.1 introduces a mandatory cross-reference check within the data access layer. The database query is modified to include the project identifier as an explicit condition. This change ensures that the query only affects rows where both identifiers align with the database schema.

By enforcing the project_id = ? condition in the DELETE statement, the application safely binds the user-controlled key to the authorized context. If an attacker attempts to supply a disjointed share ID, the database query returns zero affected rows. The application then correctly handles the null result without modifying unauthorized records.

Exploitation of CVE-2026-33700 requires the attacker to satisfy specific preconditions. The attacker must possess a valid authentication token for the Vikunja instance. Furthermore, the attacker must hold administrative privileges for at least one project, which serves as the pivot point for the authorization bypass.

The initial phase of the attack involves identifying a target share identifier. Since link share IDs often use sequential numeric values, an attacker can determine valid target IDs through enumeration. The attacker may also leverage concurrent information disclosure vulnerabilities to precisely map the share IDs of target projects.

DELETE /api/v1/projects/1/shares/100 HTTP/1.1
Host: vikunja.example.com
Authorization: Bearer <Attacker_Token>

To execute the exploit, the attacker crafts an HTTP DELETE request directed at their authorized pivot project. They append the enumerated target share ID to the URL path. The server processes the request, validates the attacker's permissions for the pivot project, and subsequently deletes the specified share from the database, regardless of its true project association.

The primary impact of CVE-2026-33700 affects the integrity of the application's data layer. An attacker can permanently remove link share records from the database, invalidating all external access URLs generated for those resources. This unauthorized modification directly undermines the system's access control mechanisms.

The secondary consequence is a localized denial of service affecting system availability. Collaborative workflows that depend on shared links will fail unexpectedly when the underlying database records disappear. Administrators must manually investigate the access failures, regenerate the link shares, and distribute the new URLs to external stakeholders.

The vulnerability carries a CVSS 4.0 score of 6.9, reflecting its medium severity. The High Privileges Required metric accurately represents the attack prerequisite, as the attacker must hold project administrative rights. The lack of confidentiality impact bounds the overall severity, as the vulnerability solely permits record deletion rather than data extraction.

The definitive remediation for CVE-2026-33700 requires upgrading the Vikunja application to version 2.2.1 or a subsequent release. The maintainers introduced structural changes to the database queries to enforce strict cross-ownership validation. Administrators should apply this patch during the next available maintenance window.

If immediate patching is unfeasible, system administrators can implement temporary mitigations at the network perimeter. Web Application Firewalls or API gateways can be configured to alert on high-frequency DELETE requests targeting the /api/v1/projects/*/shares/* endpoint. Monitoring these logs helps identify enumeration attempts indicative of exploitation.

Organizations should also enforce the principle of least privilege across the application. Administrators must regularly audit project permissions and revoke administrative rights from non-essential accounts. Reducing the pool of privileged users limits the internal attack surface and mitigates the risk of lateral manipulation.