26
CVEs
1
Critical
16
High
0
KEV
15
PoC
0
Unpatched C/H
96.2%
Patch Rate
0.3%
Avg EPSS
Severity Breakdown
CRITICAL
1
HIGH
16
MEDIUM
9
LOW
0
Monthly CVE Trend
Affected Products (4)
Top Risky CVEs
| CVE | Summary | Severity | CVSS | EPSS | Priority | Signals |
|---|---|---|---|---|---|---|
| CVE-2026-68582 | 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. | CRITICAL | 9.3 | 0.2% | 67 |
PoC
|
| CVE-2026-68581 | 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. | HIGH | 8.6 | 0.3% | 63 |
PoC
|
| CVE-2026-91973 | 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. | HIGH | 8.7 | 0.6% | 44 |
PoC
|
| CVE-2026-91972 | 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. | HIGH | 8.7 | 0.5% | 44 |
PoC
|
| CVE-2026-91985 | 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. | HIGH | 8.7 | 0.4% | 44 |
PoC
|
| 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-76216 | 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. | HIGH | 7.7 | 0.3% | 39 |
|
| 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-91968 | 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. | HIGH | 7.1 | 0.4% | 36 |
PoC
|
| CVE-2026-91970 | 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. | HIGH | 7.1 | 0.4% | 36 |
PoC
|
| CVE-2026-91969 | 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. | HIGH | 7.1 | 0.3% | 36 |
PoC
|
| CVE-2026-91971 | 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. | HIGH | 7.1 | 0.3% | 36 |
PoC
|
| CVE-2026-91979 | 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. | HIGH | 7.1 | 0.3% | 36 |
PoC
|