Live › vulnerability › CVE-2026-63500
Yeti, a forensics intelligence platform, fails to validate a UUID in imported DFIQ YAML objects, so the UUID's path traversal sequences are used when exporting to the archive. A low-privileged logged-in user can write attacker-controlled .yaml content to arbitrary locations the Yeti service account can write to.
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 that run a self-hosted Yeti instance that accepts DFIQ YAML imports and allows low-privileged user accounts. Exposure depends on which filesystem paths the Yeti service account can write to; the separate DFIQ archive-import zip-slip issue is not covered by this entry.
No product ranges from the sources yet.
2.5.1.POST /api/v2/dfiq/from_yaml and POST /api/v2/dfiq/to_archive endpoints in your deployment's API logs.2.5.1.Each 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, core/schemas/dfiq.py accepts an unvalidated uuid from DFIQ YAML through POST /api/v2/dfiq/from_yaml, and core/web/apiv2/dfiq.py later interpolates that stored value into an archive filesystem path in POST /api/v2/dfiq/to_archive. A low-privileged authenticated user can import a DFIQ object whose UUID contains traversal sequences and trigger archive export, causing attacker-controlled content with a .yaml suffix to be written outside the intended temporary archive directory. The impact is limited by paths writable by the YETI service account, and the separate DFIQ archive-import zip-slip candidate is not part of this vulnerability. This issue is fixed in version 2.5.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-63500")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.