grok2api CVE-2026-124574

Requires a valid but scope-restricted client key (PR:L) - exploitation is not possible unauthenticated. The attacker's key must be configured with a restricted AccountScope (e.g. ProviderScope/TierScope limits), and the attacker must drive a video-generation job through the retry path in runVideoJob: the originally pinned in-scope account must fail (e.g. a forbidden or transient error) so that beginSelectionSession is invoked for replacement selection, at which point the pre-patch code omits the key's scope and can select an out-of-scope account. Limiting factors: authenticated access via a provisioned client key is mandatory, a scope-restricted key configuration must exist, the pinned account must actually fail to reach the retry branch, and impact is confined to the video job account-selection path and the victim account's quota rather than broader system access.

This is a genuine but limited-severity authorization flaw, not a high-impact priority. The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P, base 5.3) indicates network reach with low complexity but requires privileges (PR:L) - i.e. the attacker must already hold a valid, scope-restricted client key. The source diff confirms the real mechanism: the video-job retry path in runVideoJob called beginSelectionSession without re-applying the requesting key's AccountScope, so a key restricted to e.g. free/web-only accounts could, on retry, fail over to and consume an out-of-scope premium/console account's quota. The 'E:P' exploit-maturity flag and the VulDB/GitHub references indicate a public proof-of-concept reference rather than confirmed weaponized code. No CISA KEV listing and no EPSS score are provided, which is consistent with a low-footprint open-source project and a quota/authorization-boundary impact rather than code execution or data theft. The vuln.today 'this_month' decision label aligns with moderate, non-emergency urgency. Impacts across C/I/A are all 'Low', reflecting unauthorized resource/quota use within an authenticated context, not full system compromise.

An attacker holding a client key deliberately restricted to a narrow account scope (e.g. free-tier/web-only) submits a video-generation request pinned to an in-scope account. When that pinned account hits a transient or forbidden failure, the retry handler re-selects a replacement account without applying the key's scope, letting the restricted key consume a premium or console/build-only account's quota. A public PoC reference exists; it is not verified as working exploit code.