EUVD-2026-64044
GHSA-j4h9-pm27-4rfw
Severity by source
CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:A reflects OctoPrint's local-network deployment; PR:L captures the required FILE_UPLOAD permission; C:H for arbitrary readable-file exfiltration; I:L for file relocation; A:N consistent with vendor CVSS 4.0 VA:N.
Primary rating from Vendor (https://github.com/OctoPrint/OctoPrint).
CVSS VectorVendor: https://github.com/OctoPrint/OctoPrint
Lifecycle Timeline
5DescriptionCVE.org
Impact
OctoPrint versions up until and including 1.11.7 as well as 2.0.0rc1 and 2.0.0rc2 contain a vulnerability that allows an attacker with the FILE_UPLOAD permission to exfiltrate files from the host that OctoPrint has read access to, by moving them into the upload folder where they then can be downloaded from. This vulnerability was already reported as GHSA-m9jh-jf9h-x3h2/CVE-2025-48067 but the fix provided in OctoPrint 1.11.2 turned out to be incomplete.
The primary risk lies in the potential exfiltration of secrets stored inside OctoPrint's config, or further system files. By removing important runtime files, this could also be used to impact the availability of the host after an attempted server restart. Given that the attacker requires a user account with file upload permissions, the actual impact of this should however hopefully be minimal in most cases.
Patches
The vulnerability has been patched in version 1.11.8 and 2.0.0rc3.
Details
OctoPrint's web application is implemented in Flask, but uploads are first intercepted by a custom upload handler built on Tornado that sits in front of it. The handler streams the upload to a temporary file on disk - so files larger than the available memory can be uploaded - and rewrites the request, adding internal form fields that tell Flask where to find that temporary file.
These fields are reserved and meant to be set only by the upload handler, never by the client. The previous fix from GHSA-m9jh-jf9h-x3h2/CVE-2025-48067 stripped them from the request received from the client when they were sent as multipart form fields, yet they could still reach Flask through other channels: as plain query parameters, or - since the Tornado handler and Flask did not parse requests identically - smuggled in via several "parser differentials" that looked harmless to the handler while Flask still saw the injected fields. Any of these let an attacker make OctoPrint treat an arbitrary file on the host as a freshly uploaded one and move it into the upload folder.
The following endpoints in OctoPrint are affected:
/api/files/{local|sdcard}/api/languages/plugin/backup/restore/plugin/pluginmanager/upload_file
Further upload endpoints in third party plugins might be affected too.
The fix rejects requests carrying any of the reserved fields, aligns the Tornado handler's request parsing with Flask's (Werkzeug) to avoid any differential parsing, and re-validates the request rewritten by Tornado before forwarding it to Flask.
Credits
This vulnerability was discovered and responsibly disclosed to OctoPrint by Koh Jun Sheng and Jacopo Tediosi.
Timeline
2026-06-04: Report received 2026-06-04: Report acknowledged 2026-06-08: Report verified 2026-06-17: Fix ready for 1.11.x 2026-06-22: Fix ported to 2.0.0 2026-06-23: Fix released with 1.11.8 and 2.0.0rc3
AnalysisAI
File exfiltration via upload endpoint parameter injection in OctoPrint 1.11.7 and earlier (plus 2.0.0rc1 and 2.0.0rc2) allows an authenticated low-privilege attacker with FILE_UPLOAD permission to relocate arbitrary host files into OctoPrint's upload directory for subsequent download, exposing secrets stored in OctoPrint's config and potentially disrupting host availability by removing runtime files. This is a confirmed bypass of the incomplete fix for CVE-2025-48067: the prior patch blocked multipart field injection but left query parameter and Tornado/Werkzeug parser-differential smuggling paths unaddressed. No public exploit code has been identified at time of analysis; vendor-released patches are available as OctoPrint 1.11.8 and 2.0.0rc3.
Technical ContextAI
OctoPrint (pkg:pip/octoprint) is a Python web application that layers a custom Tornado upload proxy in front of a Flask/Werkzeug backend. The Tornado handler streams incoming uploads to temporary disk files and rewrites the HTTP request, injecting reserved internal form fields that tell Flask where to find the uploaded data. CWE-73 (External Control of File Name or Path) is the root cause class: these reserved fields were never meant to be client-controlled. The CVE-2025-48067 fix stripped such fields from multipart bodies, but two bypass channels remained - first, the fields could be submitted as URL query parameters entirely outside the multipart body, and second, Tornado and Werkzeug parse certain raw HTTP constructs differently ('parser differentials'), so a request that appeared clean to the Tornado handler still exposed the injected fields to Flask. Affected endpoints include /api/files/{local|sdcard}, /api/languages, /plugin/backup/restore, and /plugin/pluginmanager/upload_file, with potential exposure in third-party plugin upload endpoints as well.
RemediationAI
Upgrade OctoPrint to version 1.11.8 (stable branch) or 2.0.0rc3 (pre-release branch) immediately; both are vendor-released patched versions per advisory GHSA-j4h9-pm27-4rfw at https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-j4h9-pm27-4rfw. The fix rejects any request carrying reserved internal Tornado fields, aligns Tornado's HTTP request parsing with Werkzeug's to eliminate parser-differential smuggling, and re-validates rewritten requests before forwarding to Flask. If immediate upgrade is not feasible, revoke FILE_UPLOAD permission from all non-essential accounts as a compensating control - this removes the prerequisite for exploitation but disables file upload functionality for those accounts. Additionally, restrict network access to OctoPrint's upload endpoints (/api/files/, /api/languages, /plugin/backup/restore, /plugin/pluginmanager/upload_file) at the perimeter or via reverse proxy ACLs, with the trade-off that this disables upload functionality for blocked network segments. Placing OctoPrint behind a VPN so that FILE_UPLOAD accounts are issued only to fully trusted users is the most operationally neutral interim control.
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.
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 weakness CWE-73 – External Control of File Name or Path
View allSame technique File Upload
View allShare
External POC / Exploit Code
Leaving vuln.today