CVE-2026-91980 in Vikunja
Summary
by MITRE • 09/15/2026
vikunja before 2.6.0 fails to validate team access when attaching teams to projects, allowing authenticated users to enumerate all teams and members. Attackers can attach arbitrary team IDs via the project teams endpoint to retrieve complete team rosters including member names and admin flags for unauthorized teams.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Vikunja versions prior to 2.6.0 represents a critical failure in access control logic, specifically within the mechanism used to associate teams with projects. This flaw stems from an insufficient validation of user permissions when processing requests that attach team entities to project resources. In a properly secured application state machine, any operation involving sensitive data structures such as team memberships must verify that the requesting authenticated user possesses explicit authorization for both the target resource and the associated entity. However, in this implementation, the backend API endpoint responsible for linking teams to projects does not adequately check whether the current session holder has administrative rights or membership within the targeted team before processing the attachment request. This oversight creates a direct path for unauthorized data access through what is technically classified as an Insecure Direct Object Reference (IDOR) vulnerability, corresponding to CWE-639 in standard security taxonomy.
The operational impact of this flaw allows authenticated users who lack legitimate affiliation with specific teams to enumerate and extract comprehensive details about those teams. By manipulating the input parameters sent to the project teams endpoint, an attacker can supply arbitrary team identifiers that they do not own or have permission to view. The system processes these requests without rejecting them based on ownership constraints, thereby returning full roster information for any valid team ID in the database. This includes sensitive personal data such as member names and administrative flags which indicate privilege levels within those teams. Such exposure facilitates further reconnaissance activities where an attacker can map out organizational structures, identify high-privilege accounts via admin flags, and potentially plan targeted social engineering or credential stuffing attacks against identified individuals.
From a threat modeling perspective aligned with the MITRE ATT&CK framework, this vulnerability enables techniques associated with Discovery, specifically Account Enumeration (T1087) and Internal Network Discovery if team structures reflect internal departmental divisions. The ability to retrieve admin flags is particularly dangerous as it aids in privilege escalation planning by highlighting which accounts hold elevated permissions within other teams. This behavior violates the principle of least privilege and fails to enforce proper object-level access controls, allowing lateral movement across organizational boundaries that should remain isolated from unauthorized users.
Mitigation for this issue requires immediate patching to version 2.6.0 or later where the developers have addressed these authorization checks. For environments unable to upgrade immediately, defensive measures include implementing strict server-side validation logic that verifies user membership in a team before allowing any read operations on its metadata. Additionally, adopting an allow-list approach for API endpoints and ensuring that all resource access requests are cross-referenced against explicit permission tables can prevent such enumeration attacks. Regular security audits focusing on authentication and authorization flows are recommended to detect similar gaps where identity verification is decoupled from data retrieval logic.