CVE-2026-91970 in Vikunja
Summary
by MITRE • 09/15/2026
Vikunja versions before 2.6.0 contain a resource exhaustion vulnerability in the Planka migrator that fails to enforce aggregate memory budgets during migration jobs. Authenticated attackers can submit migration requests pointing to attacker-controlled servers advertising numerous size-compliant attachments, exhausting worker memory and causing denial of service for all users.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Vikunja versions prior to 2.6.0 represents a significant resource exhaustion flaw located within the Planka migrator component. This issue stems from an architectural oversight where the migration process fails to enforce aggregate memory budgets or limits on the data being ingested during transfer operations. In standard software design, when handling external inputs such as file migrations, it is critical to implement strict quotas that account for both individual item sizes and total cumulative resource consumption. The absence of these controls allows an authenticated user to manipulate the migration workflow in a way that bypasses existing safeguards designed to prevent system overload.
From a technical perspective, the flaw exploits the lack of validation on the aggregate size of attachments referenced during a migration job. An attacker with valid authentication credentials can construct a malicious migration request that points to servers under their control. These external servers are configured to advertise numerous files that individually appear compliant with standard attachment size limits but collectively exceed the available memory capacity of the Vikunja worker processes. By submitting such requests, the attacker forces the application to attempt loading these large volumes of data into memory simultaneously or in rapid succession without adequate throttling or budget enforcement mechanisms.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service condition for all users interacting with the Vikunja instance. As worker processes consume excessive amounts of RAM attempting to process the oversized migration payload, they eventually exhaust available system resources. This leads to application instability, crashes, or complete unresponsiveness, effectively halting productivity and disrupting access to task management data for legitimate users. The attack does not require privilege escalation beyond standard authenticated user status, making it accessible to a broad range of potential adversaries who have obtained valid credentials through phishing, credential stuffing, or other means.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, specifically highlighting the failure to limit resources such as memory during input processing. It also maps closely to MITRE ATT&CK technique T1496, Resource Hijacking, where an adversary uses computing resources for their own purposes or causes disruption by exhausting system capacity. The scenario further reflects CWE-787, out-of-bounds write, in the context of buffer management if the memory allocation exceeds allocated bounds, though the primary classification remains resource exhaustion due to unvalidated input size aggregation.
Mitigation strategies must focus on immediate patching and architectural hardening. Organizations running Vikunja versions earlier than 2.6.0 should upgrade to the latest stable release where this issue has been resolved by implementing proper memory budget enforcement in the Planka migrator. In environments where upgrading is not immediately feasible, administrators can implement network-level controls such as rate limiting on migration endpoints or restrict outbound connections from application servers to untrusted external hosts during migration operations. Additionally, enforcing strict input validation that calculates and caps the total size of all attachments within a single migration job before processing begins would prevent this specific exploitation vector in future versions.