Skip to main content
VulnerabilityPublished Updated

CVE-2026-38361: dash-uploader · Uncontrolled Resource Consumption

Affects dash-uploaderSource CVE Database V5

0

Not known to be exploited · public detection template (Nuclei) · CVSS 7.5 High.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
2.6% chance of exploitation in 30 days – higher than 85% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 8 May 2026

  2. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  3. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  4. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
PyPIdash-uploaderpkg:pypi/dash-uploaderOther threatsAffected
  • =0.1.0
Fixed in–

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Until an official fix is available, users should consider restricting access to the dash-uploader service to trusted users or networks and monitor resource usage closely to detect potential exploitation attempts. Avoid exposing the vulnerable versions publicly.

Description

Multiple unauthenticated denial-of-service (DoS) issues in fohrloop dash-uploader v0.1.0 through v0.7.0a2. The chunked-upload handler (dash_uploader/httprequesthandler.py, dash_uploader/upload.py) trusts unsanitized, attacker-controlled upload parameters (e.g. flowTotalChunks) and does not enforce the documented max_file_size limit, allowing a remote, unauthenticated attacker to cause an out-of-memory (OOM) process crash (unbounded range(1, flowTotalChunks + 1) allocation), truncation of the target file to zero bytes (flowTotalChunks=0, where the all([]) == True quirk runs the file-assembly branch on zero chunks), permanent disk exhaustion (never-cleaned-up temporary directories per flowIdentifier), and a complete bypass of the documented max_file_size limit.

References

Community reviews

Loading reviews…