Vikunja CVE-2026-55067

The attacker must hold a valid authenticated session on the target Vikunja instance (any registered user account suffices; no elevated privileges required). The deployment must be multi-tenant - meaning at least one other user owns a separate project with a kanban view. The attacker needs a valid project_view_id for a victim view, which is feasible by enumerating sequential integers via the public API. No special server configuration, feature flag, or non-default setting is required; the vulnerable code path is active in any standard Vikunja deployment that uses kanban views (default behavior). Exploitation is bounded by two factors: the attacker must be authenticated (unauthenticated users cannot exploit this), and the impact is write-only defacement - the relocated bucket moves out of the attacker's authorization scope, so they cannot subsequently read or modify the victim's data.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N, score 5.0) accurately represents the threat: network-reachable, low complexity, requiring only a valid authenticated session (PR:L), with a scope change (S:C) because impact crosses tenant authorization boundaries. Integrity is low (I:L) - the attacker can inject arbitrary bucket titles into a victim's view but cannot read the victim's data, so confidentiality and availability are unaffected. A working POC is publicly documented in the advisory, materially lowering the exploitation barrier compared to a theoretical flaw. EPSS data was not provided in the intelligence feed. There is no CISA KEV listing, so active exploitation is unconfirmed. Real-world risk is meaningful for publicly accessible multi-tenant Vikunja instances where self-registration is enabled - any registered user becomes a potential attacker. Single-user, private, or access-restricted instances face negligible practical risk. The CVSS score is internally consistent with the described impact and is not inflated.

An attacker registers or logs into a public Vikunja instance, creates a bucket in their own project, then issues sequential integers as project_view_id values in POST requests to identify a victim's kanban view. By sending {"title":"PWNED BUCKET","project_view_id":<victim_view_id>} to the bucket update endpoint, the attacker's bucket is silently moved into the victim's kanban board - visible to the victim with the attacker's username as created_by - and only the victim can delete it. A working curl-based POC demonstrating this exact sequence is published in advisory GHSA-569v-q83c-3j3g.