10
CVEs
0
Critical
6
High
0
KEV
0
PoC
0
Unpatched C/H
90.0%
Patch Rate
0.2%
Avg EPSS
Severity Breakdown
CRITICAL
0
HIGH
6
MEDIUM
4
LOW
0
Monthly CVE Trend
Affected Products (4)
Top Risky CVEs
| CVE | Summary | Severity | CVSS | EPSS | Priority | Signals |
|---|---|---|---|---|---|---|
| CVE-2026-57458 | Privilege escalation in Vikunja 2.3.0 allows a user who holds a narrowly scoped API token (permissions {"oauth":["authorize"]}) to exchange that token for unrestricted session credentials, defeating the API-token permission boundary. The token holder calls POST /api/v1/oauth/authorize to obtain an OAuth authorization code and then POST /api/v1/oauth/token to trade it for a normal bearer JWT and refresh token that are not bound to the original token's scope - runtime validation showed the scoped token could not read GET /api/v1/user, while the minted token could reach both /api/v1/user and /api/v1/projects. The vulnerability requires an already-issued scoped token from the same user (CVSS 3.1 base 8.1, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, CWE-269), no public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV). Version 2.4.0 fixes the issue. | HIGH | 8.1 | 0.3% | 41 |
|
| CVE-2026-62376 | Plaintext storage of password-reset, email-confirmation and account-deletion tokens in Vikunja prior to 2.4.0 allows anyone who already holds read access to the backend database to redeem a pending token and take over the associated account, including administrator accounts, without knowing any password. The vulnerability is a CWE-312 cleartext-storage flaw rated CVSS 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H), where the high attack complexity reflects two preconditions rather than any weakness in the exploit itself: the attacker must independently obtain database read access (leaked or misconfigured backups, exposed storage, or a secondary SQL-level exposure), and the victim account must have an unexpired token within its 24-hour lifetime. The vendor advisory publishes proof-of-concept code illustrating the attack (a SQL query harvesting tokens plus a password-reset redemption request); no KEV listing was provided in the available intelligence, so there is no confirmation of active exploitation, and the CVSS vector's PR:N confirms the token-redemption step itself requires no Vikunja application credentials or user interaction. | HIGH | 8.1 | 0.2% | 41 |
|
| CVE-2026-62367 | Unauthenticated account takeover in Vikunja 1.0.0 through 2.3.0 lets an attacker who can obtain an OpenID Connect token carrying a victim's email address log in as that victim with a full session and no victim interaction. The flaw only manifests when an administrator has enabled the non-default per-provider emailfallback option, under which Vikunja resolves an unknown (issuer, subject) pair to a pre-existing local username/password account using the email claim alone - it never inspects email_verified (or Microsoft's xms_edov) and never asks for the matched account's password. Practical exposure is narrow but real: it additionally requires an IdP that will assert a victim's unverified email (a self-service or multi-tenant issuer) and a victim local account that has no TOTP, which the 2.3.0 enforceTOTPIfRequired gate protects; there is no public exploit identified at time of analysis, and no KEV/EPSS signal has been provided, so this is a high-priority fix for the specific vulnerable configuration rather than an ongoing mass-exploitation event. | HIGH | 7.5 | 0.1% | 38 |
|
| CVE-2026-111922 | Account takeover in Vikunja 2.2.0 through 2.6.0 stems from a default CORS policy that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set, so a page served from any local port can call the token refresh endpoint and read the returned bearer JWT. The attack is conditional rather than mass-exploitable: the attacker must be able to host malicious content on the victim's own machine, and the victim must have an active authenticated session; it is not directly exploitable from an arbitrary external internet origin. No public exploit identified at time of analysis. | HIGH | 7.2 | 0.1% | 36 |
|
| CVE-2026-111917 | Revoked Vikunja sessions retain live WebSocket access: in versions 2.3.0 through 2.6.0 the /api/v2/ws endpoint authenticates the first client message by verifying only the JWT signature and token type, never resolving the token's 'sid' claim against the sessions table, so a stolen access token can still open a new connection or keep an existing one alive after DELETE /api/v2/user/sessions/{id} or after TOTP enrollment wipes all sessions. The impact is confidentiality-only: the attacker continues to receive notification.created pushes carrying comment, task and project content belonging to the victim's account, which the vendor scores 7.1 under CVSS 4.0 (PR:L, VC:H) and our assessment scores 6.5 under CVSS 3.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). Exploitation requires an authenticated attacker who already holds a valid, unexpired user access token - there is no initial-access path in this defect - and no public exploit code or CISA KEV entry was identified at time of analysis. | HIGH | 7.1 | 0.3% | 36 |
|
| CVE-2026-111919 | Vikunja 0.22.0 through 2.6.0 fails to revoke webhook and link-share channels when a collaborator's project access is removed, so a former collaborator who created a webhook while still authorized continues to receive task titles and descriptions - including content created after revocation - as an automatic live feed. The cleanup routine that deletes derived rows (assignees, subscriptions) does not include webhooks or link shares, and it is only wired to the team-member removal path, leaving direct project-user removal, permission downgrade, and team-project removal without any cleanup. Per the assessed vector (AV:N/AC:L/PR:L/UI:N/C:H), the attacker must have been a legitimate authenticated collaborator who previously registered a webhook, gains read-only disclosure only, and no public exploit code has been identified at time of analysis. | HIGH | 7.1 | 0.3% | 36 |
|
| CVE-2026-111918 | An improper authorization flaw in Vikunja's saved-filter creation flow lets any authenticated user who has engineered a zero-accessible-projects account state cause RecalculateTaskPositions to write task_positions rows for every task on the instance, including tasks belonging to other tenants. Triggering it requires a saved filter created with an empty filter string and no search string, which collapses the project scope and drops the WHERE clause entirely, producing a single-request write-amplification primitive that scales with instance size and enables denial of service plus cross-tenant integrity violations. Vikunja versions from 1.0.0-rc0 through 2.6.0 are affected and 2.7.0 contains the fix; the flaw is authenticated-only (PR:L per the assessed vector), yields no read access to other tenants' task contents, and is only materially impactful in multi-tenant deployments - no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV). | MEDIUM | 5.3 | 0.2% | 27 |
|
| CVE-2026-111921 | Write-level project members in Vikunja 0.13.0 through 2.6.0 can delete admin-tier link shares they are not authorized to touch, because the deletion handler builds a LinkSharing object containing only the URL-supplied IDs and the permission check then reads that object's Go zero value (Read) instead of the stored share permission. An authenticated attacker who already holds Write membership on a project can iterate sequential share IDs against DELETE /api/v1/projects/{project}/shares/{share} or the v2 equivalent (present from v2.4.0) to revoke admin links and invalidate existing share sessions, yielding limited integrity and availability impact. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor CVSS 4.0 base score is 5.3. | MEDIUM | 5.3 | 0.2% | 27 |
|
| CVE-2026-111920 | Vikunja 2.6.0 allows an authenticated collaborator who holds a higher permission on a parent project to override an explicitly set read-only share on a nested child project, enabling modification of that child's tasks and content. This broken access control is a permission-resolution regression introduced in 2.6.0 and only affects users who already have access to the project tree; no public exploit was identified at time of analysis. The issue is limited to integrity impact and is a low-to-moderate priority rather than a critical remote threat. | MEDIUM | 5.3 | 0.2% | 27 |
No patch
|
| CVE-2026-115507 | HTML injection in the conversational notification header of Vikunja 2.2.0 through 2.7.0 allows an authenticated project member to break out of the display anchor and plant a clickable phishing link in task-comment and task-mention emails that Vikunja sends to other project members. The attacker only needs control of text that reaches the header - a task title, a project title or their own display name - plus shared project membership and an action that triggers a notification (an @mention or an assignment). Impact is confined to link injection in the rendered email: no script execution is possible, remote images are neutralized by the sanitizer, and the recipient must click the injected link in an HTML-capable mail client, so the practical effect is credential-phishing redirection rather than code execution or data compromise. No CISA KEV entry, no confirmed public exploit code and no EPSS signal are present in the supplied data; the vendor advisory does include a detailed end-to-end lab reproduction using the REST API and a local SMTP sink. | MEDIUM | 5.1 | 0.2% | 26 |
|