Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as shared collaborator
-
ExploitLocate down-restricted child sub-project
-
ExecutionTrigger MAX-permission inheritance from parent
-
ImpactModify, delete, or re-share restricted child content
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Least privilege enforcement
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires: (1) the target running the specific vulnerable release Vikunja v2.6.0 (behavior regression not present in v2.5.0); (2) an authenticated user who is an existing collaborator; (3) a project hierarchy where that user holds a HIGHER permission (e.g. write/admin) on a parent project; and (4) an explicit LOWER-permission share (e.g. read-only) deliberately set by the owner on a child sub-project. The flaw only manifests for this down-restriction configuration - if no parent grant exists or the child is not nested, inheritance has nothing higher to override. Limiting factors: a valid account and membership in the shared project tree are mandatory (no anonymous/unauthenticated path), impact is confined to sub-projects the attacker can already reach via the hierarchy, and no cross-user or cross-tenant escalation beyond the misconfigured tree is indicated. |
| Impact | This is a genuine but low-to-moderate priority issue, not a critical remote threat. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows network reach and low complexity, but PR:L is decisive: exploitation is only possible for an already-authenticated collaborator who has been deliberately granted differing permissions across a parent/child project hierarchy. Impact is narrow - VC:N/VI:L/VA:N and no scope change (SC:N/SI:N/SA:N) - reflecting that the flaw grants unintended write/modify (and per the advisory, delete and re-share) on a single sub-project rather than system-wide compromise. No EPSS score, KEV listing, or SSVC decision data was provided in the input; absence of these is not evidence of safety but means widespread automated exploitation is not indicated. No public exploit code was provided - only a GHSA advisory with root-cause SQL analysis. Notably, the affected-versions data lists 'fixed in: None', so no patch is confirmed available, which raises residual risk for v2.6.0 operators even though the real-world attack surface (a trusted insider with partial access abusing a permission-inheritance regression) is inherently limited. |
| Exploit ScenarioDerived | An organization self-hosting Vikunja 2.6.0 gives a contractor write/admin access to a parent 'Engineering' project but explicitly down-restricts them to read-only on a sensitive child 'Security Roadmap' sub-project. Because the permission engine resolves the effective right as the maximum over the project tree, the contractor silently inherits the parent's higher permission on the child and can edit, delete, or re-share it (including granting others admin). No public exploit code exists, but the GHSA advisory documents the exact recursive-CTE flaw, making reproduction straightforward for an authenticated user. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 17, 2026
Vikunja 2.6.0 allows an authenticated collaborator who holds a higher permission on a parent project to override an explicitly set read-only share on a nested child project, enabling modification of that child's tasks and content. This broken access control is a permission-resolution regression introduced in 2.6.0 and only affects users who already have access to the project tree; no public exploit was identified at time of analysis. The issue is limited to integrity impact and is a low-to-moderate priority rather than a critical remote threat.
RemediationAI
No vendor-released patch was identified at time of analysis; monitor GHSA-pjr3-86v4-5p7w and the VulnCheck advisory for a fixed release and upgrade Vikunja as soon as one is available. In the interim, audit nested project permissions and ensure that any user intended to be read-only on a child project has no higher permission on any ancestor project (parent grants can be removed or the child moved to a separate top-level project). Be aware that removing parent-level grants may reduce that user's access to the parent and sibling projects, and restructuring the hierarchy changes inheritance behavior. If down-restriction shares must remain in place, avoid using them with 2.6.0 until a patched build is released, and review child projects for unexpected modifications by users who should have had read-only access.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Vikunja's project ACL engine in pkg/models/project_access.go computes effective permissions through a recursive SQL CTE. In 2.6.0, getProjectAccessForUser collects direct grants from project ownership, users_projects, and team_projects, propagates them down the parent_project_id hierarchy, and then applies MAX(permission) per project. This means a parent-level grant is inherited downward and can exceed an explicit lower grant on a child: for example, ADMIN(2) on the parent and READ(0) on the child resolves to ADMIN(2) on the child because MAX(0,2)=2. The root cause is CWE-269 improper privilege management, specifically a regression from 2.5.0's nearest-ancestor-wins resolution (ROW_NUMBER priority) to a maximum-over-subtree model in 2.6.0. The CVSS vectors specify PR:L, so exploitation requires an authenticated low-privileged collaborator, and impact is limited to integrity (I:L) within the affected nested project configuration.
Know when Vikunja gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Authenticated collaborator required (PR:L) over the network with no special complexity (AC:L); impact is unauthorized modification of a restricted sub-project (I:L) with no confidentiality loss and scope unchanged.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Weak password policy in Vikunja task management before 2.0.0 allows users to set trivially guessable passwords. PoC avai
Stored cross-site scripting (XSS) in Vikunja prior to version 2.0.0 allows authenticated attackers to steal authenticati
Vikunja before version 2.0.0 contains a path traversal vulnerability in its backup restoration function that fails to va
Vikunja is an open-source self-hosted task management platform. [CVSS 6.1 MEDIUM]
Business logic vulnerability in Vikunja task management platform before 2.1.0 allows incomplete resource cleanup, potent
Cross-tenant information disclosure in the self-hosted task manager Vikunja (0.24.0 through 2.3.0) lets a holder of any
Instance-wide data breach in Vikunja before 2.2.1 lets remote attackers exfiltrate and destroy every file attachment acr
Vikunja instances before 2.6.0 expose CalDAV BasicAuth endpoints (/dav, /.well-known, and /feeds) that are not covered b
Vikunja versions before 2.6.0 ship authentication endpoints under /api/v2 (login, register, password-reset, and OAuth to
Vikunja prior to 2.6.0 leaks the secret hash that backs a project's link shares through its single-share read endpoint,
Principal type confusion in Vikunja (versions 0.22.0-2.3.0) allows an authenticated low-privilege attacker to fully cont
Privilege escalation in Vikunja 2.3.0 allows a user who holds a narrowly scoped API token (permissions {"oauth":["author
EUVD-2026-103288
GHSA-r72j-vqhw-6264
NVD
CVE.org
VulDB
Exploit-DB