Go Vikunja
Monthly
Vikunja prior to 2.6.0 leaks the secret hash that backs a project's link shares through its single-share read endpoint, so any authenticated user holding only read-only membership in a project can read the credential that is supposed to be reserved for the link itself. Because that hash can be exchanged for a link-share JWT carrying the share's own permission level, the disclosure becomes a privilege-escalation primitive: if the leaked share was created with write or admin rights, the attacker inherits them and can modify tasks, projects, or administrative settings. The issue is fixed in 2.6.0 per the vendor advisory, and no CISA KEV listing, EPSS score, or public exploit code was present in the supplied intelligence at time of analysis.
Authenticated users of self-hosted Vikunja instances before 2.6.0 can crash the server by uploading a highly compressed archive through the data-import feature, which is expanded without any size or expansion-ratio limit and consumes tens of gigabytes of memory and disk. The issue is a classic decompression-bomb denial of service (CWE-400) rated 7.1 under CVSS 4.0 (AV:N/AC:L/PR:L/UI:N, availability-only impact); any account able to reach the import endpoint is sufficient, no administrative rights are needed. A vendor fix is available in 2.6.0, and no public exploit code or CISA KEV listing was identified in the supplied intelligence.
Vikunja instances before 2.6.0 expose CalDAV BasicAuth endpoints (/dav, /.well-known, and /feeds) that are not covered by the application's anti-brute-force controls, letting a remote unauthenticated attacker send an unlimited number of credential-guessing requests. Successful guessing against password-only accounts yields full read access to the victim's tasks, projects, and feeds data. The vendor has released 2.6.0 as the fix; no public exploit code or active exploitation has been confirmed in the supplied intelligence.
Vikunja versions before 2.6.0 ship authentication endpoints under /api/v2 (login, register, password-reset, and OAuth token issuance) with no rate limiting, so remote unauthenticated attackers can hammer them with unbounded requests to guess credentials, enumerate accounts, and flood mailboxes with password-reset messages. The exposure is a confidentiality problem — the supplied CVSS 4.0 vector rates high impact to data confidentiality but none to integrity or availability — and a vendor patch exists in 2.6.0. There is no public exploit identified at time of analysis and the flaw is not listed in CISA KEV, so this is best treated as a hardening gap that becomes serious the moment an instance is reachable from untrusted networks.
Vikunja versions before 2.6.0 omit pixel-count decode limits on avatar and project-background image upload endpoints, so an authenticated user can upload tiny files whose decoded dimensions are enormous and drive unbounded CPU and memory consumption during image processing. Repeated or concurrent uploads can exhaust server resources and deny service to all users of the instance. The flaw is rated CVSS 7.1 with high availability impact only, no public exploit code has been identified at time of analysis, and a vendor fix is available in 2.6.0.
An authenticated user of Vikunja before 2.6.0 can exhaust the memory of migration worker processes by launching a Planka import job that points at a server they control, which advertises a large number of individually size-compliant attachments. Because the migrator enforces per-file size limits but no aggregate memory budget, the worker is consumed and the instance becomes unavailable to every user on it. The flaw is rated 7.1 (CVSS 4.0, availability-only impact), requires low privileges but no user interaction, and no public exploit code or CISA KEV entry is associated with it at time of analysis; the vendor has released a fix in 2.6.0.
Vikunja releases before 2.6.0 can be knocked offline by any authenticated user who uploads a deliberately oversized multipart CSV file to the POST /api/v2/migration/csv/migrate endpoint, because the importer parses rows without bounding cardinality. Each tiny record consumes heap, so a file containing millions of minimal rows drives the process to out-of-memory conditions and terminates the API service, causing a full denial of service for all tenants on that instance. The flaw is rated 7.1 (CVSS 4.0) with high availability impact and low privileges required; exploitability is high and automatable, though no public exploit code and no CISA KEV listing were provided at time of analysis. Notes in the source metadata separately cite a vendor-available patch.
Memory exhaustion in the Vikunja task-filter endpoint lets any authenticated user crash the API service by submitting a filter query containing thousands of nested parentheses, which the recursive expression parser consumes without a depth limit. All deployments before version 2.6.0 are affected (EUVD lists 2.5.0 through 2.5.x), and a single low-privileged account is enough to repeatedly take the backend offline. A vendor advisory and a VulnCheck advisory are published, a patched release exists in 2.6.0, and no public exploit code or CISA KEV entry was identified at time of analysis, though the attack is trivial to reproduce by hand with plain HTTP requests.
Principal-type confusion in Vikunja through 2.4.0 allows an attacker holding a valid link-share JWT to impersonate arbitrary user accounts by exploiting numeric ID collisions between LinkSharing principals and user records. Three permission-check code paths lack type guards, causing the application to treat a LinkSharing principal whose id equals N as the user with users.id == N. With a crafted link-share token, an attacker can remove victims from teams, enumerate and delete bot user accounts, or read team membership rosters. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Cross-tenant information disclosure in the self-hosted task manager Vikunja (0.24.0 through 2.3.0) lets a holder of any project share link read kanban bucket records - bucket titles and the full created_by user object (username, name, id) - belonging to other tenants' project views, because the task-collection endpoint loads the view from the attacker-controlled URL path without re-authorizing it. The same missing pre-authorization check yields a project/view-ID existence oracle (404 vs non-404) usable by link shares and ordinary authenticated users. No public exploit identified at time of analysis; fixed in 2.4.0.
Principal type confusion in Vikunja (versions 0.22.0-2.3.0) allows an authenticated low-privilege attacker to fully control any target user's API token management by exploiting a numeric ID collision between the independent link-share and user ID sequences. The `/api/v1/tokens` endpoints resolve the caller identity exclusively via the generic `web.Auth.GetID()` interface without validating whether the authenticated principal is a user or a link-share, meaning a link-share JWT whose integer ID equals a victim's user ID is accepted as that user's credential. No CISA KEV listing and no public exploit code have been identified at time of analysis, but successful exploitation yields the ability to mint new API tokens under a victim's identity with attacker-chosen permission scopes, constituting a functional account takeover at the API level.
Authentication bypass in Vikunja task management platform allows unauthenticated attackers to circumvent two-factor authentication when OIDC email-based user matching is enabled. The OIDC callback handler issues complete JWT tokens without validating TOTP enrollment status, enabling full account access to users with configured TOTP protection when matched through OIDC email fallback. Affects versions prior to 2.3.0. No public exploit identified at time of analysis.
Vikunja, an open-source self-hosted task management platform, contains an authorization bypass vulnerability that allows attackers with read-only link share access to escalate privileges to full admin access. The ReadAllWeb handler fails to enforce proper access controls when listing link shares, exposing secret hashes for higher-privilege shares. Versions prior to 2.2.2 are affected, and a patch is available in version 2.2.2.
Vikunja, an open-source self-hosted task management platform, contains an insecure direct object reference (IDOR) vulnerability that allows any authenticated user to access or delete attachments belonging to other users' tasks. The vulnerability affects all versions prior to 2.2.1, enabling attackers to enumerate and download attachments by combining their own valid task ID with sequential attachment IDs. With a CVSS score of 8.1 (High severity), this represents a significant confidentiality and integrity risk, though no evidence of active exploitation (KEV) or public proof-of-concept has been reported.
Vikunja versions 0.18.0 through 2.2.0 contain an authentication bypass vulnerability where disabled or locked user accounts can continue accessing the system through alternative authentication mechanisms. The vulnerability affects the go-vikunja/vikunja product across all matching versions, allowing attackers with knowledge of valid but disabled account credentials to maintain API access, CalDAV synchronization, and OpenID Connect sessions despite administrative account lockdown. While no CVSS score or EPSS data is available from official sources, the vulnerability represents a critical authorization control failure (CWE-285) with high real-world impact in multi-tenant or regulated environments where account disabling is a primary access revocation mechanism.
Broken object-level authorization in Vikunja before 2.6.0 lets any authenticated user write task-position records into project views belonging to other tenants by supplying a project_view_id that is never checked against the target task's project. Because only integrity of view ordering is affected (no read, no availability impact), the practical damage is cross-tenant data corruption and ordering manipulation rather than data theft. A vendor patch (2.6.0) and a GitHub security advisory are available; the issue is not listed in CISA KEV and no public exploit code was identified at time of analysis.
An API token scope bypass in Vikunja before 2.6.0 allows a holder of a deliberately limited-scope API token to read task data outside that token's permissions — specifically comments, reactions, and time entries — by adding the 'expand' query string parameter to task read requests, because the authorization layer never inspects query parameters. Exploitation requires an already-valid low-privilege token (CVSS 4.0 PR:L) and only results in limited confidentiality loss, giving a modest base score of 5.3; there is no public exploit and no evidence of active exploitation at time of analysis. The vendor has released a fix in Vikunja 2.6.0.
Vikunja releases before 2.6.0 return the raw TOTP shared secret from the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without demanding re-authentication, so anyone holding a valid access token can clone the victim's second factor. Because the exposed seed lets an attacker generate valid codes indefinitely, a hijacked session token can be converted into durable account takeover that survives password changes but not TOTP secret rotation. The vendor has shipped a fix in 2.6.0; no public exploit code or CISA KEV entry was identified at time of analysis.
Missing authorization checks in Vikunja's v2 API allow anyone holding a read-only project link-share token to enumerate users through the project users endpoint and to confirm arbitrary usernames exist via the global search endpoint. All Vikunja deployments before 2.6.0 are affected; the flaw is a limited-confidentiality information disclosure (CVSS 4.3, PR:L because a share token is required) and is fixed in 2.6.0. No public exploit code or CISA KEV entry was present at time of analysis.
Vikunja versions before 2.6.0 omit team-level access validation when a team is attached to a project, letting any authenticated user enumerate teams they do not belong to through the project teams endpoint. An attacker with a low-privileged account can supply arbitrary team IDs and receive complete rosters - member names and administrative flags - for unauthorized teams. Impact is confidential-only (CVSS 4.3, CWE-200) and no public exploit code or KEV listing was provided with the source data.
Vikunja prior to version 2.3.0 fails to validate link share permissions against server state during JWT authentication, allowing attackers with revoked or downgraded JWT tokens to maintain the original access level for up to 72 hours. This affects self-hosted task management deployments where link shares are used for collaboration, enabling unauthorized information disclosure and modification of shared projects even after a project owner explicitly revokes or restricts access.
Vikunja prior to version 2.2.1 contains an authorization bypass vulnerability in the DELETE /api/v1/projects/:project/shares/:share endpoint that fails to verify link share ownership. An attacker with administrative access to any project can delete link shares from arbitrary other projects by combining their own project ID with a target share ID, effectively allowing cross-project share manipulation. This is a privilege escalation and denial-of-service vector affecting self-hosted Vikunja deployments where multiple projects exist.
Vikunja versions prior to 2.2.1 contain a Server-Side Request Forgery (SSRF) vulnerability in the avatar image download functionality that fails to implement proper protections when fetching user profile pictures from OpenID Connect provider URLs. An authenticated attacker can exploit this by controlling their OIDC profile picture URL to force the Vikunja server to make arbitrary HTTP GET requests to internal networks or cloud metadata endpoints, potentially disclosing sensitive information. The vulnerability has a CVSS score of 6.4 (medium severity) and is patched in version 2.2.1.
Vikunja prior to version 2.2.1 exposes webhook BasicAuth credentials in plaintext through the GET /api/v1/projects/:project/webhooks API endpoint to any user with read access to a project. While HMAC secrets are properly masked, the BasicAuth username and password fields added in a later migration lack equivalent protection, allowing read-only collaborators to steal credentials intended for authenticating webhook requests to external systems. This is a confirmed information disclosure vulnerability with a CVSS 6.5 score reflecting moderate real-world risk due to the requirement for authenticated project access.
Vikunja prior to version 2.2.1 suffers from an information disclosure vulnerability where the API returns full task object details in the `related_tasks` field without validating the requesting user's read permissions on the related tasks' projects. An authenticated attacker can exploit cross-project task relationships to enumerate sensitive task metadata (titles, descriptions, due dates, priorities, completion percentages, project IDs) from projects they have no access to, achieving a high-confidence information disclosure with CVSS 6.5 and no active exploitation reported in known exploit databases.
Vikunja prior to version 2.2.1 contains a Server-Side Request Forgery (SSRF) vulnerability in its migration helper functions that lack HTTP request validation. An authenticated attacker can exploit this by triggering a Todoist or Trello migration, which causes the Vikunja server to fetch arbitrary URLs specified in attachment metadata from third-party APIs, potentially exposing internal network resources and returning their contents as task attachments. The vulnerability requires low privilege (authenticated user) and carries a CVSS score of 6.4 with moderate confidentiality and availability impact across network boundaries.
Vikunja Desktop (Electron wrapper) versions 0.21.0 through 2.1.x contain a critical remote code execution vulnerability caused by enabled Node.js integration combined with missing navigation controls. An attacker who is a legitimate user on a shared Vikunja instance can inject a malicious hyperlink into user-generated content (task descriptions, comments, project descriptions) that, when clicked by a victim using Vikunja Desktop, causes arbitrary code execution with the victim's OS user privileges. A proof-of-concept demonstrating command execution via a simple HTML link has been documented, and the vulnerability affects all Desktop users on affected versions.
The Vikunja Desktop Electron application fails to validate or allowlist URI schemes before passing URLs from window.open() calls to shell.openExternal(), allowing attackers to invoke arbitrary local applications, open files, or trigger custom protocol handlers. Vikunja versions 0.21.0 through 2.1.x are affected, with the vulnerability patched in version 2.2.0. An attacker who can inject links with target="_blank" into user-generated content can exploit this to execute malicious actions on the victim's operating system without user awareness or explicit consent.
The Vikunja Desktop Electron wrapper enables Node.js integration in the renderer process without proper context isolation or sandboxing, allowing any cross-site scripting vulnerability in the web frontend to escalate directly to remote code execution on the victim's machine. Vikunja versions 0.21.0 through 2.1.x are affected, as confirmed by CPE cpe:2.3:a:go-vikunja:vikunja. An attacker exploiting an XSS flaw gains full access to Node.js APIs and the underlying operating system, making this a critical privilege escalation from web-based XSS to system-level RCE.
A permission-check bypass vulnerability exists in Vikunja versions 0.20.2 through 2.1.x where the DELETE /api/v1/projects/:project/background endpoint incorrectly validates CanRead permissions instead of CanUpdate permissions, allowing read-only project members to permanently delete a project's background image. This affects the go-vikunja:vikunja product family, and the vulnerability has been patched in version 2.2.0 as documented in the GitHub security advisory GHSA-564f-wx8x-878h.
Vikunja prior to 2.6.0 leaks the secret hash that backs a project's link shares through its single-share read endpoint, so any authenticated user holding only read-only membership in a project can read the credential that is supposed to be reserved for the link itself. Because that hash can be exchanged for a link-share JWT carrying the share's own permission level, the disclosure becomes a privilege-escalation primitive: if the leaked share was created with write or admin rights, the attacker inherits them and can modify tasks, projects, or administrative settings. The issue is fixed in 2.6.0 per the vendor advisory, and no CISA KEV listing, EPSS score, or public exploit code was present in the supplied intelligence at time of analysis.
Authenticated users of self-hosted Vikunja instances before 2.6.0 can crash the server by uploading a highly compressed archive through the data-import feature, which is expanded without any size or expansion-ratio limit and consumes tens of gigabytes of memory and disk. The issue is a classic decompression-bomb denial of service (CWE-400) rated 7.1 under CVSS 4.0 (AV:N/AC:L/PR:L/UI:N, availability-only impact); any account able to reach the import endpoint is sufficient, no administrative rights are needed. A vendor fix is available in 2.6.0, and no public exploit code or CISA KEV listing was identified in the supplied intelligence.
Vikunja instances before 2.6.0 expose CalDAV BasicAuth endpoints (/dav, /.well-known, and /feeds) that are not covered by the application's anti-brute-force controls, letting a remote unauthenticated attacker send an unlimited number of credential-guessing requests. Successful guessing against password-only accounts yields full read access to the victim's tasks, projects, and feeds data. The vendor has released 2.6.0 as the fix; no public exploit code or active exploitation has been confirmed in the supplied intelligence.
Vikunja versions before 2.6.0 ship authentication endpoints under /api/v2 (login, register, password-reset, and OAuth token issuance) with no rate limiting, so remote unauthenticated attackers can hammer them with unbounded requests to guess credentials, enumerate accounts, and flood mailboxes with password-reset messages. The exposure is a confidentiality problem — the supplied CVSS 4.0 vector rates high impact to data confidentiality but none to integrity or availability — and a vendor patch exists in 2.6.0. There is no public exploit identified at time of analysis and the flaw is not listed in CISA KEV, so this is best treated as a hardening gap that becomes serious the moment an instance is reachable from untrusted networks.
Vikunja versions before 2.6.0 omit pixel-count decode limits on avatar and project-background image upload endpoints, so an authenticated user can upload tiny files whose decoded dimensions are enormous and drive unbounded CPU and memory consumption during image processing. Repeated or concurrent uploads can exhaust server resources and deny service to all users of the instance. The flaw is rated CVSS 7.1 with high availability impact only, no public exploit code has been identified at time of analysis, and a vendor fix is available in 2.6.0.
An authenticated user of Vikunja before 2.6.0 can exhaust the memory of migration worker processes by launching a Planka import job that points at a server they control, which advertises a large number of individually size-compliant attachments. Because the migrator enforces per-file size limits but no aggregate memory budget, the worker is consumed and the instance becomes unavailable to every user on it. The flaw is rated 7.1 (CVSS 4.0, availability-only impact), requires low privileges but no user interaction, and no public exploit code or CISA KEV entry is associated with it at time of analysis; the vendor has released a fix in 2.6.0.
Vikunja releases before 2.6.0 can be knocked offline by any authenticated user who uploads a deliberately oversized multipart CSV file to the POST /api/v2/migration/csv/migrate endpoint, because the importer parses rows without bounding cardinality. Each tiny record consumes heap, so a file containing millions of minimal rows drives the process to out-of-memory conditions and terminates the API service, causing a full denial of service for all tenants on that instance. The flaw is rated 7.1 (CVSS 4.0) with high availability impact and low privileges required; exploitability is high and automatable, though no public exploit code and no CISA KEV listing were provided at time of analysis. Notes in the source metadata separately cite a vendor-available patch.
Memory exhaustion in the Vikunja task-filter endpoint lets any authenticated user crash the API service by submitting a filter query containing thousands of nested parentheses, which the recursive expression parser consumes without a depth limit. All deployments before version 2.6.0 are affected (EUVD lists 2.5.0 through 2.5.x), and a single low-privileged account is enough to repeatedly take the backend offline. A vendor advisory and a VulnCheck advisory are published, a patched release exists in 2.6.0, and no public exploit code or CISA KEV entry was identified at time of analysis, though the attack is trivial to reproduce by hand with plain HTTP requests.
Principal-type confusion in Vikunja through 2.4.0 allows an attacker holding a valid link-share JWT to impersonate arbitrary user accounts by exploiting numeric ID collisions between LinkSharing principals and user records. Three permission-check code paths lack type guards, causing the application to treat a LinkSharing principal whose id equals N as the user with users.id == N. With a crafted link-share token, an attacker can remove victims from teams, enumerate and delete bot user accounts, or read team membership rosters. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Cross-tenant information disclosure in the self-hosted task manager Vikunja (0.24.0 through 2.3.0) lets a holder of any project share link read kanban bucket records - bucket titles and the full created_by user object (username, name, id) - belonging to other tenants' project views, because the task-collection endpoint loads the view from the attacker-controlled URL path without re-authorizing it. The same missing pre-authorization check yields a project/view-ID existence oracle (404 vs non-404) usable by link shares and ordinary authenticated users. No public exploit identified at time of analysis; fixed in 2.4.0.
Principal type confusion in Vikunja (versions 0.22.0-2.3.0) allows an authenticated low-privilege attacker to fully control any target user's API token management by exploiting a numeric ID collision between the independent link-share and user ID sequences. The `/api/v1/tokens` endpoints resolve the caller identity exclusively via the generic `web.Auth.GetID()` interface without validating whether the authenticated principal is a user or a link-share, meaning a link-share JWT whose integer ID equals a victim's user ID is accepted as that user's credential. No CISA KEV listing and no public exploit code have been identified at time of analysis, but successful exploitation yields the ability to mint new API tokens under a victim's identity with attacker-chosen permission scopes, constituting a functional account takeover at the API level.
Authentication bypass in Vikunja task management platform allows unauthenticated attackers to circumvent two-factor authentication when OIDC email-based user matching is enabled. The OIDC callback handler issues complete JWT tokens without validating TOTP enrollment status, enabling full account access to users with configured TOTP protection when matched through OIDC email fallback. Affects versions prior to 2.3.0. No public exploit identified at time of analysis.
Vikunja, an open-source self-hosted task management platform, contains an authorization bypass vulnerability that allows attackers with read-only link share access to escalate privileges to full admin access. The ReadAllWeb handler fails to enforce proper access controls when listing link shares, exposing secret hashes for higher-privilege shares. Versions prior to 2.2.2 are affected, and a patch is available in version 2.2.2.
Vikunja, an open-source self-hosted task management platform, contains an insecure direct object reference (IDOR) vulnerability that allows any authenticated user to access or delete attachments belonging to other users' tasks. The vulnerability affects all versions prior to 2.2.1, enabling attackers to enumerate and download attachments by combining their own valid task ID with sequential attachment IDs. With a CVSS score of 8.1 (High severity), this represents a significant confidentiality and integrity risk, though no evidence of active exploitation (KEV) or public proof-of-concept has been reported.
Vikunja versions 0.18.0 through 2.2.0 contain an authentication bypass vulnerability where disabled or locked user accounts can continue accessing the system through alternative authentication mechanisms. The vulnerability affects the go-vikunja/vikunja product across all matching versions, allowing attackers with knowledge of valid but disabled account credentials to maintain API access, CalDAV synchronization, and OpenID Connect sessions despite administrative account lockdown. While no CVSS score or EPSS data is available from official sources, the vulnerability represents a critical authorization control failure (CWE-285) with high real-world impact in multi-tenant or regulated environments where account disabling is a primary access revocation mechanism.
Broken object-level authorization in Vikunja before 2.6.0 lets any authenticated user write task-position records into project views belonging to other tenants by supplying a project_view_id that is never checked against the target task's project. Because only integrity of view ordering is affected (no read, no availability impact), the practical damage is cross-tenant data corruption and ordering manipulation rather than data theft. A vendor patch (2.6.0) and a GitHub security advisory are available; the issue is not listed in CISA KEV and no public exploit code was identified at time of analysis.
An API token scope bypass in Vikunja before 2.6.0 allows a holder of a deliberately limited-scope API token to read task data outside that token's permissions — specifically comments, reactions, and time entries — by adding the 'expand' query string parameter to task read requests, because the authorization layer never inspects query parameters. Exploitation requires an already-valid low-privilege token (CVSS 4.0 PR:L) and only results in limited confidentiality loss, giving a modest base score of 5.3; there is no public exploit and no evidence of active exploitation at time of analysis. The vendor has released a fix in Vikunja 2.6.0.
Vikunja releases before 2.6.0 return the raw TOTP shared secret from the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without demanding re-authentication, so anyone holding a valid access token can clone the victim's second factor. Because the exposed seed lets an attacker generate valid codes indefinitely, a hijacked session token can be converted into durable account takeover that survives password changes but not TOTP secret rotation. The vendor has shipped a fix in 2.6.0; no public exploit code or CISA KEV entry was identified at time of analysis.
Missing authorization checks in Vikunja's v2 API allow anyone holding a read-only project link-share token to enumerate users through the project users endpoint and to confirm arbitrary usernames exist via the global search endpoint. All Vikunja deployments before 2.6.0 are affected; the flaw is a limited-confidentiality information disclosure (CVSS 4.3, PR:L because a share token is required) and is fixed in 2.6.0. No public exploit code or CISA KEV entry was present at time of analysis.
Vikunja versions before 2.6.0 omit team-level access validation when a team is attached to a project, letting any authenticated user enumerate teams they do not belong to through the project teams endpoint. An attacker with a low-privileged account can supply arbitrary team IDs and receive complete rosters - member names and administrative flags - for unauthorized teams. Impact is confidential-only (CVSS 4.3, CWE-200) and no public exploit code or KEV listing was provided with the source data.
Vikunja prior to version 2.3.0 fails to validate link share permissions against server state during JWT authentication, allowing attackers with revoked or downgraded JWT tokens to maintain the original access level for up to 72 hours. This affects self-hosted task management deployments where link shares are used for collaboration, enabling unauthorized information disclosure and modification of shared projects even after a project owner explicitly revokes or restricts access.
Vikunja prior to version 2.2.1 contains an authorization bypass vulnerability in the DELETE /api/v1/projects/:project/shares/:share endpoint that fails to verify link share ownership. An attacker with administrative access to any project can delete link shares from arbitrary other projects by combining their own project ID with a target share ID, effectively allowing cross-project share manipulation. This is a privilege escalation and denial-of-service vector affecting self-hosted Vikunja deployments where multiple projects exist.
Vikunja versions prior to 2.2.1 contain a Server-Side Request Forgery (SSRF) vulnerability in the avatar image download functionality that fails to implement proper protections when fetching user profile pictures from OpenID Connect provider URLs. An authenticated attacker can exploit this by controlling their OIDC profile picture URL to force the Vikunja server to make arbitrary HTTP GET requests to internal networks or cloud metadata endpoints, potentially disclosing sensitive information. The vulnerability has a CVSS score of 6.4 (medium severity) and is patched in version 2.2.1.
Vikunja prior to version 2.2.1 exposes webhook BasicAuth credentials in plaintext through the GET /api/v1/projects/:project/webhooks API endpoint to any user with read access to a project. While HMAC secrets are properly masked, the BasicAuth username and password fields added in a later migration lack equivalent protection, allowing read-only collaborators to steal credentials intended for authenticating webhook requests to external systems. This is a confirmed information disclosure vulnerability with a CVSS 6.5 score reflecting moderate real-world risk due to the requirement for authenticated project access.
Vikunja prior to version 2.2.1 suffers from an information disclosure vulnerability where the API returns full task object details in the `related_tasks` field without validating the requesting user's read permissions on the related tasks' projects. An authenticated attacker can exploit cross-project task relationships to enumerate sensitive task metadata (titles, descriptions, due dates, priorities, completion percentages, project IDs) from projects they have no access to, achieving a high-confidence information disclosure with CVSS 6.5 and no active exploitation reported in known exploit databases.
Vikunja prior to version 2.2.1 contains a Server-Side Request Forgery (SSRF) vulnerability in its migration helper functions that lack HTTP request validation. An authenticated attacker can exploit this by triggering a Todoist or Trello migration, which causes the Vikunja server to fetch arbitrary URLs specified in attachment metadata from third-party APIs, potentially exposing internal network resources and returning their contents as task attachments. The vulnerability requires low privilege (authenticated user) and carries a CVSS score of 6.4 with moderate confidentiality and availability impact across network boundaries.
Vikunja Desktop (Electron wrapper) versions 0.21.0 through 2.1.x contain a critical remote code execution vulnerability caused by enabled Node.js integration combined with missing navigation controls. An attacker who is a legitimate user on a shared Vikunja instance can inject a malicious hyperlink into user-generated content (task descriptions, comments, project descriptions) that, when clicked by a victim using Vikunja Desktop, causes arbitrary code execution with the victim's OS user privileges. A proof-of-concept demonstrating command execution via a simple HTML link has been documented, and the vulnerability affects all Desktop users on affected versions.
The Vikunja Desktop Electron application fails to validate or allowlist URI schemes before passing URLs from window.open() calls to shell.openExternal(), allowing attackers to invoke arbitrary local applications, open files, or trigger custom protocol handlers. Vikunja versions 0.21.0 through 2.1.x are affected, with the vulnerability patched in version 2.2.0. An attacker who can inject links with target="_blank" into user-generated content can exploit this to execute malicious actions on the victim's operating system without user awareness or explicit consent.
The Vikunja Desktop Electron wrapper enables Node.js integration in the renderer process without proper context isolation or sandboxing, allowing any cross-site scripting vulnerability in the web frontend to escalate directly to remote code execution on the victim's machine. Vikunja versions 0.21.0 through 2.1.x are affected, as confirmed by CPE cpe:2.3:a:go-vikunja:vikunja. An attacker exploiting an XSS flaw gains full access to Node.js APIs and the underlying operating system, making this a critical privilege escalation from web-based XSS to system-level RCE.
A permission-check bypass vulnerability exists in Vikunja versions 0.20.2 through 2.1.x where the DELETE /api/v1/projects/:project/background endpoint incorrectly validates CanRead permissions instead of CanUpdate permissions, allowing read-only project members to permanently delete a project's background image. This affects the go-vikunja:vikunja product family, and the vulnerability has been patched in version 2.2.0 as documented in the GitHub security advisory GHSA-564f-wx8x-878h.