CVE-2026-35602: Vikunja File Size Bypass Vulnerability

CVE-2026-35602 Overview

CVE-2026-35602 is a file size validation bypass vulnerability in Vikunja, an open-source self-hosted task management platform. Prior to version 2.3.0, the Vikunja file import endpoint uses the attacker-controlled Size field from the JSON metadata inside the import zip instead of the actual decompressed file content length for the file size enforcement check. By setting Size to 0 in the JSON while including large compressed file entries in the zip, an attacker bypasses the configured maximum file size limit.

Critical Impact

Authenticated attackers can bypass file size restrictions to upload arbitrarily large files, potentially leading to storage exhaustion and denial of service conditions on Vikunja instances.

Affected Products

• Vikunja versions prior to 2.3.0

Discovery Timeline

• 2026-04-10 - CVE CVE-2026-35602 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2026-35602

Vulnerability Analysis

This vulnerability stems from an improper resource allocation control weakness (CWE-770: Allocation of Resources Without Limits or Throttling). The file import functionality in Vikunja fails to properly validate file sizes during the import process, creating an opportunity for resource exhaustion attacks.

When processing import zip files, Vikunja reads metadata from embedded JSON that includes a Size field intended to describe the file content length. However, the application trusts this user-supplied value for size enforcement checks rather than calculating the actual decompressed content size. This design flaw allows attackers to craft malicious import archives that declare minimal file sizes while containing significantly larger payloads.

The vulnerability requires authentication to exploit, limiting the attack surface to users with valid Vikunja credentials. However, in multi-tenant environments or instances with open registration, this could enable any registered user to impact service availability.

Root Cause

The root cause is improper input validation where the application trusts attacker-controlled metadata for security-critical size enforcement. Instead of measuring the actual decompressed file content length, the import handler relies on the Size field within the JSON metadata embedded in the import zip archive. This violates the security principle of never trusting user-supplied input for security decisions.

Attack Vector

The attack is network-based and requires low-privilege authenticated access. An attacker would:

1. Create a legitimate Vikunja import zip file structure
2. Modify the JSON metadata to set the Size field to 0 or an artificially small value
3. Include compressed files that decompress to sizes exceeding the configured maximum file limit
4. Upload the crafted import archive through the file import endpoint
5. The server accepts the upload since the declared size passes validation, but the actual decompressed content consumes excessive storage

This attack could be repeated to exhaust disk space, causing denial of service for the Vikunja instance and potentially other applications sharing the same storage.

Detection Methods for CVE-2026-35602

Indicators of Compromise

• Unusual file import activity from specific user accounts
• Rapid storage consumption without corresponding increase in legitimate task data
• Import operations where declared file sizes in metadata are significantly smaller than actual stored content
• Error logs showing disk space exhaustion or storage allocation failures

Detection Strategies

• Monitor import endpoint activity for high-frequency requests from individual users
• Implement file system monitoring to detect anomalous storage growth patterns
• Audit import operations by comparing declared metadata sizes against actual file sizes written to storage
• Configure alerts for storage utilization thresholds on Vikunja data directories

Monitoring Recommendations

• Enable verbose logging for file import operations to capture metadata and actual file sizes
• Set up disk space monitoring with alerting for the Vikunja storage directory
• Review authentication logs for accounts performing repeated import operations
• Implement rate limiting on import endpoints to slow potential exploitation attempts

How to Mitigate CVE-2026-35602

Immediate Actions Required

• Upgrade Vikunja to version 2.3.0 or later immediately
• Review import logs for suspicious activity prior to patching
• Consider temporarily disabling the file import feature if upgrading cannot be performed immediately
• Audit storage consumption and remove any suspicious oversized files

Patch Information

The vulnerability is fixed in Vikunja version 2.3.0. The fix was implemented through Pull Request #2575, which ensures the application calculates actual decompressed file sizes rather than trusting the metadata values. Organizations should upgrade to version 2.3.0 or later by downloading from the official release.

For detailed technical information about this vulnerability, refer to the GitHub Security Advisory GHSA-qh78-rvg3-cv54.

Workarounds

• Restrict access to the import functionality by limiting user permissions if your deployment supports this
• Implement external file size validation at the web server or reverse proxy level before requests reach Vikunja
• Configure disk quotas on the underlying storage to limit the impact of storage exhaustion attacks
• Deploy monitoring and alerting to detect exploitation attempts before significant damage occurs
• Consider placing Vikunja behind an application firewall that can inspect and validate import payloads

# Example: Configure disk quota monitoring for Vikunja data directory
# Monitor storage usage and alert at 80% threshold
du -sh /path/to/vikunja/files/
# Set up cron job to check storage usage
echo "0 */4 * * * root /usr/local/bin/check_vikunja_storage.sh" >> /etc/crontab