JumpServer EUVD-2026-98923

Requires an authenticated JumpServer user who already holds permission to create or execute the affected automation tasks (operator-level privilege, hence PR:H). The attacker must supply content - such as an account or connection-token username/input field - containing an Ansible lookup template expression that is subsequently processed by the Ansible-based automation rendering engine. Exploitation is LIMITED to the privileges of the automation process and cannot reach unrelated JumpServer assets; it does NOT grant unauthenticated access. Affected deployments are any JumpServer prior to 4.10.17-lts; the fix adds forbidden-character validation (SECURITY_ACCOUNT_USERNAME_FORBIDDEN_CHARS) on username fields, so environments on or after 4.10.17-lts, or those not exposing automation-task permissions to untrusted users, are not exploitable.

This is a moderate, authenticated-only code/template injection (CWE-94) in JumpServer's Ansible-based automation rendering, scored CVSS 6.0. The provided vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L) is internally consistent with the description: network-reachable via the web interface, low complexity, but requiring PR:H - a user already holding permission to create or execute automation tasks, i.e. a trusted/privileged operator, not an anonymous attacker. The description explicitly rules out unauthenticated access and access to unrelated assets, so scope is Unchanged and the blast radius is the automation process context. Confidentiality is High (file, env, and password lookups can disclose secrets) while integrity and availability are only Low (limited command execution). No EPSS score, KEV listing, or POC was provided in the input: by the precision rules this is 'no public exploit identified at time of analysis.' The source patch cross-references the risk well - PR #16886 introduces validate_account_username/forbidden-character filtering on account and connection-token username fields, indicating the practical injection channel is attacker-controlled username/input content that is later rendered as an Ansible/Jinja template expression. Net assessment: a real but privilege-gated insider/abuse-of-permission issue, not a mass-exploitable internet-facing RCE; prioritize because JumpServer is a bastion host handling credentials (secret-disclosure impact is high), but realistic exploitation depends on already granting automation permissions. The 'RCE' tag overstates impact - the description and CVSS cap this at limited command execution, not full reliable RCE.

A JumpServer user who has been granted permission to create or execute automation tasks crafts an account username or automation field containing an Ansible lookup template expression (e.g. file, pipe, env, or password lookup). When the Ansible-based automation renders the content, the expression is evaluated within the automation execution context, disclosing local files or environment secrets and permitting limited command execution as the automation process. No public exploit code was identified in the provided data, though the fixing commit and PR diff reveal the vulnerable username/input rendering path.