The vulnerability exists in Vikunja versions 0.18.0 through 2.7.1 and allows a team owner to elevate privileges by deleting an account. By creating a bot and then deleting it via the bots endpoint, the system’s account deletion logic triggers a function that promotes any read‑only shared projects to admin status, effectively giving the attacker ownership of those projects. This flaw is a classic privilege escalation that could grant an attacker control of project data without prior administrative rights.

Vikunja installations powered by the go-vikunja:vikunja product, specifically any releases from 0.18.0 up to but not including 2.7.1. The vulnerability is tied to the application’s account management and project sharing components, so any deployment exposing the bots API is potentially affected.

The CVSS score of 7.1 reflects a high severity vulnerability, and while the EPSS score is not available, the existence of an authenticated API endpoint and the documented exploitation path imply a relatively low attack effort. The flaw is not listed in CISA’s KEV catalog, indicating no known widespread exploitation reports, but the ease of creating and deleting a bot account makes it an attractive vector for insiders or compromised team owners. The lack of a public exploit does not diminish the risk, as the required permissions are typically part of normal team owner duties.