CVE-2026-55064: Vikunja Authorization Bypass Vulnerability

CVE-2026-55064 Overview

CVE-2026-55064 is a missing authorization vulnerability [CWE-862] in Vikunja, an open-source self-hosted task management platform. Affected versions from 2.3.0 up to (but not including) 2.4.0 allow a user with Write permission on a shared child project to detach it from its parent hierarchy. The user submits parent_project_id=0 to POST /api/v1/projects/{project}, bypassing the Admin requirement introduced for CVE-2026-35595. Detaching the project severs the recursive permission-inheritance chain and disrupts the owner's hierarchy and inherited collaborator access.

Critical Impact
Low-privileged authenticated users can break project hierarchy and inherited access without Admin rights.

Affected Products

Vikunja 2.3.0 through 2.3.x
Fixed in Vikunja 2.4.0
Self-hosted deployments exposing /api/v1/projects/{project}

Discovery Timeline

2026-08-28 - CVE-2026-55064 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-55064

Vulnerability Analysis

The vulnerability lives in Vikunja's project authorization logic. The Project.CanUpdate check in pkg/models/project_permissions.go and the UpdateProject handler in pkg/models/project.go gate reparenting only when parent_project_id is nonzero. However, UpdateProject persists any submitted value, including zero. This inconsistency permits an authenticated user with Write (not Admin) permission on a shared child project to detach it from its parent by explicitly submitting parent_project_id=0. The prior fix for CVE-2026-35595 blocked reparenting to a different nonzero project but overlooked the detach-to-root case.

Root Cause

The permission check compares p.ParentProjectID to zero before invoking CanWrite on the target parent. When the caller submits zero, the check short-circuits and no Admin gate applies. The persistence layer still writes the value, so the hierarchy edge is removed. The root cause is missing authorization on a valid but implicit state transition.

Attack Vector

An authenticated attacker with Write access to a shared child project sends a POST request to /api/v1/projects/{project} with a JSON body containing parent_project_id: 0. The server updates the project and removes it from the owner's hierarchy tree, breaking inherited collaborator permissions across descendants.

// Patched authorization check in pkg/models/project_permissions.go
// Only a real new parent (> 0) needs a write check here; detach-to-root
// (explicit 0) is gated for Admin in UpdateProject instead.
if p.ParentProjectID != nil && *p.ParentProjectID > 0 && *p.ParentProjectID != ol.parentID() {
    newProject := &Project{ID: *p.ParentProjectID}
    can, err := newProject.CanWrite(s, a)
    if err != nil {
        return false, err
    }
}
// Source: https://github.com/go-vikunja/vikunja/commit/781ffac198548ae4f3d1febc613caed8e0e11d01

Detection Methods for CVE-2026-55064

Indicators of Compromise

HTTP POST requests to /api/v1/projects/{project} with a JSON body containing "parent_project_id": 0.
Audit-log entries where a non-Admin collaborator modified parent_project_id from a nonzero value to zero.
Unexpected disappearance of child projects from an owner's hierarchy view.

Detection Strategies

Enable request-body logging on the Vikunja API and alert on updates that set parent_project_id to 0 by non-owner users.
Compare parent_project_id history in the database and flag transitions from nonzero to zero performed by users lacking Admin permission.
Baseline expected hierarchy changes and treat detach events from Write-only accounts as anomalies.

Monitoring Recommendations

Forward Vikunja application and reverse-proxy logs to a centralized logging platform for query and correlation.
Track per-user rates of project update calls to surface abuse patterns.
Alert operators when top-level projects gain new root-level siblings unexpectedly.

How to Mitigate CVE-2026-55064

Immediate Actions Required

Upgrade Vikunja to version 2.4.0 or later, which enforces the Admin gate on detach-to-root.
Audit recent project updates for parent_project_id=0 transitions and restore parent relationships where warranted.
Review sharing permissions and reduce Write access on sensitive parent hierarchies to Admin where feasible.

Patch Information

The fix is included in Vikunja v2.4.0 via commit 781ffac1 and pull request #3239. See the GitHub Security Advisory GHSA-44v6-7fxq-vgf4 for full details.

Workarounds

Restrict shared project permissions to Read-only until the patch is deployed.
Place the Vikunja API behind a reverse proxy that rejects POST bodies to /api/v1/projects/{project} containing parent_project_id: 0 from non-owner users.
Periodically snapshot the project hierarchy so unauthorized detachments can be reverted quickly.

bash

# Upgrade Vikunja to the patched release
docker pull vikunja/vikunja:v2.4.0
docker stop vikunja && docker rm vikunja
docker run -d --name vikunja \
  -v /path/to/vikunja/files:/app/vikunja/files \
  -v /path/to/vikunja/config.yml:/etc/vikunja/config.yml \
  -p 3456:3456 vikunja/vikunja:v2.4.0