CVE-2026-92783 in Yeti
Summary
by MITRE • 09/16/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Yeti versions through 2.11.0 represents a critical failure in Access Control List enforcement within the application’s Role-Based Access Control subsystem. Specifically, the DELETE /api/v2/rbac/{id} endpoint lacks proper authorization checks to verify whether the initiating requestor possesses sufficient privileges to modify or remove existing access control relationships. This flaw allows any authenticated user with read-only permissions on a given object to execute deletion commands against RBAC entries associated with that object. By exploiting this logic error, an attacker can systematically revoke administrative grants assigned to legitimate owners, effectively stripping them of their ability to manage the resource.
From a technical perspective, this issue stems from insufficient validation of caller permissions during state-changing operations. While standard RESTful practices often assume that read access implies visibility rather than mutability, Yeti’s implementation incorrectly permits destructive actions on security metadata for users who should only have observational rights. The absence of server-side authorization checks means the application relies entirely on client-side restrictions or implicit trust in user roles, which can be easily bypassed using standard HTTP clients or automated scripts that manipulate request parameters directly. This type of flaw is commonly categorized under CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as it allows a lower-privileged entity to perform actions reserved for higher-privileged administrators.
The operational impact of this vulnerability is severe, primarily centering on availability and integrity compromises within the platform’s security framework. Attackers can permanently lock legitimate owners out of their own objects by revoking essential grants such as owner or admin roles. Once these permissions are removed without proper audit trails or recovery mechanisms in place, the affected users lose all ability to interact with, modify, or access the targeted resources. This not only disrupts business operations but also creates a persistent denial-of-service condition for specific assets within the system. Furthermore, by altering RBAC structures maliciously, attackers may pave the way for further privilege escalation if they can subsequently reassign those revoked permissions to their own accounts, thereby gaining unauthorized administrative control over critical systems.
In terms of threat modeling and adversary behavior, this vulnerability aligns with MITRE ATT&CK techniques related to Account Manipulation and Defense Evasion. Specifically, it mirrors T1098.004 SSH Authorized Key Modification or more broadly T1078 Valid Accounts when used in conjunction with permission changes to maintain persistence or disrupt access for defenders. The ability to alter security configurations without proper oversight allows adversaries to weaken the overall security posture of the environment, making subsequent lateral movement or data exfiltration easier by removing monitoring capabilities associated with specific user roles.
To mitigate this risk, immediate remediation should focus on enforcing strict server-side authorization checks before processing any DELETE requests against RBAC endpoints. Developers must ensure that only users holding explicit write or administrative privileges for a given resource can modify its access control lists. Implementing role-based access controls at the API gateway level and conducting regular security audits of permission logic are essential steps to prevent recurrence. Additionally, enabling comprehensive audit logging for all changes to RBAC entries will aid in detecting unauthorized modifications post-exploitation. Upgrading to a patched version where these validation checks have been correctly implemented is the most effective long-term solution to restore trust in the system’s access control mechanisms and ensure that only authorized personnel can manage security permissions.