CVE-2026-85684 in marker
Summary
by MITRE • 09/04/2026
marker through 2.0.0 contains a path traversal vulnerability in the FastAPI /marker/upload handler that fails to sanitize the file.filename parameter. Unauthenticated attackers can supply filenames containing directory traversal sequences to write arbitrary files to any location or delete existing files on the system.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The marker library, specifically through version 2.0.0, contains a critical path traversal vulnerability within its FastAPI-based /marker/upload handler. This security flaw stems from an insufficient sanitization of user-supplied input, particularly the file.filename parameter provided during file upload operations. In modern web applications utilizing frameworks like FastAPI, it is standard practice to sanitize or validate filenames to prevent attackers from manipulating filesystem paths. However, in this implementation, the application directly uses the raw filename value without adequately checking for directory traversal sequences such as dot-dot-slash (../) or their URL-encoded variants. This lack of validation allows an attacker to control the destination path where uploaded files are written on the server's file system.
From a technical perspective, this vulnerability is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The core issue lies in the application logic that processes the upload request. When a user submits a file via the /marker/upload endpoint, the backend code extracts the filename from the HTTP multipart form data and uses it as part of the destination path for saving the uploaded content. Because there are no checks to ensure the resulting path remains within the intended directory structure, an attacker can inject relative or absolute paths into the filename field. For instance, by submitting a file named ../../etc/passwd.txt, the application may interpret this literally and attempt to write the data outside of the designated upload folder, potentially overwriting system files or placing malicious scripts in executable directories.
The operational impact of this vulnerability is severe due to its unauthenticated nature. Attackers do not need valid credentials to exploit this flaw, significantly lowering the barrier for entry. By leveraging path traversal, an attacker can achieve arbitrary file write capabilities on the underlying operating system. This capability can be exploited to overwrite critical configuration files, inject web shells into publicly accessible directories for remote code execution, or delete essential application data leading to denial of service conditions. In cloud environments or containerized deployments, this could potentially lead to further lateral movement if the compromised host has access to other sensitive resources or shared volumes.
This vulnerability aligns with MITRE ATT&CK technique T1508: Exploitation for Service Reflection, where attackers manipulate inputs to affect system behavior, and more broadly falls under Initial Access vectors that involve exploiting software vulnerabilities in web applications. The lack of input validation represents a fundamental failure in secure coding practices, highlighting the importance of strict allow-listing or canonicalization of file paths before filesystem operations are performed.
To mitigate this vulnerability, developers should immediately upgrade to a patched version of the marker library if one is available from the vendor. In cases where an immediate update is not feasible, implementing robust input validation on the server side is essential. This includes rejecting filenames that contain directory traversal sequences or ensuring that any provided path is resolved and verified against a strict allow-listed base directory before writing files. Additionally, employing principle of least privilege for the application process can limit the damage if an exploit occurs by restricting write permissions to only necessary directories. Regular security audits and static code analysis tools configured to detect CWE-22 patterns should be integrated into the development lifecycle to prevent similar issues in future releases.