This vulnerability exposes a data architecture failure: per-user OAuth tokens were stored in a shared MCPConnectionConfig row for convenience, creating both a security boundary violation and a latent race condition. When OnyxTokenStorage.set_tokens copies user authentication headers into what should be an admin-level configuration row, it's the path of least resistance in fast-moving platform development — the MCP integration likely shipped quickly, authorization was assumed to happen at the API layer, and someone stashed transient user state in a convenient singleton rather than refactoring the data model.
The second failure vector is equally instructive. The endpoint _db_mcp_server_to_api_mcp_server was returning auth_template.headers to any user with BASIC_ACCESS permissions because the authorization check was added at the entry point without auditing what the handler actually returned. This is the "post-hoc auth gate" pattern: security improvements get bolted onto API endpoints while the data layer underneath retains its original, overly-permissive shape. One developer added the access check; another wrote the return statement that handed out privileged data to anyone who passed the gate.
The per-user token isolation fix addresses the immediate symptom. What it may not address is whether other endpoints in Onyx use the same return pattern against shared structures — whether auth_template or equivalent data is still being returned to under-privileged callers in other features. Audit your codebase for endpoints that return shared configuration objects to users who shouldn't have access to the underlying data structure.
Two additional concerns deserve attention. First, OAuth tokens have a temporal blast radius that CVSS scoring doesn't capture: tokens captured during the exposure window may persist in logs, caches, or third-party integrations, and their authorized scope can expand over time as the platform adds new capabilities. The fix closes the code path but doesn't invalidate tokens already leaked. Second, every feature that consumed auth_template or similar shared structures during the exposure window accumulated trust in a leaky data layer — those dependent features now need auditing, not just the MCP integration itself. The vulnerability is closed; the exposure surface from the preceding period may not be.