Mage AI CVE-2026-111823

The target Mage instance must have user authentication enabled so that the OAuth session-creation path is reachable over the network. Crucially, NO valid OAuth token and NO real/registered provider are required - the attacker supplies an arbitrary token and an unknown provider string in the request body, and the server fails to reject the unknown-provider error. To impersonate an existing account, the attacker needs to know or guess a valid (preferably privileged) user email; to create a new usable account instead, the OAUTH_DEFAULT_ACCESS setting must be configured so the new user receives roles. Limiting factors: exploitation is moot on instances with no authentication layer, and newly-created users gain no privileges unless OAUTH_DEFAULT_ACCESS is set, so the highest-impact path is impersonating an already-privileged existing email.

All available signals point to a genuine high-priority flaw rather than an inflated high-CVSS score. The MITRE-supplied CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 9.8) describes an unauthenticated, low-complexity, remote authentication bypass, and the attached source-code evidence corroborates it directly: the SessionResource.create logic fails to act on an unknown/unverified OAuth provider (CWE-390) and proceeds to mint a session from attacker-controlled request-body data. The fixing PR's regression tests literally send the attack payload (email + arbitrary token + provider='invalid') and assert it is now rejected, which both confirms exploitability and publishes the exact vector. Tempering factors: no EPSS score, no CISA KEV entry, and no SSVC decision data were provided, so there is no evidence of active or widespread exploitation yet - absence of these signals is not proof of safety, only of unmeasured risk. Real-world blast radius is further bounded by the product's medium deployment footprint and the requirement that user authentication be enabled on the instance. For any internet-exposed Mage instance with auth enabled, this should be treated as an urgent patch.

An attacker reaches an internet-exposed Mage session-creation API and POSTs a JSON body containing a victim's email address, an arbitrary token value, and a non-existent OAuth provider name. Because the vulnerable code does not act on the unknown-provider error condition, it issues a valid authenticated session for that email - impersonating an existing (ideally privileged) user or creating a new one. No public weaponized exploit was identified, but the fixing PR and its test suite publicly document the exact payload.