Yeti Platform EUVD-2026-116266

Exploitation requires three concrete prerequisites stated in the advisory: (1) a valid authenticated YETI account that does NOT need administrator privileges; (2) the deployment must use the default local file storage backend (core/clients/file_storage/classes/local_storage.py), since the traversal occurs in its path joining; and (3) the YETI service account must hold filesystem read/write permissions on the targeted paths, which bounds both what can be read (C:H) and what can be written (I:H/A:L). The trigger is the ExportTask 'name' field (e.g. '../../../../../../etc/passwd') consumed via ExportTask.file_name without path-separator or '..' sanitization. Limiting factors for defenders: the authentication requirement (PR:L) prevents anonymous exploitation; non-default (non-local) storage backends are not described as affected; and the ultimate blast radius is constrained by the service account's filesystem permissions and deployment layout rather than being guaranteed code execution.

This is a genuine prioritization candidate rather than CVSS-inflation, but it is bounded by an authentication precondition. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L (score 8.3) is internally consistent with the verified advisory: network-reachable REST API (AV:N), no race or special timing (AC:L), a low-privileged authenticated account (PR:L), and no user interaction (UI:N), yielding confirmed arbitrary file read (C:H) and arbitrary file write (I:H) with corruption/DoS potential (A:L). The vuln.today decision label is 'this_week' (not act_now/emergency). No CISA KEV listing is present, so there is no confirmed active exploitation; however, a detailed author-verified proof-of-concept IS present in the GHSA advisory (working curl-based read and write PoCs), so this is not a theory-only finding. No EPSS score was supplied in the input, so probabilistic exploitation likelihood cannot be quantified here. The single most important limiting signal is PR:L: an attacker needs a valid non-admin YETI account AND the deployment must use the default local storage backend, which narrows this from internet-wide spray toward authenticated/insider or post-credential-compromise abuse. Net: treat as a real high-severity issue to patch promptly given the working PoC and C:H/I:H impact, but it is not an unauthenticated internet-wide emergency.

A low-privileged authenticated YETI user (e.g. the 'analyst' role) sends POST /api/v2/tasks/export/new with a task name like '../../../../../../etc/passwd', then calls GET /api/v2/tasks/export/{export_id}/content to read files readable by the YETI service account - config files, database credentials, or JWT signing secrets. The same traversal, when the export task runs, writes attacker-controlled output to a writable path outside the export directory. A public, author-verified PoC for both read and write exists in the GHSA advisory (not packaged as weaponized exploit code); attack complexity is low (AC:L) and no user interaction is needed.