CVE-2026-57458 in Vikunja
Summary
by MITRE • 10/10/2026
Vikunja is an open-source self-hosted task management platform. In version 2.3.0, a scoped API token limited to the `oauth.authorize` permission can call `POST /api/v1/oauth/authorize`, obtain an OAuth authorization code, and exchange the code at `POST /api/v1/oauth/token` for a normal bearer JSON Web Token (JWT) and refresh token. The resulting credentials are not restricted by the original API token's permissions, allowing access to routes outside its declared scope for the same user. Version 2.4.0 fixes the vulnerability.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in Vikunja versions prior to 2.4.0 represents a critical flaw in the implementation of OAuth 2.0 authorization flows, specifically involving token scoping and validation mechanisms. As an open-source self-hosted task management platform, Vikunja relies on robust access control to ensure that users and applications can only perform actions authorized by their assigned permissions. The core issue arises from how scoped API tokens are processed during the OAuth authentication sequence. An attacker possessing a limited API token with only the oauth.authorize permission was able to exploit this weakness to escalate privileges significantly beyond its intended scope. This flaw undermines the fundamental principle of least privilege, allowing unauthorized access to sensitive resources and potentially leading to full account compromise for any user whose credentials were targeted.
The technical mechanism of the exploitation involves a specific sequence of HTTP requests that abuse the OAuth 2.0 authorization code grant flow. Initially, an actor uses the restricted API token to call POST /api/v1/oauth/authorize. Because the token holds the oauth.authorize permission, this request is accepted by the server, resulting in the issuance of an OAuth authorization code. The critical failure occurs when this temporary authorization code is exchanged for a permanent access credential at POST /api/v1/oauth/token. Instead of generating a new JWT that respects and inherits the restrictive permissions of the original API token used to initiate the flow, the system issues a standard bearer JSON Web Token (JWT) along with a refresh token. These newly issued credentials are not bound by the limitations of the initial scope, effectively stripping away the security constraints imposed on the originating token.
The operational impact of this vulnerability is severe due to the unrestricted nature of the resulting JWTs. Once an attacker obtains these tokens through the described flow, they gain access to API routes and endpoints that were explicitly outside the declared scope of their original credentials. This means a user or application intended only to authorize OAuth flows can inadvertently become a full administrator for that specific user account within Vikunja. The ability to exchange a limited token for an unrestricted bearer token creates a direct path for privilege escalation, allowing attackers to read, modify, or delete tasks, manage users, and access sensitive configuration data without detection by standard scope-based logging mechanisms.
From a standards perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, as the system fails to enforce appropriate administrative permissions on generated tokens relative to their origin. It also reflects weaknesses in authentication logic that can be categorized under MITRE ATT&CK technique T1078 Valid Accounts, where legitimate credentials are used to gain unauthorized access by bypassing intended restrictions. The flaw highlights a common pitfall in OAuth implementations where the token generation endpoint does not properly inherit or validate the scope constraints of the authorization request initiator. This oversight allows attackers to leverage valid but limited tokens as keys to unlock broader system capabilities, effectively nullifying the security model designed around scoped permissions.
Mitigation for this issue requires immediate upgrading to Vikunja version 2.4.0 or later, where the developers have corrected the token generation logic to ensure that JWTs issued via OAuth flows inherit the restrictions of the initiating API token. For organizations unable to upgrade immediately, monitoring logs for unusual patterns in OAuth authorization and token exchange endpoints may provide early detection indicators. Security teams should also review their access control policies to ensure that any remaining scoped tokens are granted only the minimum necessary permissions, reducing the blast radius if similar flaws exist elsewhere in the application architecture. Regular audits of authentication flows against industry standards like OWASP API Security Top 10 can help identify and remediate such privilege escalation vectors before they are exploited in production environments.