CVE-2026-35602: 
NixOS vulnerability analysis and mitigation

CVE-2026-35602 is a file size limit bypass vulnerability in Vikunja's file import endpoint, classified as "File Size Limit Bypass via Vikunja Import." It affects all Vikunja versions up to and including 2.2.2 (Go module code.vikunja.io/api), and was published on April 9–10, 2026. The vulnerability was discovered and reported by aisafe.io and patched in version 2.3.0. It carries a CVSS v3.1 base score of 5.4 (Moderate) per the GitHub Advisory, though Feedly's NVD-sourced data assigns a score of 7.1 (High) (Github Advisory, Vikunja Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the import handler at pkg/modules/migration/create_from_structure.go:406 passes the attacker-controlled File.Size field from the data.json metadata inside the import zip to a.NewAttachment(), rather than deriving the size from the actual decompressed content. The size enforcement check at pkg/files/files.go:118 evaluates realsize > config.GetMaxFileSizeInMBytes()*uint64(datasize.MB) using this attacker-supplied value; setting "size": 0 in the JSON causes the comparison 0 > 20MB to evaluate to false, bypassing the limit entirely. The actual file content is read from the zip entry independently and can be up to 500MB per entry (the readZipEntry hard cap), and highly compressible content (e.g., zero-filled buffers) allows a small zip upload to store gigabytes of data on the server. A complete Python proof-of-concept is publicly available in the security advisory (Vikunja Advisory, Github Advisory).

An authenticated attacker can repeatedly upload small, highly compressed zip files that decompress into files far exceeding the configured maximum file size limit, exhausting server disk storage. This causes denial of service for all users of the Vikunja instance, as a full disk prevents new data from being written. There is no per-user storage quota to contain the impact, and no confidentiality breach is involved — the primary impacts are availability (high) and minor integrity concerns from bypassing enforced upload policies (Vikunja Advisory).

A functional Python proof-of-concept exploit is publicly available in the Vikunja security advisory, demonstrating the full attack against a real server instance (tested on v2.2.2). Exploitation requires only a valid authenticated user account (low privileges) and network access to the /api/v1/migration/vikunja-file/migrate endpoint. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.036–0.047%, indicating a low near-term exploitation probability (Vikunja Advisory, Github Advisory).

1. Authenticate: Obtain a valid Vikunja user account and authenticate via POST /api/v1/login to retrieve a Bearer token.
2. Craft malicious zip: Construct a zip archive containing:
   • A VERSION file with a valid Vikunja version string (e.g., 2.2.2).
   • A data.json file with project/task/attachment metadata where the attachment's file.size field is set to 0.
   • The actual large file (e.g., 25MB of repeated bytes) stored under the filename referenced in data.json.
3. Compress for efficiency: Use ZIP_DEFLATED compression; highly compressible content (e.g., b"A" * (25 * 1024 * 1024)) achieves extreme compression ratios, allowing a ~25KB upload to store ~25MB.
4. Submit the import: Send a PUT request to /api/v1/migration/vikunja-file/migrate with the crafted zip as a multipart file upload and the Bearer token in the Authorization header.
5. Repeat for storage exhaustion: The server responds with HTTP 200 and stores the oversized file despite the configured limit. Repeat the upload to progressively fill the server's disk, eventually causing denial of service for all users (Vikunja Advisory).

• Network: Repeated PUT requests to /api/v1/migration/vikunja-file/migrate from the same authenticated user, especially with small upload sizes but high frequency; HTTP 200 responses with {"message": "Everything was migrated successfully."} for each request.
• File System: Rapid growth of the Vikunja file storage directory (local or S3-backed); presence of many large binary files (e.g., large.bin) in the attachments storage path that exceed the configured max_file_size.
• Logs: Vikunja application logs showing repeated successful migration imports from a single user account in a short time window; disk usage alerts or storage quota warnings from the host OS or monitoring system.
• Database: Unusually large number of file records in the Vikunja files table associated with a single user, with size values of 0 or inconsistent with actual stored content size (Vikunja Advisory).

Upgrade Vikunja to version 2.3.0 or later, which fixes the vulnerability by deriving the authoritative file size from the actual reader content (uint64(len(a.File.FileContent))) rather than the attacker-controlled File.Size metadata field. The fix also adds defense-in-depth at the file creation boundary (pkg/files/files.go) and bounds the per-entry zip read cap to the configured files.maxsize. No configuration-based workaround is available for unpatched versions; restricting access to the import endpoint via network controls or disabling the migration feature can reduce exposure until patching is possible (Vikunja Advisory, Fix PR, v2.3.0 Release).

The vulnerability was discovered and responsibly disclosed by aisafe.io, and the Vikunja maintainer (kolaente) published the advisory and merged the fix on April 9, 2026. The v2.3.0 release notes explicitly recommend updating soon, noting 11 security fixes in the release. No significant broader media coverage or notable external researcher commentary has been identified beyond the GitHub advisory and associated pull request discussion (Vikunja Advisory, v2.3.0 Release).