EUVD-2026-21429
GHSA-qh78-rvg3-cv54
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Impact | This vulnerability presents a moderate-to-high real-world risk despite the 5.4 CVSS score. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) correctly identifies low attack complexity and a low integrity/availability impact rating, but the impact assessment is conservative. The actual severity stems from cumulative exploitation: an authenticated user repeatedly uploading small compressed files can fill server disk storage with minimal computational effort, triggering denial of service affecting all system users. The vulnerability requires authentication (PR:L), which limits the threat surface to users with valid credentials, but many organizations grant import privileges to low-privilege or external users. The proof-of-concept is fully functional and documented, confirming exploitability. No per-user storage quota exists to bound individual impact, making this a classic resource exhaustion vector. EPSS score is not provided in the input data, but the combination of (1) confirmed exploitability via POC, (2) authenticated-but-accessible attack vector, (3) cumulative DoS capability, and (4) vendor patch availability suggests this warrants immediate patching in production environments, particularly if external users have import access. |
| Exploit ScenarioDerived | An authenticated user with project import permissions crafts a malicious zip file (~25KB) containing a data.json metadata file with Size: 0 for a file attachment, but includes actual file content (large.bin) of 25MB or more within the zip archive. The user uploads this zip to the Vikunja migration endpoint. Because the size validation check trusts the JSON metadata instead of the actual decompressed content, the 25MB file bypasses the 20MB server limit and is stored on disk. The attacker repeats this process dozens or hundreds of times using legitimate import workflows, filling the server's available storage and triggering denial of service for all users. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 10, 2026
Vikunja's file import endpoint bypasses configured maximum file size limits by trusting an attacker-controlled Size field in import metadata rather than validating actual decompressed file content. Authenticated users can upload small compressed zip files (e.g., ~25KB) containing files up to 25MB or larger, exhausting server storage and causing denial of service across all users. The vulnerability affects Vikunja v2.2.2 and earlier versions; a vendor-released patch is available in v2.3.0.
RemediationAI
Vendor-released patch: Vikunja v2.3.0 (https://github.com/go-vikunja/vikunja/releases/tag/v2.3.0) includes the upstream fix via pull request #2575 (https://github.com/go-vikunja/vikunja/pull/2575). The remediation replaces the attacker-controlled File.Size parameter with uint64(len(a.File.FileContent)), ensuring file size enforcement is applied to the actual decompressed content rather than metadata. Upgrade to v2.3.0 or later. If immediate patching is not feasible, consider restricting the import endpoint to trusted administrators only via access control policies, reducing the number of authenticated users who can trigger resource exhaustion. However, no reliable workaround mitigates the logic flaw itself; patching is strongly recommended. See the official advisory at https://github.com/go-vikunja/vikunja/security/advisories/GHSA-qh78-rvg3-cv54 for additional details and patch verification.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability exists in Vikunja's project migration system, which processes zip-archived exports containing a JSON metadata file (data.json) that describes the project structure including attachment metadata. During deserialization at pkg/modules/migration/create_from_structure.go:406, the File.Size field from the attacker-controlled JSON metadata is passed directly to the NewAttachment function. The file size enforcement check at pkg/files/files.go:118 then compares this untrusted Size value against the configured maximum (default 20MB) rather than validating against the actual length of the decompressed file content. The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the application fails to enforce resource limits on the actual content being imported, instead relying on metadata supplied by the attacker. Zip compression ratios on highly compressible data (zero-filled buffers, repetitive patterns) can exceed 1000:1, allowing a single ~25KB zip upload to store gigabytes of uncompressed content within server constraints.
Know when Python gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
Summary
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.
Details
During import, the JSON metadata from data.json inside the zip archive is deserialized into project structures. File content is read independently from the zip entries. When creating attachments, the code at pkg/modules/migration/create_from_structure.go:406 passes the attacker-controlled File.Size from the JSON:
err = a.NewAttachment(s, bytes.NewReader(a.File.FileContent), a.File.Name, a.File.Size, user)The file size enforcement check at pkg/files/files.go:118 then evaluates this attacker-controlled value:
if realsize > config.GetMaxFileSizeInMBytes()*uint64(datasize.MB) && checkFileSizeLimit {With Size set to 0 in the JSON, the comparison 0 > 20MB evaluates to false and the check passes. The actual file content (from the zip entry) can be up to 500MB per entry (the readZipEntry limit). Highly compressible content like zero-filled buffers achieves extreme compression ratios, allowing a small zip upload to store gigabytes of data.
Proof of Concept
Tested on Vikunja v2.2.2 with default max_file_size: 20MB.
import zipfile, io, json, requests
TARGET = "http://localhost:3456"
token = requests.post(f"{TARGET}/api/v1/login",
json={"username": "user1", "password": "User1pass!"}).json()["token"]
h = {"Authorization": f"Bearer {token}"}
# Craft zip with forged Size=0 in JSON but 25MB actual content
large_content = b"A" * (25 * 1024 * 1024)
# 25MB
data = [{"title": "Project", "tasks": [{"title": "Task", "attachments": [{
"file": {"name": "large.bin", "size": 0, "created": "2026-01-01T00:00:00Z"},
"created": "2026-01-01T00:00:00Z"}]}]}]
zip_buf = io.BytesIO()
with zipfile.ZipFile(zip_buf, 'w', zipfile.ZIP_DEFLATED) as zf:
zf.writestr("VERSION", "2.2.2")
zf.writestr("data.json", json.dumps(data))
zf.writestr("large.bin", large_content)
resp = requests.put(f"{TARGET}/api/v1/migration/vikunja-file/migrate",
headers=h,
files={"import": ("export.zip", zip_buf.getvalue(), "application/zip")})Output:
HTTP 200: {"message": "Everything was migrated successfully."}
25MB file stored despite 20MB server limit.Impact
An authenticated user can exhaust server storage by uploading small compressed zip files that decompress into files exceeding the configured maximum file size limit. A single ~25KB upload can store ~25MB due to zip compression ratios. Repeated exploitation can fill the server's disk, causing denial of service for all users. No per-user storage quota exists to contain the impact.
Recommended Fix
Use the actual content length instead of the attacker-controlled Size field:
err = a.NewAttachment(s, bytes.NewReader(a.File.FileContent), a.File.Name, uint64(len(a.File.FileContent)), user)--- *Found and reported by aisafe.io*
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Related Vulnerabilities in Vikunja Multiple Authorization and Injection
View all 11Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Same technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Exploit-DB