CVE-2026-91979: Vikunja Archive Expansion DoS Vulnerability

CVE-2026-91979 Overview

CVE-2026-91979 is a denial-of-service vulnerability in Vikunja, an open-source task management platform, affecting all versions prior to 2.6.0. The application fails to enforce size limits during archive expansion in its data import functionality. Authenticated users can upload highly compressed archive files that expand to tens of gigabytes when decompressed. The expansion exhausts server memory and disk resources, causing the Vikunja instance to crash. This class of flaw is commonly referred to as a decompression bomb and falls under [CWE-400: Uncontrolled Resource Consumption].

Critical Impact
An authenticated attacker can crash a Vikunja server by uploading a small archive that expands to consume all available memory and disk space.

Affected Products

Vikunja versions prior to 2.6.0
Self-hosted Vikunja deployments exposing the data import endpoint
Multi-tenant Vikunja instances where any authenticated user can trigger imports

Discovery Timeline

2026-09-15 - CVE-2026-91979 published to NVD
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-91979

Vulnerability Analysis

Vikunja provides a data import feature that accepts compressed archive files from authenticated users. The import handler decompresses uploaded archives without validating the decompressed size against a maximum threshold. An attacker crafts a small archive containing highly redundant data that compresses to a few kilobytes but expands to tens of gigabytes on disk and in memory. When Vikunja processes the archive, the server's memory allocator and file system are overwhelmed, terminating the process and denying service to all users.

The issue requires only low-privileged authentication over the network and produces high availability impact with no confidentiality or integrity effects. Multi-user hosted Vikunja instances are the most exposed because any account holder can trigger the crash.

Root Cause

The root cause is missing enforcement of a decompression size ceiling in the import pipeline. The code streams archive contents into memory and onto disk without tracking cumulative expanded bytes or comparing against a configured limit. This is a classic uncontrolled resource consumption pattern where trust is placed in attacker-controlled input dimensions.

Attack Vector

Exploitation requires a valid Vikunja account and network access to the import endpoint. The attacker generates a decompression bomb, for example a ZIP or similar archive containing repeating null bytes, then submits it through the standard data import workflow. No user interaction is required beyond the attacker's own upload. See the GitHub Security Advisory GHSA-w7jp-mf2v-8342 and the VulnCheck Advisory on Vikunja DOS for additional technical context.

// No verified proof-of-concept code is published for CVE-2026-91979.
// Refer to the linked advisories for technical details.

Detection Methods for CVE-2026-91979

Indicators of Compromise

Vikunja processes terminating with out-of-memory errors shortly after an authenticated user submits an import request
Sudden disk space exhaustion on the volume backing Vikunja's temporary import directory
Uploaded archive files with a compression ratio orders of magnitude beyond normal user data

Detection Strategies

Instrument the import endpoint to log uploaded file size, decompressed size, and compression ratio for every request
Alert when a single import job exceeds a defined decompressed byte threshold or ratio, for example ratios above 100:1
Correlate application crash events with the preceding authenticated import request to attribute the trigger to a specific account

Monitoring Recommendations

Monitor host-level memory pressure, swap usage, and disk fill rate on servers running Vikunja
Track HTTP requests to the Vikunja import path and record the authenticated user identifier
Retain temporary import artifacts for forensic review when resource thresholds are crossed

How to Mitigate CVE-2026-91979

Immediate Actions Required

Upgrade Vikunja to version 2.6.0 or later, which enforces archive expansion limits during import
Restrict the import feature to trusted administrator accounts where the workflow permits
Apply operating system resource limits, such as cgroup memory caps, to contain the Vikunja process

Patch Information

The maintainers addressed CVE-2026-91979 in Vikunja 2.6.0. Operators of self-hosted instances should update immediately and validate that the upgrade path preserves data. Refer to the GitHub Security Advisory GHSA-w7jp-mf2v-8342 for release notes and fix details.

Workarounds

Disable the data import endpoint at the reverse proxy layer until the upgrade is applied
Cap request body size in the fronting proxy to reject archives above a small threshold, for example a few megabytes
Run Vikunja under a systemd unit with MemoryMax and TasksMax directives to prevent host-wide impact when the process is targeted

bash

# Example nginx configuration to cap upload size in front of Vikunja
client_max_body_size 5m;

# Example systemd hardening for the Vikunja service unit
# /etc/systemd/system/vikunja.service.d/limits.conf
[Service]
MemoryMax=2G
TasksMax=256