CVE-2026-91979 in Vikunja
Summary
by MITRE • 09/15/2026
Vikunja before 2.6.0 fails to limit archive expansion during data import, allowing authenticated users to cause denial of service. Attackers can upload highly compressed files that expand to tens of gigabytes in memory and disk, exhausting server resources and crashing the instance.
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 critical failure in input validation during the data import process, specifically concerning archive file handling. This flaw allows authenticated users to exploit the application's lack of constraints on archive expansion limits, leading to severe resource exhaustion and service disruption. The core technical issue lies in the absence of checks for the uncompressed size or the number of entries within uploaded archive files such as ZIP archives. When a user initiates an import operation by uploading an archive, the server proceeds to extract its contents without verifying whether the resulting data volume exceeds available system resources. This design oversight transforms a standard file upload feature into a vector for denial-of-service attacks, as the application blindly trusts the metadata of the compressed files rather than validating their potential impact on the host environment.
From a technical perspective, this vulnerability is classified under CWE-409, which describes Improper Handling of Highly Compressed Data (Data Amplification). The attack mechanism relies on creating archive files with extremely high compression ratios or containing numerous small dummy files that expand to massive sizes when decompressed. For instance, an attacker can upload a compressed file of only a few megabytes that expands into tens of gigabytes upon extraction. This process consumes significant amounts of both RAM and disk I/O bandwidth as the server attempts to allocate memory for the uncompressed data streams and write them to the filesystem. The lack of rate limiting or size caps means that even a single malicious upload can trigger this cascade, overwhelming the application's ability to manage concurrent connections and file operations effectively.
The operational impact of this vulnerability is substantial, primarily manifesting as a complete denial of service for legitimate users. As server resources such as memory and disk space are exhausted by the excessive expansion process, Vikunja instances may become unresponsive or crash entirely. This disruption halts all task management activities within the platform, affecting productivity for teams relying on the application. Furthermore, repeated exploitation attempts can lead to persistent instability, requiring manual intervention from system administrators to restart services and clear temporary files. The vulnerability also poses indirect risks related to data integrity if the resource exhaustion causes incomplete writes or corruption of existing project data during the import process.
This flaw aligns with MITRE ATT&CK technique T1496, Resource Hijacking, where attackers leverage compromised resources for denial-of-service purposes rather than direct exfiltration or control. It also reflects CWE-770, Allocation of Resources Without Limits or Throttling, highlighting the fundamental architectural gap in resource management protocols. To mitigate this risk, organizations running Vikunja must upgrade to version 2.6.0 or later, where these expansion limits have been implemented and enforced by default. In environments where immediate upgrading is not feasible, administrators should implement network-level controls such as web application firewalls that restrict the maximum size of uploaded files and monitor for unusual spikes in disk I/O activity associated with archive extraction processes. Additionally, configuring server-side timeouts and memory limits can provide a secondary layer of defense against resource exhaustion attacks until the software patch is applied.