CVE-2026-63502 in Yeti
Summary
by MITRE • 11/03/2026
Yeti bridges the gap between CTI and DFIR practitioners by providing a Forensics Intelligence platform and pipeline. Prior to 2.5.1, YETI derives ExportTask.file_name from the user-controlled task name and passes it to core/clients/file_storage/classes/local_storage.py without sanitizing traversal sequences or enforcing path confinement. A low-privileged authenticated user using the default local storage backend can call POST /api/v2/tasks/export/new with a traversal name and use ExportTask.file_contents through GET /api/v2/tasks/export/{export_id}/content to read files accessible to the YETI service account. Running ExportTask.run() can also write attacker-controlled export output to an attacker-selected writable path. The impact depends on the service account's filesystem permissions, and universal code execution is not established. This issue is fixed in version 2.5.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified within YETI versions prior to 2.5.1 represents a critical directory traversal flaw that compromises the integrity of the Forensics Intelligence platform by allowing unauthorized access to sensitive filesystem resources. As a tool designed to bridge Cyber Threat Intelligence and Digital Forensics, YETI handles significant amounts of structured data and export tasks. The core technical deficiency lies in how the application processes user-supplied input for file operations. Specifically, when an authenticated user initiates an export task via the POST /api/v2/tasks/export/new endpoint, the system derives the ExportTask.file_name directly from the provided task name without performing adequate sanitization of path traversal sequences such as dot-dot-slash characters or enforcing strict path confinement mechanisms. This lack of input validation allows a low-privileged user to manipulate the file path structure during the export process.
The operational impact of this flaw is twofold, involving both unauthorized data exfiltration and potential arbitrary file writes depending on the configuration. By exploiting the directory traversal vulnerability through the GET /api/v2/tasks/export/{export_id}/content endpoint, an attacker can read files that are accessible to the YETI service account but should remain restricted from low-privileged users. This effectively bypasses intended access controls, leading to a breach of confidentiality for sensitive intelligence data or system configuration files stored on the server's filesystem. Furthermore, if the ExportTask.run() method is executed with attacker-controlled parameters, it can write output to an arbitrary path selected by the attacker. While this does not automatically guarantee universal code execution due to restrictions in writing executable payloads directly via this vector alone, it allows for significant manipulation of the file system structure and potential disruption of service integrity if critical files are overwritten or deleted.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize special elements within a pathname that can cause the path to resolve to a location outside of the intended directory. In terms of adversary behavior and detection modeling under the MITRE ATT&CK framework, this exploitation technique maps to T1083: File and Directory Discovery for information gathering and potentially T1564: Hidden Files and Directories if used to obscure malicious artifacts or access hidden system files. The attack vector is classified as Network with Low Complexity since it requires only authenticated network access to the API endpoints, making it a significant risk in environments where YETI instances are exposed to internal networks without strict role-based access control enforcement.
Mitigation strategies must prioritize immediate software updates and robust input validation practices. The primary remediation step is upgrading YETI to version 2.5.1 or later, which addresses the path traversal issue by implementing proper sanitization of user-controlled task names before they are used in file system operations. In addition to patching, administrators should enforce strict least-privilege principles for the service account running the YETI application, ensuring that it has minimal read and write permissions limited strictly to its operational directories. Implementing web application firewall rules or API gateway policies can also provide an additional layer of defense by detecting and blocking requests containing path traversal sequences before they reach the application logic. Regular security audits focusing on file handling routines are recommended to prevent similar vulnerabilities in future development cycles, ensuring that all user inputs interacting with the filesystem are rigorously validated against a whitelist of allowed characters or paths rather than relying solely on blacklist-based filtering which can be bypassed by encoding variations or novel traversal techniques.