CVE-2026-92783: Yeti RBAC Authentication Bypass Vulnerability

CVE-2026-92783 Overview

CVE-2026-92783 is a missing authorization vulnerability [CWE-862] in the Yeti threat intelligence platform through version 2.11.0. The DELETE /api/v2/rbac/{id} endpoint fails to validate caller permissions before removing role-based access control (RBAC) relationships. Any authenticated user with read access can delete access control grants belonging to other users, including object owners. Attackers can revoke the legitimate owner's grant and permanently lock users out of the objects they created.

Critical Impact
An authenticated low-privilege user can delete RBAC relationships on any object, revoking ownership and denying access to legitimate owners across the Yeti platform.

Affected Products

Yeti Platform versions through 2.11.0
Yeti core/web/apiv2/rbac.py RBAC API module
Deployments exposing the /api/v2/rbac/{id} endpoint to multiple users

Discovery Timeline

2026-09-16 - CVE-2026-92783 published to NVD
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-92783

Vulnerability Analysis

Yeti is an open-source threat intelligence platform that uses RBAC relationships to associate users with objects such as observables, entities, and indicators. The RBAC subsystem stores these relationships as first-class objects addressable through the /api/v2/rbac/{id} API. The DELETE handler in core/web/apiv2/rbac.py accepts a relationship identifier and removes the record without confirming that the requesting user owns, manages, or otherwise controls the target grant. As a result, a user holding only read access to an object can enumerate its RBAC relationships and delete the grant that binds the object to its owner.

Once the owner's grant is removed, the owner loses all permissions on that object. Because grants cannot be recreated by a user who no longer has any role on the object, the lockout is persistent and requires administrative intervention. The flaw is a broken access control issue rather than an authentication bypass; callers must be authenticated, but the server never checks whether the authenticated principal is authorized for the specific deletion request.

Root Cause

The root cause is the absence of an authorization check in the RBAC delete path. The handler resolves the relationship by ID and calls the delete operation directly. Review of the referenced snippets in core/web/apiv2/rbac.py at lines 52-53 and 110-116 shows the endpoint relies only on the standard authentication dependency, with no verification that the caller has write or admin rights over the relationship being removed. This maps to [CWE-862] Missing Authorization.

Attack Vector

Exploitation requires a valid Yeti account with any level of API access. The attacker queries the RBAC API to identify the relationship identifier linking a target object to its owner, then issues a DELETE request against /api/v2/rbac/{id}. The server processes the deletion regardless of the caller's role on the underlying object. Attackers can script the enumeration and deletion to lock multiple owners out of investigations, indicators, or shared threat intelligence artifacts. See the VulnCheck Advisory on Yeti and Yeti Issue #1349 for reproduction details.

// No verified exploit code is published for CVE-2026-92783.
// Refer to the VulnCheck advisory and Yeti issue tracker for technical detail.

Detection Methods for CVE-2026-92783

Indicators of Compromise

DELETE requests to /api/v2/rbac/{id} originating from accounts that do not own the referenced object.
Yeti audit or application logs showing RBAC relationship removals immediately followed by permission-denied errors for previous owners.
Sudden loss of access complaints from analysts for objects they created.
Automated or scripted API traffic enumerating /api/v2/rbac/ endpoints from a single low-privilege session.

Detection Strategies

Parse Yeti reverse-proxy or application logs for HTTP DELETE calls to /api/v2/rbac/ and correlate the calling user with the owner of the affected object.
Alert when a single authenticated session issues multiple RBAC delete calls within a short window.
Baseline normal RBAC administrative activity and flag deletions performed by non-administrator accounts.

Monitoring Recommendations

Forward Yeti API access logs to a centralized logging or SIEM platform and retain them for post-incident review.
Monitor for role or grant modifications on high-value objects such as investigations and indicators used in active response.
Track failed authorization events following RBAC deletions to identify locked-out owners quickly.

How to Mitigate CVE-2026-92783

Immediate Actions Required

Upgrade Yeti to a fixed release once published by the maintainers; track the Yeti Platform Repository and Yeti Issue #1349 for the patched version.
Restrict access to the Yeti API to trusted analysts only and remove accounts that no longer require access.
Audit RBAC relationships and restore any grants removed by unauthorized users.

Patch Information

As of the NVD publication on 2026-09-16, Yeti versions through 2.11.0 are affected. Consult the VulnCheck Advisory on Yeti and the upstream project for the fixed release. Apply the vendor patch that adds an authorization check to the DELETE /api/v2/rbac/{id} handler in core/web/apiv2/rbac.py.

Workarounds

Place the Yeti API behind a reverse proxy that blocks DELETE requests to /api/v2/rbac/ from non-administrative source networks or accounts.
Reduce the number of accounts with API access until the patch is applied.
Regularly export RBAC relationships to enable rapid restoration if unauthorized deletion occurs.

bash

# Example nginx snippet to block RBAC deletions from untrusted networks
location ~ ^/api/v2/rbac/ {
    limit_except GET POST {
        allow 10.0.0.0/24;   # administrator subnet
        deny all;
    }
    proxy_pass http://yeti_backend;
}