OpenAM versions from 14.5.1 up to but not including 16.1.4 contain a cross-site request forgery (CSRF) vulnerability in the OAuth 2.0 device authorization flow. This flaw allows attackers to approve device codes without user consent when consent is skipped for implied-consent clients. An attacker can initiate a device authorization and trick a logged-in user into visiting a malicious page, thereby obtaining access and ID tokens to impersonate the user in API calls.
Vikunja versions prior to 2.7.1 have an authorization bypass vulnerability that enables authenticated users to read any task. This is achieved by injecting a crafted task object during a no-op Kanban bucket move, allowing attackers to access task details they should not have permission to view.
Vikunja versions prior to 2.7.1 have a vulnerability where authenticated users can cause uncontrolled resource consumption by requesting avatars at many distinct sizes. This can exhaust server memory, leading to the API process being terminated due to out-of-memory conditions.
Vikunja versions from 2.4.0 up to but not including 2.7.1 contain an authorization bypass vulnerability. This flaw arises from colliding permission keys between v1 and v2 API tokens, allowing token holders to perform unauthorized actions. Specifically, tokens scoped only for reading project backgrounds can delete them via the v2 DELETE background endpoint, and tokens limited to bucket creation can update existing buckets.
Vikunja versions prior to 2.7.1 have a vulnerability in session expiration handling. This flaw allows users holding revoked access tokens to continue authenticating because the SetupTokenMiddleware bypasses session and account-status verification. Consequently, attackers with stolen tokens can maintain persistent access by minting OAuth sessions or API tokens even after logout, password reset, or account disabling.
Vikunja versions prior to 2.7.1 have a stored CSS injection vulnerability that allows authenticated users with project write access to inject arbitrary CSS via unsanitized table-cell data-background-color attributes. This can be exploited by storing crafted task descriptions or comments to create phishing overlays or force background-image requests that can deanonymize viewers.
Vikunja versions from 0.23.0 up to but not including 2.7.1 have an information disclosure vulnerability. Project collaborators with write access can exploit this flaw by registering webhooks to read tasks from projects they should not access. The webhook payloads are generated with the permissions of the user triggering the event, allowing attackers to obtain titles, descriptions, and metadata of tasks from private projects when linked tasks are modified.
Vikunja versions prior to 2.7.1 have a mass assignment vulnerability that allows any authenticated user to set the read-only external_id field via team creation and update endpoints. This flaw enables attackers to mark a team as externally managed, which permanently blocks removal of all members and causes single sign-on (SSO) members to be dropped from the team upon their next login.
Vikunja versions prior to 2.7.1 have a vulnerability that allows attackers holding a valid session to brute-force account passwords through unthrottled re-authentication endpoints. Specifically, attackers can repeatedly attempt password guesses via the /user/settings/totp/disable endpoint without triggering lockout mechanisms, enabling them to disable two-factor authentication (TOTP) without a code. This flaw can lead to persistent account takeover.
Vikunja versions prior to 2.7.1 have a missing authentication vulnerability that allows attackers with a stolen session to enroll and enable TOTP (Time-based One-Time Password) without needing the account password. This enables attackers to call the TOTP enroll and enable endpoints using their own secret, effectively locking the legitimate user out of their account. This lockout persists even after the user resets their password.
Vikunja versions prior to 2.7.1 have a vulnerability in their Trello, Todoist, and Microsoft To Do migration importers where memory allocation is unbounded. Authenticated users can trigger migrations that cause excessive memory use by referencing large attachments or oversized API responses, leading to memory exhaustion and crashing the shared API process.
Vikunja versions from 1.0.0 up to but not including 2.7.1 have a vulnerability that allows authenticated users to bypass the service.maxitemsperpage limit by sending page=0 to certain API list endpoints. This can cause unbounded SQL queries and excessive memory use, degrading service availability.
Vikunja versions from 0.18.0 up to but not including 2.7.1 contain a privilege escalation vulnerability. This flaw allows team owners to escalate their privileges to admin or ownership of read-only shared projects by exploiting account deletion functionality. Specifically, attackers can create a bot, add it to their team, and then delete it via the bots endpoint, which triggers a function that improperly promotes read-only shares and locks out the legitimate owner.
Vikunja versions prior to 2.7.1 have a denial of service vulnerability that allows authenticated users to exhaust API process memory by uploading large WeKan or vikunja-file imports without item-count limits. Attackers can submit a large (~22 MB) WeKan JSON file containing hundreds of thousands of cards or duplicate IDs to the migration endpoint, causing an out-of-memory condition and crashing the instance.
Vikunja versions prior to 2.7.1 embed live tokens for password reset, email confirmation, and account deletion in URL query strings sent via email. These URLs, when clicked, cause the full request URI including sensitive tokens to be logged in Vikunja's HTTP access logs and any reverse-proxy logs. An attacker with access to these logs could replay unredeemed tokens to hijack accounts or confirm account deletions.
Vikunja versions prior to 2.7.1 have a client-side request forgery vulnerability that allows users with write access to embed image elements in rich text fields. This can cause viewers' clients to make unintended requests to loopback or LAN addresses, potentially exposing local services to unauthorized access or tracking when content is viewed.
Vikunja versions prior to 2.7.1 have a vulnerability involving improper resource cleanup that causes full-data export archives to remain orphaned on disk after export operations or account deletions. Authenticated users can repeatedly trigger exports, leading to disk storage exhaustion. Additionally, personal data of deleted users is retained indefinitely due to this issue.
Vikunja versions prior to 2.7.1 have a credential exposure vulnerability that allows attackers to steal stored authentication tokens. This occurs when an attacker tricks a user into switching the frontend API URL, causing the application to send bearer tokens and OAuth refresh tokens to the attacker's server. This vulnerability can lead to account takeover.
Vikunja versions prior to 2.7.1 have a vulnerability that allows authenticated CalDAV clients to cause uncontrolled resource consumption. By sending VTODO requests with thousands of RELATED-TO properties, attackers can create a large number of dummy tasks and related database entries. This results in database bloat and overload of the event processing pipeline.
Vikunja versions prior to 2.7.1 have an information disclosure vulnerability that allows authenticated users to infer the existence and certain attributes of private teams by sending DELETE requests to a specific team member removal endpoint. This flaw enables attackers to distinguish whether a team exists, if it is managed by SSO, or if it has only one member based on the server's responses.