Quick Take
- What: Authentication bypass in Vikunja task management software allows disabled users to keep working through bot API tokens
- Affected versions: Vikunja 2.4.0 through 2.7.0
- Fixed in: Version 2.7.1
- Impact: Disabled or locked accounts can still read and modify shared projects via HTTP API, CalDAV, MCP and feeds
- What to do: Upgrade to Vikunja 2.7.1 and manually revoke bot tokens for disabled accounts
In plain English
Vikunja is a task and project management tool. When an administrator disables or locks a user account (for example, when someone leaves the company or their account is compromised), that person can still access and change shared projects if they created a “bot user” and saved its access token beforehand. The system only checks whether the bot itself is disabled, not whether the human who owns the bot is disabled.
What you should do: If you run a Vikunja server, update to version 2.7.1 and manually delete bot tokens for any disabled accounts. If you only use Vikunja as a regular user and don’t run the server yourself, you don’t need to do anything.
What happened
Vikunja introduced bot users in version 2.4.0. Bot users are automation accounts that a human owner can create and generate API tokens for. When Vikunja checks an API token, it loads the bot user and verifies only that the bot itself is not disabled or locked. It does not check the status of the bot’s human owner.
When an administrator disables or locks a user account, Vikunja updates only that user’s database row. It does not cascade the status change to any bots owned by that user. As a result, every bot token minted before the owner was disabled continues to authenticate successfully.
An attacker (or a legitimately disabled user) holding a bot API token can continue to read and modify every project or team shared with the bot. This works across all Vikunja interfaces: the HTTP API (v1 and v2), CalDAV, MCP (Model Context Protocol) and RSS/Atom feeds.
The vulnerability was reported externally as TOK-BOT-01 and assigned CVE-2026-123493. The GitHub security advisory credits the reporter Cuong-VnC. The CVSS v4 score is 5.3 (Medium severity).
What you should do
Upgrade to Vikunja 2.7.1. The patch changes the authentication logic so that when the authenticating user is a bot, Vikunja also checks the owner’s status (Disabled, Locked, EmailConfirmationRequired). This makes the bot inherit its owner’s state without requiring a database cascade, so re-enabling the owner automatically restores the bots.
After upgrading, manually revoke API tokens for bots owned by disabled or locked accounts. The fix prevents future authentication but does not invalidate existing tokens.
What it means
The vulnerability undermines administrative account controls. When an admin disables a user for offboarding or incident response, they expect to cut off all access immediately. This bug leaves a backdoor: any bot tokens the user created remain valid indefinitely.
The impact is limited to users who created bots and minted tokens before being disabled, and only affects resources shared with those bots. It does not grant access to other users’ private projects. However, in a team environment where bots are shared across projects, a single disabled account can retain broad read/write access.
The fix in 2.7.1 closes the gap by tying bot authentication to the owner’s account status, ensuring that disabling an account immediately disables all automation owned by that account.
