Vikunja EUVD-2026-78644

Exploitation requires a valid authenticated Vikunja account or API token (PR:L in the CVSS vector) - anonymous users cannot reach the vulnerable code path - plus network reachability to the REST API, and the attacker must be able to supply a filter query parameter to the task-filter endpoint carrying thousands of nested parentheses. No administrative role, no special feature toggle, and no non-default configuration are needed: the recursive filter parser is part of the default task-listing functionality, so any instance where untrusted or broadly provisioned accounts exist is exposed. What limits exploitation is that the impact is availability-only - no data is read, modified, or stolen - the attacker must already hold credentials (or be able to self-register, if registration is open), the crash terminates the API process rather than the database, and the success of the attack therefore depends on how quickly the deployment restarts or supervises that process. Instances with closed registration, tightly controlled user provisioning, or low user counts face materially lower realistic risk than open, multi-tenant or internet-facing deployments.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VA:H/SC:N/SI:N/SA:N, base 7.1) is internally consistent with the description: remote, low-complexity, no user interaction, and requiring only a low-privileged authenticated account, with availability impact confined to the vulnerable system and no confidentiality or integrity effect. Translated to CVSS 3.1 this corresponds to roughly 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), so the practical risk is availability-only rather than a data-breach scenario. EPSS data was not supplied in this feed, so the exploitation probability cannot be quantified and should not be assumed high or low; likewise, absence from CISA KEV and the lack of any referenced public exploit code mean this is currently a confirmed-but-not-observed-in-the-wild DoS condition, and remediation should be prioritised by exposure rather than by panic. The mitigating factor is the PR:L requirement - an anonymous internet user cannot trigger it, only someone who can already authenticate - while the aggravating factor is that a single scripted loop of nested-parenthesis requests can be repeated indefinitely, so even a mid-sized municipal IT team in leszno running a shared Vikunja instance should treat this as urgent, because one compromised or malicious user account can deny service to every other tenant. Overall this is a genuine but moderate-priority availability issue: real, easy to reproduce, cheap to mitigate by upgrading, but not a candidate for emergency out-of-band response unless the instance is internet-facing with open registration.

An attacker holding any ordinary Vikunja account - obtained legitimately, via open registration, or by compromising a low-value user - sends a single HTTP GET to the task-filter endpoint with a filter parameter consisting of several thousand opening parentheses. The parser recurses once per parenthesis, memory consumption spikes until the Go runtime kills the API process, and the attacker simply repeats the request in a loop to keep the instance unavailable to all users with minimal effort and no specialized tooling.