Summary
Marmite's development server contains a path traversal vulnerability that may let unauthenticated attackers read arbitrary files accessible to the server process.
The issue becomes risky when the server is exposed to an untrusted network and request paths are percent-decoded and joined with the output directory without rejecting traversal segments.
Affected context
The vulnerability occurs in Marmite's development server when it is started with the --serve option. It affects request handling that decodes URL paths and combines them with the configured output folder without adequately constraining the resulting path. Exposure depends on whether the development server is reachable by unauthenticated or otherwise untrusted clients.
Exploit preconditions
- Attack surface: HTTP request handling in the Marmite development server
- Required access: Network connectivity to the server; authentication is not required according to the vulnerability description
- Trigger point: Processing a request path after percent-decoding and joining it with the output directory
- Why exploitation is possible: Traversal components are not rejected or safely constrained before filesystem access, allowing requests to resolve outside the intended output folder
Why this happens
The underlying bug is insufficient canonicalization and boundary validation of user-controlled filesystem paths. After URL decoding, path components containing parent-directory references can alter the resolved location when joined with the output directory. This maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal.
Potential impact
- An attacker may read application configuration files and source code
- Sensitive credentials, tokens, or environment-related data could be disclosed if readable by the Marmite process
- Internal deployment details may be exposed
- Disclosed information could support follow-on attacks against the host or connected services
General mitigation guidance
Mitigation generally focuses on enforcing a strict filesystem boundary for all user-controlled paths.
Common defensive patterns include:
- Resolve requested paths against the intended document root and verify that the canonical result remains within that root
- Reject parent-directory components and other ambiguous path forms after decoding
- Prefer allowlisted resource mapping over direct filesystem path construction
- Avoid exposing development servers to untrusted networks
- Run the server with the least filesystem privileges necessary and minimize readable sensitive data
- Use secure-by-default binding and access-control settings for development services
How teams detect issues like this
Organizations can look for path traversal risks through:
- Static analysis targeting filesystem joins that incorporate request-controlled paths
- Code review checks for missing canonicalization and document-root boundary validation
- Tests covering encoded, normalized, mixed-separator, and repeated traversal representations
- Web-server and application logs containing requests that resolve outside the intended content directory
- Policy enforcement requiring development services to bind only to trusted interfaces or networks
Automated security scanners and code review tools may help identify suspicious path construction patterns.
