EUVD-2026-81046
GHSA-w297-93hv-q3cx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with read-only Yeti account
-
DeliveryEnumerate RBAC relationship IDs
-
ExploitSend DELETE /api/v2/rbac/{id}
-
ExecutionServer skips permission check
-
PersistOwner grant revoked
-
ImpactLegitimate owners locked out
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a valid authenticated Yeti account with at least read access (PR:L) and network reachability to the API. Exploitation targets the DELETE /api/v2/rbac/{id} endpoint, which omits any caller-permission check, letting the account delete RBAC relationships it does not own. Limiting factors: an account is mandatory (no unauthenticated path), impact is confined to authorization integrity and availability (deleting/ revoking grants and locking owners out) with no data confidentiality loss, and only multi-user Yeti deployments with RBAC-managed objects are meaningfully at risk. Affects all versions of Yeti from 0 through 2.11.0. |
| Impact | Genuine but bounded risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H) describes a network-reachable, low-complexity flaw that requires low-privilege authentication (PR:L) - an existing Yeti account with only read access. This is a CWE-862 missing-authorization broken-access-control bug, not remote code execution: confidentiality impact is explicitly none (VC:N), while integrity and availability are high (VI:H/VA:H) because an attacker can delete RBAC relationships and permanently lock legitimate owners out of objects. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so exploitation is not confirmed in the wild - this reads as a real integrity/availability priority for anyone running a multi-user Yeti instance, but not an internet-wide mass-exploitation event. The PR:L requirement (a valid low-trust insider or a compromised read-only account) is the key limiter that keeps this below the 'drop everything' tier. Note the vendor supplied only a CVSS 4.0 vector; no CVSS 3.1 or SSVC decision data was provided, and the input's 7.2 aligns with the 4.0 vector. |
| Exploit ScenarioDerived | A low-privilege Yeti user (or an attacker who has phished a read-only analyst account) calls DELETE /api/v2/rbac/{id} against an access-control relationship they do not own. Because the endpoint never validates the caller's permissions, the request succeeds and revokes the true owner's grant, permanently locking the owner out of the object. No public proof-of-concept is identified, but the flaw is a single unauthorized API call and trivially reproducible. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
Authenticated users with only read access can delete RBAC relationships in Yeti through 2.11.0, revoking owner grants and locking legitimate owners out of objects. The flaw resides in the DELETE /api/v2/rbac/{id} endpoint, which omits a caller-permission check (CWE-862). No public exploit code or active exploitation has been identified at time of analysis; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H) indicates high integrity and availability impact with no confidentiality loss, consistent with a genuine but bounded risk.
RemediationAI
No vendor-released patch identified at time of analysis. Until a fixed version is available, apply compensating controls: (1) Restrict access to the DELETE /api/v2/rbac/{id} endpoint using a reverse proxy rule (e.g., Nginx location block) that allows only administrative users or trusted IP ranges - trade-off: legitimate read-only users lose the ability to delete their own RBAC relationships. (2) Implement a temporary authorization check in core/web/apiv2/rbac.py at the vulnerable endpoint to verify the caller has admin privileges before processing the deletion - this requires code modification but directly addresses CWE-862. (3) Monitor API logs for DELETE requests to /api/v2/rbac/ and alert on unexpected deletions. (4) Ensure regular backups of RBAC configuration so that deleted relationships can be restored. Refer to the GitHub issue #1349 and the VulnCheck advisory for updates.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
CVE-2026-92783 is a missing authorization vulnerability (CWE-862) in the Yeti threat intelligence platform, a Python-based application for managing cyber threat data. The affected component is the REST API endpoint DELETE /api/v2/rbac/{id}, implemented in core/web/apiv2/rbac.py (references point to lines 110-116 and 52-53 of version 2.5.1). The endpoint fails to validate whether the requesting user has the necessary permissions to delete an RBAC relationship; any authenticated account with at least read access (PR:L) can invoke it. RBAC relationships in Yeti connect users or groups to objects with specific permissions (e.g., owner grants). Deleting these relationships can revoke an owner's grant, effectively locking the legitimate owner out of the object. The vulnerability affects all versions of Yeti from 0 through 2.11.0, as reflected by CPE cpe:2.3:a:yeti-platform:yeti:*:*:*:*:*:*:*:* and EUVD-2026-81046. The attack is network-based (AV:N) with low complexity (AC:L) and no user interaction (UI:N); impact is limited to integrity and availability (I:H/A:H) with no confidentiality loss (C:N).
Know when Yeti gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
Network API reachable, low complexity, needs a low-privilege authenticated account (PR:L); deleting ACL grants is high integrity and high availability impact, no confidentiality loss (C:N).
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Yeti through 2.11.0 fails to validate caller permissions in the DELETE /api/v2/rbac/{id} endpoint, allowing users with read access to delete access control relationships. Attackers can revoke the owner's grant and permanently lock legitimate owners out of objects.
Executive ViewAI
Yeti's access control mechanism contains a high-severity flaw that allows authenticated users with only read privileges to delete RBAC relationships, revoking ownership and locking legitimate owners out of objects. This can disrupt critical security operations that rely on Yeti for threat intelligence management, leading to potential data governance failures and operational downtime. With no vendor patch currently available, organizations must take immediate steps to mitigate the risk.
No vendor patch identified at time of analysis. Interim mitigations include blocking or restricting access to the DELETE /api/v2/rbac/{id} endpoint at the network or API gateway level, enforcing strict role-based access controls to limit the ability to modify RBAC relationships, enabling detailed audit logging and real-time alerting for all RBAC changes, and applying the principle of least privilege to all authenticated users.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Yeti bridges the gap between CTI and DFIR practitioners by providing a Forensics Intelligence platform and pipeline. Rat
Authenticated path traversal in Yeti (YETI threat-intelligence platform) prior to 2.5.1 lets a low-privileged, non-admin
Authenticated AQL injection in YETI 2.5.0 and earlier lets any low-privileged analyst account push attacker-controlled s
Unauthenticated information disclosure in Yeti Platform (yeti-platform/yeti) before 2.5.1: the audit router is mounted o
Path traversal in YETI's DFIQ import/export pipeline allows a low-privileged authenticated user to write attacker-contro
Exploit-DB