Jet Admin EUVD-2026-63997

Exploitation requires that the target organization has configured a custom domain in Jet Admin, and the OAuth-credential-theft consequence specifically requires that the victim tenant uses an OAuth provider for authentication - a tenant with no custom domain or no OAuth configured is not exposed to the full impact. The attacker must be able to create their own Jet Admin app/workspace and reach the domain-binding and authentication-configuration functions, which per the CVSS vector requires no privileges on the victim tenant and no user interaction (PR:N/UI:N/AV:N). The principal limiting factor is therefore configuration-dependence on the victim side (custom domain plus OAuth), not attacker-side prerequisites.

The signals point to a genuinely high-priority, low-friction issue. The CVSS 4.0 base vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes fully remote, low-complexity exploitation with no authentication and no user interaction, and the subsequent-system confidentiality impact (SC:H) plus high availability impact (VA:H) reflect that the attack reaches beyond the attacker's own tenant into the victim's environment - consistent with a scope-changing authorization bypass. Working against it, this is a logic/authorization flaw specific to Jet Admin's multi-tenant domain model rather than a memory-corruption bug, so it does not lend itself to indiscriminate mass scanning; realistic abuse likely targets known-valuable tenants. EPSS is not provided in the input, there is no KEV listing, and no POC is referenced, so the 'no public exploit identified at time of analysis' status should be weighed against the fact that the described steps are conceptually simple and require no special tooling. Even a mid-sized operator with a modest IT team should treat this as urgent given the OAuth secret exposure, because leaked client credentials enable follow-on impersonation of the victim's login flow well after any domain change is reverted.

An attacker registers a Jet Admin workspace, builds a malicious app, and binds it to a target organization's custom domain, then edits that domain's authentication configuration to reroute incoming users to attacker-controlled logic. End users visiting the legitimate domain are served the attacker's app, and the attacker's workspace is automatically populated with the victim's OAuth Client ID and Client Secret; no POC is publicly referenced, but the described steps require only standard platform features.