Vikunja vulnerabilities

A vulnerability in Vikunja before version 2.2.1 allows unauthorized access to share hashes and downloading/deleting all file attachments across the instance. An authorization flaw in the LinkSharing.ReadAll and GetTaskAttachment endpoints enables privilege escalation to admin-level shares.

Vikunja 2.2.0 before 2.7.1 contains an HTML injection vulnerability in CreateConversationalHeader in pkg/notifications/mail.go that interpolates display names and task and project titles raw into email anchors. Authenticated users can craft titles or display names that close the anchor and inject phishing links into task-comment and task-mention notification emails sent to project members.

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

Vikunja 0.13.0 before 2.7.0 contains an incorrect authorization vulnerability that allows project members with Write permission to delete admin-tier link shares because the delete permission check reads an unloaded share object. Attackers can send DELETE requests to the v1 or v2 projects shares endpoints with sequential share IDs to revoke admin links and invalidate existing share sessions.

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.

Vikunja 0.22.0 before 2.7.0 contains an improper access revocation vulnerability that allows removed collaborators to keep receiving project data through webhooks they created. Former collaborators keep receiving task titles and descriptions through their webhook, including content created after their access was revoked.

Vikunja from 1.0.0-rc0 before 2.7.0 contains an improper authorization vulnerability in RecalculateTaskPositions that allows authenticated users with zero accessible projects to write task_positions rows for all tasks instance-wide. Attackers can delete their Inbox after repointing default_project_id, then create empty-filter saved filters to persist cross-tenant references and amplify writes for denial of service.

Vikunja 2.3.0 before 2.7.0 contains an improper session validation vulnerability that allows attackers to keep WebSocket access after revocation because handleAuth never checks the JWT sid claim against the sessions table. Attackers holding a stolen access token can open or maintain connections to /api/v2/ws after session deletion or TOTP enrollment, continuing to receive the victim's notification.created pushes, including comment, task and project content.

Vikunja versions prior to 2.4.0 store password-reset, email-confirmation, and account-deletion tokens in the user_tokens table in plaintext. An attacker with read access to the database can immediately use pending tokens to take over user accounts without knowing passwords. Version 2.4.0 fixes the issue.

Vikunja versions 1.0.0 through 2.3.0, when an administrator enables the per-provider emailfallback option on an OpenID Connect provider, links an SSO login to a pre-existing local account using only the email claim from the IdP, without checking email_verified or requiring the account password. An attacker with a token carrying a victim's email can log in as that victim without consent. Version 2.4.0 fixes the issue.

Vikunja version 2.3.0 allows a scoped API token limited to the oauth.authorize permission to call POST /api/v1/oauth/authorize, obtain an OAuth authorization code, and exchange it for a normal bearer JWT and refresh token. The resulting credentials are not restricted by the original token's permissions, granting access to routes outside its declared scope. Version 2.4.0 fixes the vulnerability.

Vikunja before 2.6.0 fails to properly restrict access to the link-share hash field in single-share read endpoints, allowing read-only members to obtain the share's secret credential. Attackers can exchange the disclosed hash for a link-share JWT at the share's permission level to escalate privileges and perform unauthorized writes or administrative actions.

Vikunja before 2.6.0 fails to validate that user-supplied project_view_id in task-position requests belongs to the task's project. Authenticated attackers can insert task position rows into arbitrary other tenant project views via POST or PUT task-position endpoints.

Vikunja before 2.6.0 contains an API token scope bypass vulnerability in task read endpoints where authorization fails to inspect query string parameters. Attackers with limited token scopes can use the expand parameter to access restricted data like comments, reactions, and time entries without proper permission verification.

Vikunja before 2.6.0 continues to expose the raw TOTP shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without re-authentication. Attackers with a valid access token can read the secret, import it into their own authenticator, and generate valid codes indefinitely to defeat the second factor and enable account takeover.

Vikunja versions before 2.6.0 fail to properly validate link-share tokens in the v2 API user search endpoints. Attackers with a read-only share link can enumerate project users via the projects endpoint and confirm arbitrary usernames exist via the global search endpoint.

vikunja before 2.6.0 fails to validate team access when attaching teams to projects, allowing authenticated users to enumerate all teams and members. Attackers can attach arbitrary team IDs via the project teams endpoint to retrieve complete team rosters including member names and admin flags for unauthorized teams.

Vikunja before 2.6.0 fails to limit archive expansion during data import, allowing authenticated users to cause denial of service. Attackers can upload highly compressed files that expand to tens of gigabytes in memory and disk, exhausting server resources and crashing the instance.

Vikunja before 2.6.0 contains an authentication bypass vulnerability in CalDAV BasicAuth endpoints that lack rate limiting protection. Remote unauthenticated attackers can issue unbounded credential-guessing requests against /dav, /.well-known, and /feeds routes to bypass the instance's anti-brute-force controls and compromise password-only accounts.

Vikunja versions before 2.6.0 fail to apply rate limiting to /api/v2 public authentication endpoints including login, register, password-reset, and OAuth token routes. Remote unauthenticated attackers can perform unbounded credential guessing, account enumeration, and password-reset flooding attacks without throttling restrictions.

Vikunja before 2.6.0 fails to apply pixel decode limits to avatar and project-background upload endpoints, allowing authenticated users to upload crafted images that decode to excessive pixel counts. Attackers can upload small images with extreme aspect ratios that consume significant CPU and memory during processing, causing denial of service through repeated or concurrent uploads.

Vikunja versions before 2.6.0 contain a resource exhaustion vulnerability in the Planka migrator that fails to enforce aggregate memory budgets during migration jobs. Authenticated attackers can submit migration requests pointing to attacker-controlled servers advertising numerous size-compliant attachments, exhausting worker memory and causing denial of service for all users.

vikunja versions before 2.6.0 contain a resource exhaustion vulnerability in the POST /api/v2/migration/csv/migrate endpoint that fails to limit parsed row cardinality. Authenticated attackers can upload multipart CSV files with millions of tiny records to exhaust process memory and terminate the API service.

vikunja versions before 2.6.0 contain a resource exhaustion vulnerability in the task-filter endpoint that accepts deeply nested filter expressions without recursion depth limits. Authenticated attackers can supply thousands of nested parentheses in the filter query parameter to exhaust memory and terminate the API process.

Vikunja before version 2.4.0 allows mass assignment of the project_view_id value in POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}. The permission check validates that the bucket belongs to the URL project and view but does not validate the destination view in the body, allowing any authenticated user to relocate an attacker-owned bucket into another tenant's Kanban view.

Vikunja before version 2.4.0 has a vulnerability in the POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks endpoint. Authorization only checks the project, view, and bucket from the URL, but does not check task permissions, allowing an authenticated user to read and modify tasks from other tenants.

Vikunja from version 0.24.6 to 2.4.0 has a vulnerability in the DELETE /api/v1/projects/:project/views/:view endpoint. An authenticated user can supply a view identifier from another project while authorization only checks the project identifier, allowing deletion of Kanban assignments and task ordering in other tenants.

Vikunja from 2.3.0 until 2.4.0 allows a user with Write but not Admin permission on a shared child project to detach it from its parent hierarchy by submitting parent_project_id equal to 0 to POST /api/v1/projects/{project}. The authorization check bypasses the Admin requirement for zero values, allowing bypass of the fix for CVE-2026-35595.

Vikunja from 0.21.0 until 2.4.0 allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. The permission check in the duplication operation skips the write-permission requirement for the parent project, allowing injection of content into another user's or team's project hierarchy.

Vikunja through 2.4.0 contains a principal-type confusion vulnerability where LinkSharing principals with id N are treated as user principals with users.id == N at three permission checks lacking type guards. Attackers with a link-share JWT can remove victims from teams, enumerate and delete victim bot users, or read team rosters by exploiting id collisions in the autoincrement space.

Vikunja versions >= 0.24.0 and <= 2.3.0 contain a broken object level authorization (BOLA) vulnerability in the GET /api/v1/projects/{project}/views/{view}/tasks endpoint. The endpoint loads the project view from the URL path without verifying authorization. A link-share token holder can read kanban bucket records (bucket titles and full created_by user object) from any view in the instance. The missing authorization also creates a project/view existence oracle (404 vs non-404). Task contents remain constrained to the share's own project.

Vikunja versions 0.22.0 through 2.3.0 fail to validate the principal type in API token management. A link-share JWT with a matching ID can be used to manage another user's tokens.

In Vikunja prior to 2.3.0, scoped API token enforcement for custom project background routes is method-confused. A token with only projects.background can delete a project background, while a token with only projects.background_delete is rejected, constituting a scoped-token authorization bypass.

In Vikunja prior to 2.3.0, the file import endpoint uses the attacker-controlled Size field from the JSON metadata inside the import zip instead of the actual decompressed file content length for the file size enforcement check. Setting Size to 0 while including large compressed file entries in the zip bypasses the configured maximum file size limit.

Vikunja prior to 2.3.0 builds iCalendar VTODO entries via raw string concatenation without RFC 5545 TEXT escaping. User-controlled task titles containing CRLF can break property boundaries and inject arbitrary iCalendar properties such as ATTACH, VALARM, or ORGANIZER.

In Vikunja prior to 2.3.0, task titles are embedded directly into Markdown link syntax in overdue email notifications without escaping Markdown special characters. When rendered by goldmark and sanitized by bluemonday (which allows <a> and <img> tags), injected Markdown constructs produce phishing links and tracking pixels in legitimate notification emails. This vulnerability is fixed in 2.3.0.

In Vikunja prior to 2.3.0, the addRepeatIntervalToTime function uses an O(n) loop that advances a date by the task's RepeatAfter duration until it exceeds the current time. Creating a repeating task with a 1-second interval and a due date far in the past triggers billions of loop iterations, consuming CPU and holding a database connection for minutes per request.

In Vikunja prior to 2.3.0, the CalDAV GetResource and GetResourcesByList methods fetch tasks by UID from the database without verifying that the authenticated user has access to the task's project. Any authenticated CalDAV user who knows a task UID can read full task data from any project.

Vikunja is an open-source self-hosted task management platform. Prior to 2.3.0, the TOTP failed-attempt lockout mechanism was non-functional due to a database transaction handling bug: after a failed TOTP validation, the login handler calls HandleFailedTOTPAuth and then unconditionally rolls back, undoing the StatusAccountLocked write and allowing unlimited brute-force attempts against TOTP codes; this is fixed in 2.3.0.

Vikunja prior to 2.3.0 contains a SQL operator precedence bug in the hasAccessToLabel function that allows any authenticated user to read any label with at least one task association, regardless of project access. Label titles, descriptions, colors, and creator information are exposed. The vulnerability is fixed in 2.3.0.

Vikunja is an open-source self-hosted task management platform. Prior to 2.3.0, link share authentication (GetLinkShareFromClaims in pkg/models/link_sharing.go) constructs authorization objects entirely from JWT claims without server-side database validation. When a project owner deletes a link share or downgrades its permissions, previously issued JWTs continue to grant the original permission level for up to 72 hours.