CVE-2026-71424 in Onyx
Summary
by MITRE • 08/18/2026
Onyx is an open-source AI platform. Prior to 3.1.10, 3.2.14, and 4.0.0, Onyx's GET /api/mcp/servers and GET /api/mcp/servers/persona/{persona_id} endpoints expose another user's OAuth Authorization header because OnyxTokenStorage.set_tokens and OnyxTokenStorage.set_client_info in backend/onyx/server/features/mcp/api.py copy per-user tokens into a shared admin MCPConnectionConfig row and _db_mcp_server_to_api_mcp_server returns that row through auth_template.headers to any BASIC_ACCESS user. This issue is fixed in versions 3.1.10, 3.2.14, and 4.0.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified within the Onyx open-source AI platform represents a critical failure in access control mechanisms, specifically manifesting as an insecure direct object reference combined with improper authorization checks. This flaw affects versions prior to 3.1.10, 3.2.14, and 4.0.0, allowing authenticated users who possess only basic access privileges to retrieve sensitive OAuth Authorization headers belonging to other users or administrative contexts. The core of the issue lies in how the backend handles token storage and retrieval for Model Context Protocol servers. Specifically, the functions OnyxTokenStorage.set_tokens and OnyxTokenStorage.set_client_info are designed to manage user-specific credentials but erroneously copy per-user tokens into a shared admin MCPConnectionConfig row. This architectural decision creates a state where sensitive authentication material intended for privileged or specific user contexts is stored in a location that lacks proper isolation from general access paths.
The exploitation of this vulnerability occurs through the GET /api/mcp/servers and GET /api/mcp/servers/persona/{persona_id} endpoints. When these endpoints are invoked, they utilize the _db_mcp_server_to_api_mcp_server function to construct the API response. This function retrieves data from the database and maps it to an API structure via auth_template.headers. Due to the aforementioned storage flaw, this process inadvertently includes the shared admin row containing other users' OAuth tokens in the headers returned to any BASIC_ACCESS user. Consequently, a low-privileged attacker can issue requests to these endpoints and receive responses that contain valid authorization headers for higher-privilege accounts or different user identities. This effectively bypasses authentication controls by allowing one user to impersonate another using stolen credentials embedded within the API response payload.
From an operational impact perspective, this vulnerability poses severe risks including unauthorized access to sensitive data, privilege escalation, and potential compromise of downstream systems that rely on these OAuth tokens for authentication. An attacker who obtains these headers can use them to authenticate as other users or administrative accounts against external services protected by those OAuth providers. This could lead to the exfiltration of confidential information, modification of critical resources, or further lateral movement within connected ecosystems. The severity is amplified because the vulnerability does not require complex exploitation techniques; it relies on a straightforward API call that returns sensitive data due to flawed server-side logic rather than client-side manipulation.
This issue aligns with CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor, and specifically relates to CWE-639, Injection into Critical State Variables, as the state management for tokens is mishandled leading to data leakage. In terms of the MITRE ATT&CK framework, this vulnerability facilitates Initial Access through Valid Accounts (T1078) by allowing attackers to steal valid credentials from other users. It also relates to Privilege Escalation via Abuse of Elevation Controls if the stolen tokens belong to administrative accounts. To mitigate this risk, organizations must upgrade Onyx to version 3.1.10, 3.2.14, or 4.0.0 and later, where these storage and retrieval mechanisms have been corrected to ensure proper isolation of user-specific tokens. Additionally, developers should implement strict access control checks on all API endpoints that return sensitive configuration data and avoid storing per-user credentials in shared global state without rigorous validation of the requesting user's permissions relative to the stored token owner.