Summary
Vikunja fails to distinguish between user identities and link-share principals when managing API tokens, allowing a link-share JWT to be misinterpreted as a real user if their numeric IDs match.
Under these conditions, an authenticated attacker can manipulate link shares to collide with a target user ID and then list, create, or delete that user's API tokens, effectively gaining a new API token with the target's privileges.
Affected context
This vulnerability appears in Vikunja's API token management functionality in versions 0.22.0 through 2.3.0.
It affects deployments where:
- Both user accounts and link shares are represented by numeric IDs
- A shared interface, such as
web.Auth.GetID(), abstracts principal identity - API token endpoints accept JWTs without verifying the principal type (user vs link-share)
In such environments, certain crafted link-share JWTs can be treated as if they belong to a real user.
Exploit preconditions
- Attack surface: Vikunja HTTP API, specifically
/api/v1/tokensendpoints. - Required access: Any authenticated account with the ability to create link shares and perform user searches.
- Trigger point: Use of a link-share JWT whose numeric ID matches a target user's ID against API token management endpoints.
- Why exploitation is possible: The authorization layer relies solely on a numeric principal ID returned by a generic auth interface, without enforcing that the principal type is a user when performing user-specific token operations.
Why this happens
The underlying bug is an authorization logic error where different principal types (users and link shares) are conflated because they share numeric identifiers and a common lookup path.
Vikunja's API token endpoints rely on a generic identity retrieval function (e.g., web.Auth.GetID()) and fail to assert that the caller is a user entity before performing user-scoped token operations.
This maps to CWE-863: Incorrect Authorization, as the system authorizes sensitive actions based on an incomplete or incorrect assessment of the calling principal's identity and role.
Potential impact
- An attacker may list a victim user's existing API tokens.
- An attacker could create new API tokens under a victim user's account with attacker-chosen scopes.
- An attacker may delete or revoke a victim user's API tokens, causing service disruption.
- An attacker can gain long-lived API access with the victim's privileges, enabling broader data or project compromise.
General mitigation guidance
Mitigation generally focuses on strengthening principal separation and authorization checks in token management flows.
Common defensive patterns include:
- Enforcing strict principal-type validation (e.g., only user principals can access user token endpoints).
- Using distinct identifier spaces or stable type tags for different principal classes to prevent collisions.
- Centralizing authorization logic so that sensitive operations explicitly validate both identity and role.
- Limiting token scope and lifetime by default to reduce the blast radius of any unintended issuance.
- Adopting least-privilege patterns for API tokens and avoiding over-broad, long-lived credentials.
How teams detect issues like this
Detection typically involves reviewing how identities and principals are modeled and authorized:
- Static analysis or manual code review to flag shared ID spaces used across multiple principal types without type checks.
- Examination of authentication middleware for generic identity getters that do not propagate principal type information.
- Logging and monitoring for unusual API token activity originating from link-share contexts or non-user principals.
- Policy-based tests or security-focused integration tests that attempt to use non-user JWTs against user-scoped endpoints.
Automated application security testing tools can assist by modeling different principal types and probing authorization boundaries.
