These pages are published after PatchSiren validates generated defensive summaries against stored public CVE and source evidence.
CVE-2026-111919 is a high-severity vulnerability in Vikunja, a project management platform, that allows removed collaborators to continue receiving project data through webhooks they created, even after their access has been revoked. This issue affects Vikunja versions 0.22.0 before 2.7.0. The vulnerability is caused by an improper access revocation mechanism in Vikunja, which allows removed collaborators [truncated]
CVE-2026-111917 is a high-severity vulnerability in Vikunja versions 2.3.0 before 2.7.0. The vulnerability allows attackers to maintain WebSocket access after session revocation due to improper session validation. This could enable attackers to continue receiving notification pushes, including sensitive content. The vulnerability is caused by the handleAuth function not checking the JWT sid claim against [truncated]
CVE-2026-111921 is a medium-severity vulnerability in Vikunja versions 0.13.0 before 2.7.0 that allows project members with Write permission to delete admin-tier link shares due to an incorrect authorization check. This issue can be exploited by sending DELETE requests to the projects shares endpoints with sequential share IDs, potentially revoking admin links and invalidating existing share sessions.
A broken access control flaw was found in Vikunja 2.6.0, where 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 due to the system resolving a user's effective project permission as the maximum over the project tree. This issue arises from the system's failure to properly enforce explicit lower-permission shares on [truncated]
A vulnerability in Vikunja allows users with a link-share token to enumerate other users through the v2 API, which was not intended to be accessible with such tokens. This issue affects versions before 2.6.0 and allows for the listing of project members and testing of username existence across the instance. The vulnerability arises from improper validation of link-share tokens in the v2 API, specifically [truncated]
CVE-2026-91971 is a high-severity vulnerability in Vikunja before version 2.6.0, allowing authenticated users to upload crafted images that can cause a denial of service due to excessive CPU and memory consumption during processing. The vulnerability exists in the avatar and project-background upload endpoints, where pixel decode limits are not applied. Attackers can upload small images with extreme aspec [truncated]
Vikunja's `web.Auth` interface allows link-share principal-type confusion, enabling cross-account team removal, bot takeover, and roster disclosure due to missing type guards in permission checks. This issue arises because both `*user.User` and `*models.LinkSharing` satisfy the `web.Auth` interface, with a link-share's `GetID()` returning the raw positive `share.ID`, which shares the same positive autoinc [truncated]
A critical vulnerability in Vikunja allows unauthorized access to kanban buckets and user information across tenants via a link-share token. This Broken Object Level Authorization (BOLA) vulnerability enables an attacker to read bucket records and enumerate usernames and IDs instance-wide. The vulnerability arises from the task-collection endpoint's failure to verify caller authorization for project views [truncated]
Vikunja's API token management is vulnerable to cross-account issuance and management due to link-share principal ID collision. An authenticated attacker can obtain a target's numeric user ID, create link shares on an attacker-writable project, and treat the colliding link-share principal as the target user. This allows listing the target's API-token metadata, issuing new API tokens, and deleting target-o [truncated]
CVE-2026-40103 is a medium-severity vulnerability in Vikunja, a self-hosted task management platform. The issue involves method-confused scoped API token enforcement for custom project background routes, allowing unauthorized deletion of project backgrounds. This vulnerability was fixed in version 2.3.0. Defenders should assess exposure and prioritize upgrading to version 2.3.0 or later. Reviewing and res [truncated]
CVE-2026-35602 is a vulnerability in the Vikunja open-source self-hosted task management platform that allows an attacker to bypass the configured maximum file size limit by manipulating the Size field in the JSON metadata of a zip file used for file import. This issue was fixed in version 2.3.0. Affected deployments should be verified and updated to prevent potential file size limit bypass. Defenders sho [truncated]
A vulnerability in Vikunja, a self-hosted task management platform, allows for injection of arbitrary iCalendar properties due to improper escaping of user-controlled task titles. This issue, fixed in version 2.3.0, has a CVSS score of 4.1 and is considered medium severity. The vulnerability arises from the CalDAV output generator building iCalendar VTODO entries via raw string concatenation without apply [truncated]
CVE-2026-35600 is a vulnerability in Vikunja, an open-source self-hosted task management platform. The vulnerability allows for phishing links and tracking pixels to be injected into legitimate notification emails due to task titles being embedded directly into Markdown link syntax in overdue email notifications without proper escaping of Markdown special characters. This issue was fixed in version 2.3.0.
CVE-2026-35599 is a vulnerability in Vikunja, an open-source self-hosted task management platform. The addRepeatIntervalToTime function has an O(n) loop that can be triggered to consume CPU and hold a database connection for minutes by creating a repeating task with a 1-second interval and a due date far in the past. This issue is fixed in version 2.3.0.
CVE-2026-35598 is a vulnerability in Vikunja, an open-source self-hosted task management platform. Prior to version 2.3.0, the CalDAV GetResource and GetResourcesByList methods allow any authenticated CalDAV user to read full task data from any project by guessing or knowing a task's UID. This issue is fixed in version 2.3.0. Defenders managing Vikunja instances should assess exposure and prioritize upgra [truncated]
CVE-2026-35597 debrief: A vulnerability in Vikunja, a self-hosted task management platform, allows unlimited brute-force attempts against Time-Based One-Time Password (TOTP) codes due to a database transaction handling bug. This issue was fixed in version 2.3.0. The vulnerability arises from a bug in the login handler of Vikunja, which causes the database session to roll back after a TOTP validation failu [truncated]
CVE-2026-35596 is a vulnerability in Vikunja, an open-source self-hosted task management platform. Prior to version 2.3.0, the hasAccessToLabel function contains a SQL operator precedence bug that allows any authenticated user to read any label that has at least one task association, regardless of project access. This exposure includes label titles, descriptions, colors, and creator information. The vulne [truncated]
A vulnerability in Vikunja, a self-hosted task management platform, allows users with inherited Write access to move projects under their own project tree, potentially escalating privileges. The issue arises from the CanUpdate check at pkg/models/project_permissions.go:139-148, which only requires CanWrite on the new parent project when changing parent_project_id. However, Vikunja's permission model uses [truncated]
CVE-2026-35594 is a vulnerability in Vikunja, an open-source self-hosted task management platform. The vulnerability is related to link share authentication, where authorization objects are constructed entirely from JWT claims without server-side database validation. This allows previously issued JWTs to continue granting original permission levels for up to 72 hours after a project owner deletes a link s [truncated]
CVE-2026-34727 is a high-severity vulnerability in Vikunja, a self-hosted task management platform. The OIDC callback handler issues a full JWT token without checking if the matched user has TOTP two-factor authentication enabled, potentially skipping the second factor when a local user with TOTP enrolled is matched via the OIDC email fallback mechanism. This issue was fixed in version 2.3.0.
