CVE-2026-102810 in Marmite
Summary
by MITRE • 09/29/2026
Marmite through 0.4.2 contains a path traversal vulnerability in the development server started by --serve that allows unauthenticated attackers to read arbitrary files. The handle_request function in src/server.rs fails to reject .. segments after percent-decoding and joining the request path to the output folder, enabling attackers to request encoded traversal sequences to access files readable by the marmite process.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in Marmite versions through 0.4.2 represents a critical security flaw within its development server component, specifically triggered when operating with the serve flag enabled. This issue is classified as a path traversal vulnerability, which fundamentally stems from an insufficient validation of user-supplied input during request processing. The core technical failure occurs within the handle_request function located in the src/server.rs source file. When handling incoming HTTP requests, this function constructs the target file path by joining the requested URI with the designated output folder directory. However, it fails to adequately sanitize or reject path traversal sequences, such as double-dot segments (..), after they have undergone percent-decoding and URL normalization processes. This oversight allows an unauthenticated attacker to manipulate the request path to escape the intended web root directory and access arbitrary files on the underlying file system that are readable by the process executing Marmite.
From a technical perspective, this flaw aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The vulnerability exploits the standard behavior where URL-encoded characters like %2e%2e (which decode to ..) are processed before path resolution checks occur. By sending requests containing these encoded traversal sequences, an attacker can bypass directory restrictions and read sensitive files such as configuration files with database credentials, source code containing API keys, or other private data stored within the project structure or even outside of it if permissions allow. The impact is severe because Marmite's development server often runs with elevated privileges relative to a standard web application user context, potentially exposing critical infrastructure details and internal logic that should remain hidden from external access.
This type of vulnerability is frequently associated with ATT&CK technique T1083: File and Directory Discovery, as it enables an attacker to enumerate and retrieve files outside the intended scope without authentication. The operational impact includes potential data exfiltration, information disclosure, and in some scenarios, serving as a stepping stone for further attacks such as remote code execution if sensitive configuration files expose credentials that can be leveraged against other services. Since this vulnerability exists specifically in the development server mode, it is primarily a risk during active development phases where developers might inadvertently deploy or expose these servers to untrusted networks or public internet interfaces without realizing the heightened security risks associated with serving raw assets and debug information.
Mitigation strategies must prioritize immediate updates to Marmite versions greater than 0.4.2, as this issue has been addressed in subsequent releases through improved input validation logic that correctly rejects traversal sequences after decoding. For environments where upgrading is not immediately feasible, it is imperative to ensure that the development server is never exposed to untrusted networks or public internet interfaces. Access should be strictly limited to localhost connections using bind addresses like 127.0.0.1 rather than 0.0.0.0. Additionally, implementing network-level controls such as firewalls to restrict access to port ranges used by the development server can provide an additional layer of defense. Developers should also adopt secure coding practices that emphasize strict path canonicalization and validation before any file system operations are performed, ensuring that resolved paths remain strictly within the intended base directory regardless of input manipulation attempts.