CVE-2026-57458

## 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 <scoped-api-token> ``` 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 <scoped-api-token> Content-Type: application/json ``` Body: ```json { "response_type": "code", "client_id": "vikunja", "redirect_uri": "vikunja-flutter://callback", "code_challenge": "<pkce-s256-challenge>", "code_challenge_method": "S256" } ``` Observed response: ```http 200 OK ``` Response body: ```json { "code": "<redacted>", "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": "<redacted>", "client_id": "vikunja", "redirect_uri": "vikunja-flutter://callback", "code_verifier": "<original-pkce-verifier>" } ``` Observed response: ```http 200 OK ``` Response body: ```json { "access_token": "<redacted>", "token_type": "bearer", "expires_in": 600, "refresh_token": "<redacted>" } ``` 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 <minted-oauth-access-token> ``` Observed response: ```http 200 OK ``` Additional scope check: ```http GET /api/v1/projects Authorization: Bearer <minted-oauth-access-token> ``` 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.

Vikunja: Scoped API token can mint unrestricted OAuth session credentials in code.vikunja.io/api. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: code.vikunja.io/api from v2.3.0 before v2.4.0.