CVE-2026-63178 in Onyx
Summary
by MITRE • 08/18/2026
Onyx is an open-source AI platform. Prior to 4.3.0, Onyx Enterprise Edition's PATCH /manage/admin/user-group/{user_group_id} and POST /manage/admin/user-group/{user_group_id}/add-users endpoints in ee/onyx/server/user_group/api.py call update_user_group and add_users_to_user_group in ee/onyx/db/user_group.py without enforcing _validate_curator_can_modify_group, allowing a curator to add accounts to arbitrary groups and obtain document access through get_acl_for_user and the OpenSearch access_control_list filter. This issue is fixed in version 4.3.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified within Onyx Enterprise Edition prior to version 4.3.0 represents a critical authorization flaw rooted in improper implementation of access control mechanisms for administrative endpoints. Specifically, the PATCH /manage/admin/user-group/{user_group_id} and POST /manage/admin/user-group/{user_group_id}/add-users API endpoints failed to enforce mandatory validation checks before processing user group modifications. In a secure architecture, any operation that alters membership or permissions within an administrative unit must verify that the requesting actor possesses sufficient privileges for the specific target resource. However, in this instance, the backend functions update_user_group and add_users_to_user_group were invoked directly without calling _validate_curator_can_modify_group, which is designed to ensure that only authorized curators can modify group configurations. This omission creates a direct path for privilege escalation where an actor with curator-level permissions can bypass intended restrictions on group membership management.
The operational impact of this flaw allows a malicious or compromised curator account to add arbitrary user accounts to any existing user group, regardless of whether the curator has legitimate oversight over that specific group. By exploiting this lack of validation, an attacker can effectively grant themselves or other unauthorized users access to sensitive data repositories protected by those groups. The exploitation chain leverages the get_acl_for_user function and the OpenSearch access_control_list filter, which rely on group membership to determine document-level permissions. Consequently, once a user is added to a privileged group through this vulnerability, they inherit all associated read or write rights defined in the Access Control List (ACL) for that group. This results in unauthorized data exposure across multiple documents and potentially sensitive datasets stored within the OpenSearch index, undermining the confidentiality guarantees of the platform's multi-tenant security model.
From a classification perspective, this issue aligns with CWE-269, which denotes Improper Privilege Management, as it involves an actor obtaining privileges that they are not explicitly authorized to hold by manipulating group memberships. Furthermore, the attack vector corresponds to MITRE ATT&CK technique T1078, specifically Valid Accounts and potentially T1548 if viewed through the lens of abusing administrative capabilities for lateral movement or data exfiltration within the system's logical boundaries. The vulnerability highlights a common pitfall in API design where business logic validation is decoupled from endpoint entry points, allowing lower-privileged roles to perform high-impact actions due to missing intermediate checks.
To mitigate this risk, organizations running Onyx Enterprise Edition versions prior to 4.3.0 must upgrade immediately to version 4.3.0 or later, where the _validate_curator_can_modify_group check has been properly integrated into the request handling pipeline for these endpoints. For environments that cannot be patched instantly due to operational constraints, temporary mitigations should focus on restricting network access to the /manage/admin/user-group/ paths to only those IP addresses associated with trusted administrative interfaces. Additionally, implementing strict API gateway policies that validate user roles against group ownership metadata before forwarding requests to the backend can provide a compensating control. Continuous monitoring of audit logs for unusual patterns in user_group modification events should also be enforced to detect potential exploitation attempts while longer-term architectural reviews ensure that all privilege escalation paths are rigorously validated at every layer of the application stack.