Live › vulnerability › CVE-2026-63502
Yeti's export feature builds a file path from a user-chosen task name without blocking directory traversal sequences, so a low-privileged logged-in user can read files the Yeti service account can access. Running the export can also write attacker-controlled output to a chosen writable path.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 20:49 UTC. All times on this page are UTC.
Teams running self-hosted Yeti before 2.5.1 with the default local file storage, where any logged-in user can create export tasks. Impact depends on what the Yeti service account can read or write on the host. Deployments on patched versions or with a different storage backend are not described as affected.
No product ranges from the sources yet.
2.5.12.5.1 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-63502")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.