GitHub Advisoryadvisory · Go

GHSA-v3p6-34mc-hj7v Vikunja: Scoped API token can mint unrestricted OAuth session credentials

HIGH Published 2026-10-09 Modified 2026-10-09 Official page ↗
Aliases
CVE-2026-57458
Ecosystem
Go
Packages
code.vikunja.io/api
Severity
High
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Weaknesses
CWE-269
Reviewed
2026-10-09

Affected packages

• Go code.vikunja.io/api: >= 2.3.0, < 2.4.0 → fixed in 2.4.0

Description

Summary A scoped API token can bypass its declared permissions by using the OAuth authorization flow to mint normal session credentials. A token limited to: ```json {"oauth":["authorize"]} ``` can call `/api/v1/oauth/authorize`, receive an OAuth authorization code, exchange it at `/api/v1/oauth/token`, and obtain a normal bearer JWT plus refresh token. The resulting credentials are not restricted by the original API-token permissions. Affected Component • Scoped API tokens • OAuth authorization flow • `POST /api/v1/oauth/authorize` • `POST /api/v1/oauth/token` Impact A narrowly scoped API token with only `oauth.authorize` can be converted into normal session credentials for the same user. This bypasses the intended API-token permission boundary. An attacker who obtains or is delegated such a limited token can mint a normal JWT and refresh token, then access routes outside the original token scope. Runtime validation showed that the original scoped token could not access `GET /api/v1/user`, but the minted OAuth access token could access: • `GET /api/v1/user` • `GET /api/v1/projects` No cross-user access, privilege escalation to admin, or access to another account was validated. Technical Details The issue is caused by an authentication-context mismatch between scoped API-token authentication and OAuth authorization-code issuance. The vulnerable chain is: 1. A scoped API token authenticates the request and sets the current user context. 2. `/api/v1/oauth/authorize` accepts that API-token-authenticated user as a valid OAuth resource owner. 3. The OAuth authorization endpoint issues an authorization code. 4. `/api/v1/oauth/token` exchanges that code for a normal bearer JWT and refresh token. 5. The resulting credentials are not bound to the original API-token permissions. Relevant code paths: • `pkg/routes/routes.go` • registers `/api/v1/oauth/authorize` in an authenticated API route group that also accepts scoped API tokens • `pkg/models/api_routes.go` • exposes non-CRUD subroutes as API-token permissions • exposes the OAuth authorization endpoint under the `oauth` permission group • `pkg/routes/api_tokens.go` • stores `api_token` and `api_user` in the request context during API-token authentication • `pkg/user/user.go` • treats `api_user` as an authenticated current user • `pkg/modules/auth/oauth2server/authorize.go` • uses the current user and issues an OAuth authorization code • `pkg/modules/auth/oauth2server/token.go` • exchanges the authorization code for a normal JWT and refresh token Steps to Reproduce 1. Create a scoped API token Create an API token with only the following permission: ```json {"oauth":["authorize"]} ``` Observed response: ```http 201 Created ``` The returned token had only the `oauth.authorize` permission. 2. Negative control: direct access with scoped token fails Request: ```http GET /api/v1/user Authorization: Bearer ``` Observed response: ```http 401 Unauthorized ``` Response body: ```json {"code":11,"message":"missing, malformed, expired or otherwise invalid token provided"} ``` This confirms that the scoped token cannot directly access the normal user route. 3. Obtain an OAuth authorization code with the scoped token Request: ```http POST /api/v1/oauth/authorize Authorization: Bearer Content-Type: application/json ``` Body: ```json { "response_type": "code", "client_id": "vikunja", "redirect_uri": "vikunja-flutter://callback", "code_challenge": "", "code_challenge_method": "S256" } ``` Observed response: ```http 200 OK ``` Response body: ```json { "code": "", "redirect_uri": "vikunja-flutter://callback", "state": "" } ``` The scoped API token successfully obtained an OAuth authorization code. 4. Exchange the authorization code for session credentials Request: ```http POST /api/v1/oauth/token Content-Type: application/json ``` Body: ```json { "grant_type": "authorization_code", "code": "", "client_id": "vikunja", "redirect_uri": "vikunja-flutter://callback", "code_verifier": "" } ``` Observed response: ```http 200 OK ``` Response body: ```json { "access_token": "", "token_type": "bearer", "expires_in": 600, "refresh_token": "" } ``` The authorization code was exchanged for a normal access token and refresh token. 5. Use the minted access token on normal routes Request: ```http GET /api/v1/user Authorization: Bearer ``` Observed response: ```http 200 OK ``` Additional scope check: ```http GET /api/v1/projects Authorization: Bearer ``` Observed response: ```http 200 OK ``` The minted OAuth access token could access normal non-OAuth routes that the original scoped API token could not access. Expected Behavior A scoped API token should not be able to obtain credentials with broader permissions than its declared scope. `/api/v1/oauth/authorize` should require a normal user session or another authentication context suitable for OAuth authorization-code issuance. API-token-authenticated requests should not be accepted for minting OAuth authorization codes. Actual Behavior A token scoped only to `oauth.authorize` can obtain an OAuth authorization code and exchange it for a normal JWT plus refresh token. The minted credentials are not restricted by the original API-token permissions.

Related

Alias · CVE (1)

  • CVE-2026-57458 Vikunja is an open-source self-hosted task management platform. vulnerability

Weakness · CWE (1)

  • CWE-269 Improper Privilege Management weakness

References