CVE-2026-33678: Insecure Direct Object Reference in Vikunja Task Attachments

Vikunja is an open-source self-hosted task management platform that provides REST API endpoints for managing tasks and associated attachments. CVE-2026-33678 identifies an Insecure Direct Object Reference (IDOR) vulnerability within the attachment handling logic of this API. The vulnerability allows authenticated users to bypass authorization checks and interact with file attachments belonging to tasks outside their authorized scope.

The core issue resides in the API endpoint responsible for retrieving and managing task attachments. The system relies on predictable, sequential integer identifiers for file attachments. When a user requests a specific attachment, the application fails to adequately verify the relationship between the authenticated user, the specified task, and the requested file.

This failure results in an authorization bypass classified under CWE-639. An attacker with standard user privileges can enumerate these sequential identifiers to systematically exfiltrate or delete files across the entire application instance. The vulnerability affects Vikunja installations running versions prior to 2.2.1.

The vulnerability originates in the data retrieval logic of the TaskAttachment.ReadOne() function. When a client requests an attachment via the /api/v1/tasks/{taskID}/attachments/{attachmentID} endpoint, the application performs a preliminary access control check. This CanRead() check strictly validates whether the authenticated user holds sufficient permissions to view the taskID specified in the URL path.

However, the application architecture fails to carry this authorization context forward into the data retrieval phase. The ReadOne() function constructs a database query using exclusively the attachmentID provided in the request payload. The underlying SQL query translates to an equivalent of SELECT * FROM attachments WHERE id = ?, explicitly omitting any condition that binds the attachment to the authorized taskID.

Consequently, the preliminary authorization check only serves as a gateway requirement. Once the application confirms the user can access the provided taskID, it blindly fetches the requested attachmentID from the database. The system then returns the resulting file or executes the requested deletion, creating a classical Insecure Direct Object Reference condition.

The vulnerability manifests in the separation between the HTTP handler's authorization middleware and the data layer's fetching logic. The vulnerable implementation retrieves records based solely on the primary key, disregarding the foreign key relationship that enforces data boundaries.

// Vulnerable implementation concept
func (ta *TaskAttachment) ReadOne() error {
    // The query only filters by the attachment ID
    return db.Where("id = ?", ta.ID).First(ta).Error
}

The mitigation implemented in Vikunja version 2.2.1 corrects this behavior by binding the requested object to its parent container during the database query. The patch modifies the ReadOne() function to require both the primary key and the associated foreign key.

// Patched implementation concept
func (ta *TaskAttachment) ReadOne() error {
    // The query now enforces the relationship between attachment and task
    return db.Where("id = ? AND task_id = ?", ta.ID, ta.TaskID).First(ta).Error
}

This explicit binding ensures that even if an attacker supplies an arbitrary attachment ID, the database engine will yield an empty result set unless the attachment genuinely belongs to the authorized task. This effectively neutralizes the IDOR attack vector at the data layer.

Exploitation of this vulnerability requires the attacker to possess a valid authentication token and access to at least one task within the target Vikunja instance. The attacker identifies their valid task ID, for example, Task ID 100. They then construct an HTTP request targeting the attachment endpoint, placing their valid task ID in the path and an arbitrary target attachment ID at the end.

GET /api/v1/tasks/100/attachments/5 HTTP/1.1
Host: target-vikunja-instance.local
Authorization: Bearer <attacker_token>

Because the attachment identifiers are generated as sequential integers, the attacker can automate this process. Using a script, the attacker increments the target attachment ID, sequentially downloading or deleting files stored on the server. The application consistently validates access against Task 100, subsequently serving the file associated with the incremented ID.

Furthermore, this vulnerability supports chaining with CVE-2026-33680, a link share hash disclosure flaw. CVE-2026-33680 permits an unauthenticated attacker to obtain valid task context from a read-only share link. An attacker can leverage this disclosed task hash to satisfy the initial CanRead() requirement, subsequently exploiting CVE-2026-33678 without any authenticated account on the system.

The primary impact of this vulnerability is a total compromise of confidentiality and integrity for all file attachments stored within the Vikunja instance. The CVSS v3.1 base score of 8.1 reflects the severity of this exposure, specifically highlighting the high impacts on both confidentiality and integrity metrics.

An attacker successfully exploiting this flaw gains unauthorized read access to sensitive documents, images, and data files uploaded by any user across the platform. This data exfiltration occurs without generating immediate alerts, as the requests rely on standard application API patterns and legitimate user sessions.

Additionally, the attacker can issue HTTP DELETE requests to the same endpoint. This allows for the systematic destruction of all attachments across the system. The lack of complex prerequisites and the predictable nature of sequential IDs result in an exceptionally low barrier to entry for weaponization.

The immediate and primary remediation strategy is upgrading the Vikunja installation to version 2.2.1 or later. This version contains the necessary logic changes to enforce authorization boundaries during data retrieval operations. Administrators should apply this patch systematically according to their deployment method.

If immediate patching is technically unfeasible, administrators can deploy detection mechanisms to identify ongoing exploitation attempts. Security Information and Event Management (SIEM) systems or Web Application Firewalls (WAF) should monitor for high-frequency requests targeting the /api/v1/tasks/*/attachments/* endpoint.

Specifically, detection logic should flag sessions or IP addresses that request multiple distinct attachment IDs within a short timeframe while reusing the same task ID in the URL path. This access pattern is highly anomalous for legitimate user behavior and serves as a strong indicator of sequential ID enumeration.