Vikunja CVE-2026-57458

Exploitation requires the attacker to already hold a valid Vikunja API token for a target user that includes the oauth.authorize permission (the legacy {"oauth":["authorize"]} scope), and the server must be running the OAuth authorization flow reachable at POST /api/v1/oauth/authorize and POST /api/v1/oauth/token on version 2.3.0. No user interaction, no admin rights, and no non-default configuration are needed beyond possessing such a scoped token. Limiting factors: the attacker must obtain or be delegated that token (PR:L), the privilege gain is confined to the SAME user (no cross-user or admin escalation was validated), and upgrading to 2.4.0 - which removes oauth from the grantable scope catalogue and rejects API-token principals at the authorize/token endpoints - fully closes it.

This is a genuine but moderate-priority issue rather than a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) correctly reflects a network-reachable, low-complexity flaw that nonetheless REQUIRES an attacker to already possess a valid scoped API token (PR:L) - so it is a privilege/scope-boundary bypass (CWE-269), not an unauthenticated RCE. No EPSS score was supplied, the CVE is NOT in CISA KEV, and no public exploit code is referenced; the only exploitation evidence is the vendor's own runtime validation in the GHSA advisory, which is a proof-of-concept description, not released weaponized code. The C:H/I:H/A:N impact is credible for the affected user's own data but is bounded: the advisory explicitly states no cross-user access, no admin privilege escalation, and no access to other accounts was observed, so 'High' confidentiality/integrity applies only within the single compromised user's scope. Net: real and worth patching (the fix is a small, clear commit), but absent KEV/EPSS/public-POC signals and given the token-possession precondition, this is a targeted-abuse / insider-or-leaked-token risk rather than a mass-exploitation threat.

An attacker who is delegated or steals a deliberately narrow Vikunja API token scoped only to {"oauth":["authorize"]} calls POST /api/v1/oauth/authorize to obtain an authorization code, then exchanges it at POST /api/v1/oauth/token for a full bearer JWT and refresh token. Those minted credentials ignore the original token's permission boundary, letting the attacker reach routes the scoped token could not (e.g. GET /api/v1/user and GET /api/v1/projects) for that same user. The vendor advisory documents this as reproduced in runtime testing, but no public exploit tool is referenced.