CVE-2026-33312: Broken Object-Level Authorization (BOLA) in Vikunja Project Background Deletion

Vikunja is an open-source, self-hosted task management platform that allows teams to organize projects, tasks, and schedules. The platform utilizes a role-based access control (RBAC) system to restrict user actions based on their assigned permissions within specific projects. These permissions dictate whether a user can read, write, or update project properties, including aesthetic settings like background images.

CVE-2026-33312 identifies a Broken Object Level Authorization (BOLA) vulnerability within the project background management module. The vulnerability exists in the API endpoint responsible for deleting project background images. Due to a flaw in the permission validation logic, the endpoint fails to require the appropriate update privileges before executing the deletion operation.

This flaw allows users with explicitly read-only access to permanently delete project background images. The vulnerability affects Vikunja versions 0.20.2 through 2.1.x and is tracked under the primary weakness enumeration CWE-863: Incorrect Authorization. The issue exposes a direct bypass of the intended project authorization boundaries.

The root cause of CVE-2026-33312 lies in the reuse of a permission validation helper function across disparate HTTP methods. The backend Go implementation handles background deletion via the RemoveProjectBackground function, located in the pkg/modules/background/handler/background.go file. This handler processes incoming DELETE requests to the /api/v1/projects/:project/background endpoint.

To authorize the request, the handler invokes a shared helper function named checkProjectBackgroundRights. This helper was originally designed to validate access for the GET endpoint, which retrieves the background image. Consequently, the function only verifies that the requesting user holds CanRead permissions for the specified project object.

When processing a DELETE request, the backend performs a destructive operation that removes the file from the storage backend and nullifies the background_file_id and background_blur_hash database fields. Because the RemoveProjectBackground handler relies on the flawed helper function, it approves the destructive action for any user possessing mere CanRead access. The system fails to enforce the CanUpdate or CanWrite constraints required for state-altering requests.

The vulnerability stems from the authorization check within the RemoveProjectBackground function. The unpatched implementation queries the user's rights using a read-focused validation check. When the check passes, the application proceeds to execute the database update and file system deletion without further scrutiny.

// Vulnerable Implementation (Conceptual)
func RemoveProjectBackground(c web.Context) error {
    projectID := c.Param("project")
    
    // Flaw: checkProjectBackgroundRights only requires CanRead access
    err := checkProjectBackgroundRights(c, projectID)
    if err != nil {
        return err
    }
    
    // Destructive operations proceed...
    err = deleteBackgroundFile(projectID)
    err = updateProjectDatabase(projectID, nil, nil)
    return err
}

The fix introduced in version 2.2.0 addresses this by explicitly requiring update permissions. The authorization logic was refactored to differentiate between read operations and destructive operations. The patched handler now correctly mandates CanUpdate rights before allowing the deletion sequence to initiate.

// Patched Implementation (Conceptual)
func RemoveProjectBackground(c web.Context) error {
    projectID := c.Param("project")
    
    // Fix: Explicitly check for CanUpdate or CanWrite permissions
    err := checkProjectUpdateRights(c, projectID)
    if err != nil {
        return web.ErrForbidden("Insufficient permissions to modify project background")
    }
    
    // Destructive operations proceed...
    err = deleteBackgroundFile(projectID)
    err = updateProjectDatabase(projectID, nil, nil)
    return err
}

Exploitation of CVE-2026-33312 requires low technical complexity and relies on standard HTTP clients. The attacker must first identify the target project ID, which is visible in the application URL or API responses during normal interaction. The attacker also requires a valid authentication token, cookie, or link share that grants read-only access to the target project.

The attacker constructs a manual HTTP DELETE request targeting the project background endpoint. The request includes the read-only authorization bearer token in the headers. Because the backend authorization logic only checks for read access, the server accepts the request as valid and authorized.

curl -X DELETE "https://vikunja.example.com/api/v1/projects/{project_id}/background" \
     -H "Authorization: Bearer <read_only_token>"

Upon receiving the request, the server returns an HTTP 200 OK status. The background image is permanently removed from the storage backend, and the associated metadata is cleared from the database. This manipulation occurs entirely within the context of a low-privileged session, demonstrating a clear Broken Object Level Authorization (BOLA) attack path.

The security impact of this vulnerability is strictly categorized as a low-level integrity compromise. The attacker successfully modifies the state of the application by forcing the deletion of asset files and database records. The CVSS 4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N accurately reflects this scope, yielding a base score of 5.3.

The vulnerability does not allow attackers to read sensitive data, modify core task information, or execute arbitrary code. The impact is limited to the aesthetic configuration of the target project. However, the flaw exposes a significant architectural gap in the application's authorization implementation, highlighting the risks of reusing read-focused validation handlers for write or delete operations.

While the immediate consequence is confined to background images, BOLA vulnerabilities of this nature often indicate broader access control issues. The attack requires no user interaction and operates seamlessly over the network. Organizations relying on strict role separation for project visibility and management are directly affected by this permission boundary violation.

The primary remediation for CVE-2026-33312 is to upgrade the Vikunja application to version 2.2.0 or later. The go-vikunja maintainers have implemented a complete patch that correctly enforces CanUpdate permissions on the DELETE /api/v1/projects/:project/background endpoint. Administrators should deploy this update to all self-hosted instances immediately.

For organizations unable to apply the patch immediately, interim mitigations are limited due to the inherent nature of the vulnerability. Administrators can temporarily restrict the creation of read-only link shares and audit existing read-only team memberships. Reducing the pool of users with read access to sensitive projects minimizes the potential attack surface.

Security teams should also implement monitoring for anomalous DELETE requests targeting the background API endpoints. High volumes of deletion requests from users with explicitly restricted roles indicate potential exploitation attempts. Organizations utilizing Web Application Firewalls (WAFs) can create rules to alert on or block these specific requests originating from untrusted network segments.