Description

ZLMediaKit confines the downloadFile API to a configured set of root directories with a prefix comparison that does not account for directory boundaries. The configuration loader in server/WebApi.cpp builds each root with File::absolutePath("", item, true); because the relative-path argument is empty that helper returns the value without a trailing separator. The handler then accepts a requested path when start_with(file_path, root) holds, so a sibling directory whose name merely begins with the configured root string satisfies the test and is served. The only other guard rejects a path containing two dots, which this requires none of. The equivalent confinement check for the ordinary static file server in src/Http/HttpFileManager.cpp computes its root with a non-empty second argument, which appends the separator before comparing, and so is not affected. The endpoint requires the configured API secret, so this grants no privilege beyond what that secret already implies, but it reads files outside the directory the operator confined it to, and the reference container runs the server as root.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.9",
  "pubDate": "2026-08-26T16:16:45.400Z",
  "pubdate": "2026-08-26T16:16:45.400Z",
  "executiveSummary": "A path traversal vulnerability exists in the ZLMediaKit downloadFile API, stemming from insufficient directory boundary validation during path confinement checks.\nThe vulnerability allows an authenticated attacker to read files outside of the intended root directories by exploiting a flawed prefix-matching mechanism.\nThe root cause is identified in server/WebApi.cpp, where the File::absolutePath utility generates path prefixes without trailing separators, causing start_with checks to match sibling directories sharing a common prefix.\nWhile the static file server implementation in src/Http/HttpFileManager.cpp correctly handles path boundaries, the WebApi interface remains exposed.\nExploitation requires a valid API secret, limiting the initial attack surface, but the impact is escalated due to the application often running with root-level privileges.\nSuccessful exploitation allows for unauthorized read access to the underlying filesystem, potentially exposing sensitive system files, configurations, or credentials.",
  "technicalDetails": "The vulnerability is located in the downloadFile API handler within server/WebApi.cpp. The system attempts to enforce directory confinement by validating that a requested file path begins with a pre-configured, trusted root directory string.\nThe root cause is a flaw in how the path prefix is constructed. The configuration loader invokes File::absolutePath(\"\", item, true). Because the relative path argument is empty, the helper function returns an absolute path string lacking a trailing directory separator. When the handler performs a prefix comparison using start_with(file_path, root), it fails to account for directory boundaries.\nConsequently, if an administrator configures a root directory such as '/opt/data', the prefix check would incorrectly approve access to a sibling directory named '/opt/database' because it shares the same starting string. The only existing constraint—a rejection of paths containing '..' (two dots)—is insufficient to prevent this traversal, as an attacker can access sibling directories without traversing up the directory tree.\nThe exploitation flow is as follows: 1) An attacker authenticates with the required API secret. 2) The attacker submits a crafted request to the downloadFile endpoint specifying a path that matches the prefix of a configured root but points to an unintended sibling directory. 3) The validation logic in server/WebApi.cpp erroneously evaluates the path as valid because it satisfies the start_with check. 4) The server reads and returns the contents of the target file to the attacker.\nThis vulnerability is particularly severe because the reference container implementation executes the ZLMediaKit service with root-level privileges. This enables an attacker, once authenticated, to read any file on the filesystem that they can target via the prefix-matching flaw, bypassing intended confinement boundaries. This contrasts with the HttpFileManager.cpp implementation, which correctly appends a separator before comparison, ensuring robust boundary enforcement."
}