Onyx CVE-2026-71424 and 63178: MCP tokens and group boundaries in enterprise RAG
Two Onyx flaws exposed other users' MCP OAuth tokens and let curators extend access into another group's documents. We examine the mechanics, fixes and detection.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 17 August 2026
- READING TIME
- 15 min read
- TOPIC
- AI Security
CVE-2026-71424 and CVE-2026-63178, both affecting the Onyx platform formerly known as Danswer, were published on 17 August 2026. The flaws reach into a particularly sensitive part of enterprise AI: the connection between a retrieval-augmented generation system, external tools and protected documents. One could disclose one user’s OAuth token to another user. The other let a curator extend their own membership into a group they were not meant to manage and then read documents protected by that membership.
These are not two labels for the same bug. CVE-2026-71424 concerns secret isolation in MCP connection configuration and carries a CVSS score of 9.6. CVE-2026-63178 is an object-authorisation failure in Enterprise group management, scored 6.5. Their common architectural consequence is more useful than the numbers: a control on one screen or endpoint is insufficient when another security layer trusts the state that endpoint creates.
The primary advisories do not report widespread exploitation. The flaws nevertheless warrant a prompt upgrade, revocation of potentially disclosed credentials and a review of historical changes. That is especially true where Onyx connects to Slack, Atlassian, Notion, Linear or a custom MCP server with permissions more powerful than those of an ordinary user.
CVE-2026-71424: a private token placed in a shared object
Model Context Protocol standardises how an AI application discovers and invokes tools. The protocol does not, by itself, solve identity isolation in the host application. Onyx kept an administrative MCPConnectionConfig describing a connection, including an authentication template. Separately, an end user completed OAuth to connect their own account to the upstream service.
According to the CVE-2026-71424 advisory, linking OAuth through a value identified by alt_config_id could write the user’s token into the administrative, shared configuration object. The credential stopped being a property of the relationship “this user to this integration.” It became part of a template available to other accounts.
The read path completed the disclosure. Endpoints that listed connection configurations returned auth_template.headers without masking them to a user holding BASIC_ACCESS. If a bearer token had landed in that header, another authenticated user could recover it. They did not need to break OAuth or steal an administrator password; they only had to read an object the application mistakenly treated as harmless configuration metadata.
A useful threat model separates three boundaries:
- a connection template describes an address, capabilities and authentication method but must not carry one person’s secret;
- a user credential must be encrypted, bound to that user and excluded from ordinary response objects;
- a tool invocation retrieves the correct token only after authorising the user and never copies it into shared state.
Breaking the first boundary enabled the second failure. The third expands the consequence because the stolen token matters outside Onyx too. It may work directly against the upstream service within the scope granted during OAuth consent.
What a compromised MCP credential really grants
Impact depends on token scope, provider configuration and the victim’s privileges. A Slack credential may permit message search or workspace actions. An Atlassian grant may expose projects and documentation. A credential for a custom MCP server might reach administrative tools, repositories or knowledge bases. It would be inaccurate to say that every affected deployment allowed takeover of all these systems. It is prudent, however, to assume credential confidentiality was lost wherever a vulnerable version handled per-user OAuth.
That distinction changes incident response. Updating Onyx prevents new exposure but cannot invalidate a token copied before the fix. The credential remains useful until it expires or the provider revokes it. Response therefore needs an inventory of users and integrations, revocation of active grants, account reconnection and review of upstream audit logs.
Look for the token being used from a new IP address, an unusual user agent, a location inconsistent with the owner’s activity or calls with no preceding Onyx session. If a provider rotates refresh tokens on use, refresh failures and unexpected new consent may also reveal competing use. Do not copy raw tokens into a SIEM. A stable grant identifier, owner, integration and non-reversible fingerprint provide correlation without creating another credential store.
Affected versions and the CVE-2026-71424 fixes
The advisory identifies versions below 3.1.10, releases from 3.2.0 to before 3.2.14, and versions from 3.3.0-beta.0 to before 4.0.0 as vulnerable. Fixes shipped in 3.1.10, 3.2.14 and 4.0.0 respectively. Version comparison therefore has to include the release branch; a simplistic “larger is safe” check is not enough.
An organisation held on an old branch for compatibility reasons should deploy the newest patch for that branch, disconnect per-user OAuth while it completes revocation and restrict configuration reads. The better destination is a supported branch that also includes subsequent security fixes. Because the second flaw discussed here is only fixed in 4.3.0, a common minimum destination for both issues is Onyx 4.3.0, unless the release notes for a newer supported version say otherwise.
CVE-2026-63178: curator role checked without curator scope
Onyx Enterprise can group users and documents. A curator is meant to administer a defined content area, not the whole tenant. Vulnerable group-update and add-user endpoints checked whether the caller held a curator role but did not verify whether that person curated the particular target group.
The CVE-2026-63178 advisory describes a curator selecting an arbitrary group identifier and adding themselves. This is broken object-level authorisation: the decision “may edit groups” was confused with “may edit this object.” A role check answered only the first question.
The next step did not require a separate search vulnerability. Onyx calculated document access from current group membership. Once the attacker added themselves, the search layer regarded them as a valid recipient. OpenSearch results, chunks supplied to the RAG pipeline and the assistant’s response could consequently include documents that had previously been out of scope.
This is why RAG access control does not begin and end with a vector-database query. If the ACL is derived from a group directory, every operation changing that directory is part of the data security boundary. A correct filter cannot help when it receives an incorrect but formally valid membership state.
The flaw affected Onyx Enterprise before 4.3.0 and was corrected in 4.3.0. Regression testing after the upgrade should go beyond denying an ordinary user. Test an object matrix: a curator of group A cannot read, edit or add members to group B; administrators can perform clearly defined operations; and a role change invalidates old permissions immediately.
An administrator’s response plan
Start by inventorying instances, versions, editions and deployment methods. Include production, staging, demonstrations and private team workspaces because test integrations often hold real tokens. Determine whether MCP OAuth was enabled and whether Enterprise curators and groups were used.
Then:
- upgrade to a supported release of at least 4.3.0, taking a configuration backup and validating schema migration;
- revoke OAuth tokens at every provider before reconnecting user accounts;
- verify that tokens, API keys and authorisation headers are absent from shared records, logs, exports and support bundles;
- export group-membership history and reconcile it against the approved identity source;
- review group
PATCHoperations, user additions, curator-role changes and document queries immediately following them; - require fresh authentication for privileged sessions and preserve evidence before cleaning state.
Do not validate the flaw in production by reading another person’s tokens or documents. Safe verification means checking the deployed version, running regression tests with synthetic secrets in an isolated environment and confirming that API responses omit or mask sensitive fields. Also confirm that a gateway or reverse proxy does not retain configuration response bodies in debug logs.
Detecting abuse when the endpoint looks legitimate
Both vulnerabilities use well-formed requests after authentication, so a basic WAF may see nothing unusual. Telemetry needs the caller identity, target object, previous and new value, authorisation decision and session identifier. For group changes, alert when a curator touches a group outside their scope, adds themselves, or immediately searches the new group’s documents.
For MCP, log configuration access and the event of releasing a credential to a connector, never the credential value. Flag bulk configuration listing, basic-role access to auth_template and upstream traffic that cannot be matched to an agent operation. Correlation between Onyx and SaaS audit trails is stronger than either source alone: the service may see a valid token while Onyx establishes that it did not initiate the call.
Log retention should exceed the normal refresh-token lifetime and reflect the sensitivity of the connected data. Access logs alone are not sufficient without an auditable membership history. A snapshot of today’s group answers “who has access now,” not “who had it when this retrieval occurred.”
Design lessons for enterprise AI
A per-user secret must not be a property of a shared template. Prefer a dedicated vault, with the application database containing only a reference annotated by owner, provider, scope and expiry. The serialization layer should expose an explicit secret-free model. Sensitive fields should be excluded by default rather than relying on every endpoint author remembering to mask them.
Group authorisation must check action, object and caller-to-object relationship. Tests need pairs of tenants, groups and roles, not only a successful administrator path. A membership change must invalidate permission caches predictably, and the system must retain enough context to reconstruct historical decisions.
Facts about affected releases, mechanics and fixes come from the project’s advisories. Credential revocation, audit correlation and treating the group directory as part of the RAG boundary are Breachroad analysis. We do not claim every vulnerable instance was exploited or every exposed credential had an identical scope.
AI, IAM, SOC and data-owner teams should rehearse this class of failure together. AI and cybersecurity training helps teams separate the model, connector, secret and access policy. MCP architecture, RAG permissions and OAuth paths can then be reviewed in an AI security assessment.
