SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
CVE-2026-63178 is a reminder of how easily access control promises can quietly break down. The curator role in Onyx Enterprise Edition was designed to give scoped administrative rights over a handful of assigned groups, nothing more. In practice, a gap in two API endpoints let a curator manage the membership of any group in the deployment, not just their own. Because document-retrieval access in Onyx is computed directly from group membership, that gap gave curators an indirect but fully functional path into other teams’ documents, without ever needing to touch the documents themselves.
Onyx is an open-source AI platform built for teams that want to bring AI chat and retrieval capabilities to their own internal knowledge, spanning everything from wikis and tickets to shared drives and messaging platforms. Like most systems that mix sensitive organizational data with fine-grained user permissions, its value depends heavily on access control boundaries holding up under real-world use. When those boundaries are designed well, a marketing team’s documents stay visible to marketing and finance’s stay visible to finance, regardless of how many other roles and integrations sit on top of the platform.
An Insecure Direct Object Reference occurs when an application lets a user supply an identifier, a record ID, a file path, a group number and acts on the object behind it without checking whether that user is actually authorized to touch it. The application trusts the ID in the request instead of verifying ownership or scope.
CVE-2026-63178 is classified as exactly that kind of flaw, scoped to Onyx’s curator role (CWE-639): a failure to verify that an authenticated curator is authorised to act on the specific object, here a user group, they’ve referenced by ID. In practice, there are two related flaws in the same route layer and both let a curator reach into groups they were never assigned.
CVE-2026-63178 was reported by Shirshak Roy, security engineer at Secnora and rated 6.5 (Medium) on the CVSS 3.1 scale. A curator, a role meant to administer only the specific groups assigned to them, can instead rewrite the membership of any user group in the deployment. Because Onyx computes document-retrieval ACLs from live group membership, that gives a curator a direct route into another team’s documents without ever touching the documents themselves.
Onyx Enterprise Edition’s RBAC model gives curators scoped admin rights over a subset of user groups, not the whole deployment. In a correctly enforced system, a curator managing “Marketing” should get a 403 the moment they try to touch “Finance.” The codebase already has the pattern for this:
Both show the correct check has existed elsewhere in the codebase for some time. It just wasn’t applied everywhere it needed to be.
Two curator-reachable endpoints, however, didn’t get the same treatment. Both mutate group membership directly, yet neither one carries the same curator-to-group scope check that “_validate_curator_relationship_update_requester” and “validate_object_creation_for_user” already enforce elsewhere, the exact gap that becomes CVE-2026-63178:
Both live in the user_group API module (“ee/onyx/server/user_group/api.py”) and both depend only on a role check called “current_curator_or_admin_user” which confirms the caller holds a curator or admin role but never checks whether they curate that specific group.
The PATCH route calls straight through to a database function, “update_user_group” which takes the caller as an unused parameter, the linter suppression “# noqa: ARG001” marks it that way in the code itself and never consults the caller’s curated-group list. It fetches the target group by ID, runs a modifiability check that only blocks default or syncing groups, then mutates membership and rebinds connector-credential pairs. The add-users route performs no scope check of its own before delegating to that same function.
There’s also a commented-out block a few hundred lines further down, reading “Only admins can add or remove users from user groups,” suggesting an ownership restriction existed at some point and was disabled. The official record names the missing guard directly as “_validate_curator_can_modify_group”. The practical result, a curator exploiting CVE-2026-63178 only needs to know or guess another group’s numeric ID to rewrite its membership, including adding their own account.
This matters because of how Onyx builds retrieval permissions. A function in the access module builds each user’s ACL by pulling their live group memberships and prefixing each group name into a permissions list. At query time, that ACL gets passed into OpenSearch’s filtering logic and OpenSearch applies it as a hard filter on search results.
Group membership is the input to that filter and group membership is exactly what the unscoped endpoints let a curator forge. Self-add to a group you don’t curate and your next search inherits that group’s document access. In Onyx EE deployments where group membership mirrors external connectors such as Confluence, Drive, Slack, SharePoint and Jira, that’s a curator in one team reading another team’s permission-synced documents. OpenSearch itself isn’t at fault here; it simply trusts the ACL the backend hands it and the backend is handing it a forged one.
The disclosure verified CVE-2026-63178 live on self-hosted Onyx v4.0.7 with Enterprise Edition enabled. The walkthrough registered an admin and a curator, scoped the curator to a group (“GroupB”) that did not include a second group (“GroupA”), then used the curator’s session to:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N, base score 6.5:
The disclosure’s own severity assessment for CVE-2026-63178 lists exploitation as proof-of-concept and technical impact as total within the application’s own data scope, which lines up with a Medium CVSS score sitting on top of a high-impact confidentiality outcome. The privilege requirement is doing a lot of the work in keeping the number where it is.
CVE-2026-63178 highlights a common failure pattern rather than a hard-to-find bug. The correct authorization pattern already existed in the codebase, proven and working, just not applied to the two endpoints that needed it. That gap between “the right check exists” and “the right check is applied consistently” is where a large share of real-world authorization flaws originate, and closing it takes more than a one-time fix. It requires periodically verifying that every endpoint handling similar objects enforces the same boundaries as its neighbors.
For organizations running Onyx Enterprise Edition, the immediate remediation is straightforward: upgrade to v4.3.0 or later. The more important step is the follow-up. Any deployment with active curator accounts should treat this as an opportunity for a targeted log review, not just a routine patch cycle, cross-checking PATCH and add-users calls against each curator’s assigned scope to rule out prior misuse before assuming the exposure window was never exercised.
SECNORA supports organisations with vulnerability assessments and managed detection and response, helping teams identify and address gaps like this one before they can be exploited. Talk to our team.
SECNORA® is a CREST Accredited cyber security focused consulting firm with expertise in Information Security and Governance, Risk, Compliance.
Copyright @ 2026 SECNORA®