CVE-2026-35599
Denial of Service via Inefficient Loop in Vikunja Task Scheduler
Publication date: 2026-04-10
Last updated on: 2026-04-17
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| vikunja | vikunja | to 2.3.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-407 | An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability described in CVE-2026-35599 is an algorithmic complexity denial-of-service (DoS) issue that affects the availability of the Vikunja task management platform by allowing an attacker to exhaust CPU and database connections. It does not impact confidentiality or integrity of data.
Since the vulnerability does not lead to unauthorized data access, data leakage, or data corruption, it does not directly affect compliance with data protection standards such as GDPR or HIPAA, which primarily focus on confidentiality, integrity, and privacy of personal data.
However, the high availability impact caused by this DoS vulnerability could indirectly affect compliance if the unavailability of the system prevents timely access to or processing of personal data required under these regulations.
Can you explain this vulnerability to me?
CVE-2026-35599 is an algorithmic complexity denial-of-service (DoS) vulnerability in the Vikunja task management platform. The issue occurs in the function addRepeatIntervalToTime, which advances a task's due date by repeatedly adding the repeat interval until the date exceeds the current time. This function uses an O(n) loop.
An attacker can exploit this by creating a repeating task with a very small repeat interval (e.g., 1 second) and a due date set far in the past (e.g., January 1, 1900). When such a task is marked as done, the loop executes billions of iterations, consuming excessive CPU time and holding a database connection for minutes per request.
This results in resource exhaustion, as multiple concurrent malicious requests can exhaust the database connection pool and make the Vikunja instance unresponsive, effectively causing a denial of service.
The vulnerability was fixed in version 2.3.0 by replacing the O(n) loop with an O(1) arithmetic calculation that directly computes the number of intervals to add, preventing excessive looping.
How can this vulnerability impact me? :
This vulnerability can be exploited by any authenticated user to cause a denial of service on the Vikunja platform.
By creating and completing a repeating task with a very small repeat interval and a due date far in the past, an attacker can trigger excessive CPU consumption and hold database connections for extended periods.
This can exhaust the database connection pool and hang API workers, rendering the Vikunja instance unresponsive and unavailable to legitimate users.
No elevated privileges or user interaction beyond task creation and completion are required to exploit this vulnerability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by observing unusually high CPU usage and long processing times when completing repeating tasks with very small repeat intervals and due dates set far in the past. A proof of concept involved creating a repeating task with a 1-second interval and a due date of 1900-01-01, then marking the task as done, which caused the request to time out after about 60 seconds.
To detect exploitation attempts, monitor API request durations and database connection usage for spikes or saturation, especially requests related to task completion.
Suggested commands include using network or application monitoring tools to identify slow or hanging HTTP requests to the Vikunja API endpoints handling task completion.
A practical approach is to attempt to reproduce the issue in a controlled environment by using scripts (e.g., Python requests) to create a task with a very small repeat interval (1 second) and a due date far in the past, then marking it as done to observe if the system experiences high CPU usage or request timeouts.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade Vikunja to version 2.3.0 or later, where this vulnerability is fixed.
The fix replaces the inefficient O(n) loop with a constant-time arithmetic calculation to prevent excessive CPU consumption.
Additionally, the update enforces a maximum cap on the repeat interval (repeat_after) to 10 years, rejecting any tasks with repeat intervals outside this range to prevent integer overflow and resource exhaustion.
If upgrading immediately is not possible, monitor and restrict authenticated users from creating or completing tasks with very small repeat intervals and due dates set far in the past to reduce the risk of exploitation.