CVE-2026-71424

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.

Reviewed through automated stages and approved by a human before publication.