CVE-2026-91984: Vikunja Authentication Bypass Vulnerability

CVE-2026-91984 Overview

CVE-2026-91984 is a broken object level authorization flaw in Vikunja, an open-source task management platform, affecting all versions before 2.6.0. The application fails to validate that a user-supplied project_view_id in task-position requests belongs to the task's parent project. Authenticated attackers can send crafted POST or PUT requests to the task-position endpoints and insert task position rows into project views owned by other tenants. The issue is tracked as CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact

Any authenticated Vikunja user can write task-position data into arbitrary cross-tenant project views, violating multi-tenant isolation.

Affected Products

• Vikunja versions prior to 2.6.0
• Self-hosted Vikunja deployments exposing task-position API endpoints
• Multi-tenant Vikunja instances shared across untrusted user groups

Discovery Timeline

• 2026-09-15 - CVE-2026-91984 published to NVD
• 2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-91984

Vulnerability Analysis

Vikunja exposes API endpoints that record the ordering of tasks within a specific project view. Each task belongs to a project, and each project can have multiple views such as list, kanban, or gantt. The task-position endpoints accept a project_view_id parameter that identifies where the position row is written.

The server accepts the client-supplied project_view_id without confirming that the referenced view belongs to the same project as the task being repositioned. An authenticated attacker can substitute a project_view_id that belongs to a different tenant's project. The backend then inserts a task position row into that unrelated view.

The result is a cross-tenant data integrity issue. Attackers cannot read the victim project's content through this specific flaw, but they can pollute another tenant's view state and inject rows referencing attacker-controlled tasks.

Root Cause

The root cause is missing authorization on a foreign key input. The endpoint trusts that any project_view_id submitted by an authenticated user is valid for the associated task. No relational check enforces that the view's parent project matches the task's parent project, and no ownership check enforces that the requesting user has write access to the target view.

Attack Vector

Exploitation requires network access to the Vikunja API and valid authenticated credentials with permission to reposition at least one task. The attacker issues a POST or PUT request to the task-position endpoint, replacing the legitimate project_view_id in the JSON body with the identifier of a view belonging to another tenant. The server processes the request and writes the row without rejecting the mismatched identifier. No user interaction on the victim side is required.

Refer to the GitHub Security Advisory GHSA-w39f-h553-h2mx and the VulnCheck Vikunja Advisory for further technical details.

Detection Methods for CVE-2026-91984

Indicators of Compromise

• Task position rows in the database where the referenced project_view_id belongs to a project different from the task's parent project.
• API access logs showing POST or PUT requests to task-position endpoints where the request body's project_view_id does not correspond to the task's project.
• Unexpected task ordering changes or ghost task entries reported by tenants that did not initiate the change.

Detection Strategies

• Run a database consistency query joining task position rows to their project views and parent tasks, and flag any row where the view's project ID does not match the task's project ID.
• Enable verbose API request logging on Vikunja and audit task-position endpoint payloads for cross-tenant identifier patterns.
• Correlate authentication logs with task-position write activity to detect a single account modifying views across many distinct tenants.

Monitoring Recommendations

• Alert on any Vikunja API user account issuing task-position writes at anomalously high volume or against many distinct project views.
• Baseline normal per-user access to project view identifiers and alert on deviations that indicate cross-tenant identifier probing.
• Retain Vikunja application logs long enough to support retrospective auditing once the patched version is deployed.

How to Mitigate CVE-2026-91984

Immediate Actions Required

• Upgrade all Vikunja instances to version 2.6.0 or later without delay.
• Audit existing task position data for cross-project inconsistencies introduced before the upgrade and remove stale rows.
• Rotate or review API tokens for any account showing anomalous task-position activity during triage.

Patch Information

The Vikunja maintainers released version 2.6.0, which adds server-side validation ensuring that the supplied project_view_id belongs to the same project as the task being repositioned. Deployment guidance and full patch context are available in the GitHub Security Advisory GHSA-w39f-h553-h2mx.

Workarounds

• If immediate upgrade is not possible, restrict Vikunja API access to trusted user groups using network controls or an authenticating reverse proxy.
• Temporarily disable shared multi-tenant usage until the patched version is deployed.
• Add a reverse-proxy rule that inspects task-position request bodies and rejects requests where the project_view_id is not one of the requesting user's own view identifiers.

# Configuration example: upgrade Vikunja container to the patched release
docker pull vikunja/vikunja:2.6.0
docker stop vikunja && docker rm vikunja
docker run -d --name vikunja \
  -p 3456:3456 \
  -v /opt/vikunja/files:/app/vikunja/files \
  -v /opt/vikunja/config.yml:/app/vikunja/config.yml \
  vikunja/vikunja:2.6.0