Vikunja versions prior to 2.7.1 have an authorization vulnerability in the TaskBucket.CanUpdate function. The flaw allows authenticated users with write access to two different projects to move a task from one project's kanban bucket to another without proper verification that both buckets belong to the same project. This can cause tasks to persist across projects incorrectly, affecting bucket limits and toggling the task's done state in done buckets.
Vikunja versions prior to 2.7.1 have a resource exhaustion vulnerability in the vikunja-file ZIP importer. Authenticated users can exploit this by uploading ZIP archives with excessive entries, including many empty or non-file entries that bypass per-entry limits. This causes the scanArchive function to process entries twice, leading to high CPU and memory consumption and potential denial of service.
Vikunja versions prior to 2.7.1 have a supply chain vulnerability in their mage release targets. These targets fetch the xgo module and Docker image using mutable 'latest' references. If an attacker compromises the upstream xgo module, image, or registry, they can inject malicious code into release binaries that are then signed and distributed as legitimate.
Vikunja versions prior to 2.7.1 have a vulnerability that allows project writers or view admins to create an unlimited number of kanban buckets. This lack of count caps leads to uncontrolled resource consumption, causing heavy database load when kanban boards are read.
Vikunja versions prior to 2.7.1 have a vulnerability where the PluginsDir and LogPath are not properly anchored to the service root path. This allows local attackers with write access to the startup working directory to plant malicious plugins that the server may load or to read sensitive log files such as audit.log. The vulnerability has a low severity rating with limited impact on confidentiality and integrity and no impact on availability.
Vikunja versions prior to 2.7.1 have an improper authorization vulnerability in the canDoBucket function. This flaw allows users with project write access to delete buckets by exploiting a mismatched view ID. Attackers can bypass the last-bucket protection by requesting deletion through another view's bucket endpoint, resulting in dangling references to default or done buckets and inconsistent task bucket states.
Vikunja veans versions before 2.7.1 have a credential exposure vulnerability. Malicious repository authors can specify an attacker-controlled server in the .veans.yml configuration file. When veans runs in an untrusted checkout, it may send sensitive credentials such as the VEANS_TOKEN bearer token, login passwords, TOTP codes, and other tokens to the attacker-controlled server. This exposure grants attackers access to the victim's Vikunja account.
Vikunja versions prior to 2.7.1 have an insecure file permissions vulnerability where localStorage.Write creates blobs that are world-readable. This allows local users on a shared host to read sensitive stored data such as attachments, project backgrounds, exports, and to copy the SQLite database to attempt offline password hash cracking.
Vikunja veans versions before 2.7.1 have a protocol downgrade vulnerability in the serverCandidates component. This flaw allows on-path attackers to force the use of plain HTTP instead of HTTPS during initialization and login. By blocking HTTPS ports, attackers can cause the client to accept unverified HTTP responses, enabling interception of sensitive data such as passwords, TOTP codes, and bot tokens, as well as cleartext API traffic.
Vikunja versions prior to 2.7.1 have a vulnerability that allows authenticated users to exhaust server memory by uploading multiple concurrent images. This uncontrolled resource consumption occurs during the decoding of avatar and background images, which can be exploited by sending many small, highly compressible PNG files decoded at very high resolutions, causing memory pressure or process termination.
Vikunja versions from 0.24.0 up to but not including 2.7.1 contain a nil pointer dereference vulnerability. This flaw allows project administrators to disrupt project views by saving a filter-mode bucket configuration with a null filter. The vulnerability causes the validateProjectViewFilters function to skip nil entries, leading to panics in kanban and task collection code during view reads, which results in HTTP 500 errors for all project members.
Vikunja versions from 2.0.0 up to but not including 2.7.1 have a vulnerability where the /api/v2 login and OIDC callback endpoints accept form-encoded bodies without CSRF or Origin checks. This flaw enables login cross-site request forgery (CSRF), allowing an attacker with an account to trick a victim into switching to the attacker's account by posting the attacker's credentials or OIDC code. This can expose data that the victim subsequently adds while logged into the attacker's account.
Vikunja versions prior to 2.7.1 have an insecure file permissions vulnerability that allows local users on a shared host to read dump archives created by the vikunja dump command. These archives are world-readable zip files located in the rootpath, potentially exposing sensitive information such as configuration files, password hashes, TOTP secrets, tokens, and stored files.
Vikunja versions prior to 2.7.1 have an information exposure vulnerability where the request logger records the raw URI of the /shares/:share/auth route. This logging behavior exposes link-share hashes in logs accessible to attackers with access to Vikunja or reverse proxy logs. These hashes are non-expiring and not password-protected, allowing attackers to reuse them to obtain project JWTs with read, write, or admin permissions.
Vikunja veans versions before 2.7.1 have a prompt injection vulnerability that allows project members with write access to inject instructions via project titles or task content. These injected instructions are rendered verbatim inside the coding agent's authoritative instruction block, potentially causing the agent to modify developer checkouts or execute commands. The vulnerability has a low CVSS score of 3.7 and requires low privileges with user interaction. No known exploits are reported in the wild, and no patch information is provided.
Vikunja versions from 0.22.0 up to but not including 2.7.1 have an information disclosure vulnerability. This flaw allows read-only project members to view full webhook target URLs by listing project webhooks. Sensitive tokens or API keys embedded in these URLs can be extracted and potentially reused by attackers until they are rotated.
Vikunja versions from 2.2.0 up to but not including 2.7.1 contain an authorization bypass vulnerability. This flaw allows attackers holding tokens scoped only to projects_webhooks to manage user-level webhooks of the owner by supplying a user_id in request bodies. Exploitation enables attackers to register user webhooks to their own receivers, thereby obtaining reminders and task payloads from all owner projects, as well as reading, modifying, or deleting existing user webhooks.
Vikunja versions prior to 2.7.1 have a cross-site request forgery (CSRF) vulnerability in the OAuth migration callbacks for Todoist, Microsoft To Do, and Trello. The lack of a bound state parameter allows attackers to trick logged-in users into importing attacker-controlled projects and tasks, potentially containing phishing links.
Vikunja versions from 2.4.0 up to but not including 2.7.1 have an authentication bypass vulnerability. This flaw allows disabled or locked users to maintain access via API tokens associated with their bot users. The vulnerability arises because token validation only verifies the bot user's status, not the status of the original user. Attackers with pre-existing bot tokens can continue to read and modify shared projects through multiple interfaces including the HTTP API, CalDAV, MCP, and feeds.
Vikunja veans versions prior to 2.7.1 have a symlink following vulnerability that allows attackers to cause the veans init process to write files outside the intended repository. This is achieved by crafting repository symlinks that redirect writes to arbitrary user files such as ~/.bashrc or to locations that install hooks and plugins globally.