AI Gateway CVE-2026-117574

Requires a valid authenticated tenant account on the shared multi-tenant AI gateway (consistent with PR:L), and the attacker must supply another tenant's model identifier in the request body or header. The vulnerable behavior is the service retrieving credentials from a shared store without an authorization check before injecting API keys, as described. Limiting factors: the attacker must already be an authenticated tenant and must know or guess a target tenant's model identifier; the issue is inherent to the shared-credential-store design described rather than a toggleable non-default feature. Impact is confined to cross-tenant key use and resource/quota consumption as stated - the available sources do not describe arbitrary code execution or data modification beyond issuing requests as the victim.

The input assigns a CVSS 9.1 (Critical), and the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L shows that most of the score is driven by the scope change (S:C) and C:H - the flaw crosses the tenant isolation boundary and exposes/uses another tenant's API keys. The authentication requirement is confirmed by the vector: PR:L means the attacker must hold a valid tenant account (authenticated), which tempers the raw severity - this is not an anonymous internet attack but an insider-or-any-valid-customer attack against a multi-tenant service. Attack vector is network (AV:N) with low complexity (AC:L) and no user interaction (UI:N), so once authenticated, exploitation is straightforward. The vuln.today Decision label is act_now, consistent with the critical score and the clear, concrete bypass mechanism. However, several key risk signals are missing: no EPSS score, no CISA KEV listing, and no PoC/exploit reference are present in the input, so exploitation probability and in-the-wild activity cannot be quantified - the act_now priority here reflects severity and clarity of the flaw, not confirmed exploitation. CWE-639 (authorization bypass via user-controlled key) matches the described IDOR-style tenant-ID substitution precisely. Net: a genuine high-priority issue for any operator of this multi-tenant AI gateway, but the real-world blast radius depends on having authenticated tenant accounts and knowing another tenant's model identifier.

An attacker who holds a legitimate tenant account on the shared AI gateway sends an otherwise normal API request but places a different tenant's model identifier in the request body or header. Because the service retrieves credentials from a shared store without checking authorization, it injects the victim tenant's API keys into the outbound request, letting the attacker invoke the LLM backend on the victim's credentials and drain their quota. No public exploit code is identified in the input, but the technique requires only a valid account and a known target model identifier.