A flaw in the open-source task management app Vikunja means that disabling a user account does not always cut off that user's access. API tokens belonging to the user's bots keep working after the owner is disabled or locked, letting the tokens read and change shared projects. The vulnerability, tracked as CVE-2026-123493, was published on 8 November 2026 and affects Vikunja versions from 2.4.0 up to, but not including, 2.7.1. Version 2.7.1 fixes the problem.

Vikunja is a self-hosted, open-source tool for managing tasks and projects, used by teams that want to run their own to-do and kanban boards rather than rely on a cloud service. Version 2.4.0 introduced bot users, a form of automation account owned by a human user. A bot's owner can create API tokens for it, and those tokens can then act on the projects and teams shared with the bot.

The problem sits in how those tokens are checked. According to the security advisory published by the Vikunja project, every API-token check loads the token's owner, which is the bot itself, and tests only that account's status. None of the checks look at the bot's human owner. At the same time, changing a user's status only updates that user's own record and never cascades to the bots they own. The two gaps combine: an administrator who disables an account believes the access is gone, while the bot tokens minted before the disablement carry on working.

The advisory, reported externally under the reference TOK-BOT-01, sets out the impact plainly. After an admin disables or locks an account, for example during offboarding or because the account is believed compromised, every bot owned by that account keeps working with its full permissions. The tokens can read and write every project or team shared with the bot through the HTTP API, in both version 1 and version 2, as well as through CalDAV, the Model Context Protocol and feeds. The disabled user, or anyone else holding one of those bot tokens, can keep reading and changing that data, including projects the owner shared with the bot before being disabled.

The advisory also includes a proof of concept. A user creates a bot, shares a project with it and creates an API token owned by the bot. A request to read that project with the token succeeds. An administrator then disables the human user. Repeating the same request still succeeds, and write requests, such as creating a task, succeed too. The admin's disable action therefore does not fully revoke the user's access.

CVE-2026-123493 is rated Medium, with a CVSS version 3.1 score of 5.4 and a CVSS version 4.0 score of 5.3. The weakness is classified as CWE-613, insufficient session expiration. The flaw is not listed in the US Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalogue, and its EPSS score, an estimate of the chance of exploitation in the next 30 days, stands at 0.00226, which is very low. No exploitation in the wild has been reported.

The moderate score should not hide the practical risk. The flaw matters most in exactly the situation administrators care about: removing someone's access. Offboarding, a suspected compromise and a disciplinary suspension are all moments when an organisation needs revocation to be complete. A token that survives a disablement undermines that, and because bot tokens are designed for automation, they may sit in scripts, integrations and scheduled jobs where nobody notices them for months.

The recommended fix, described in the advisory, is for the shared authentication code to check the bot owner's status as well as the bot's own status whenever a bot token is used. That check should cover the disabled, locked and email-confirmation-required states, and it should apply across the API token, CalDAV, Model Context Protocol and feed paths. With that change, a bot inherits its owner's state, so re-enabling the owner restores the bots automatically and no separate status cascade is needed.

Administrators running Vikunja should upgrade to version 2.7.1, which contains the fix. Before or after upgrading, it is worth auditing bot accounts and their tokens, and revoking any tokens belonging to bots owned by users who have been disabled, locked or removed. Teams should also review which projects and teams are shared with bots, since a bot token's reach is set by those shares. Anyone who cannot upgrade immediately should treat bot tokens owned by disabled users as live credentials and revoke them by hand.

As with any self-hosted service, the lesson is a familiar one: access controls are only as strong as their weakest path, and automation accounts deserve the same lifecycle checks as the people who create them.