CVE-2026-44845 in JumpServer
Summary
by MITRE • 08/17/2026
JumpServer is an open source bastion host and an operation and maintenance security audit system. Prior to 4.10.17, an authenticated administrator with Applet Host management and deployment permissions can inject Jinja2 expressions into the IP/Host field or Core Service Address field, causing Ansible to evaluate ansible_host inventory data or playbook variables during Applet Host deployment and execute arbitrary commands on the JumpServer control node. This issue is fixed in version 4.10.17.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/17/2026
JumpServer serves as a critical infrastructure component for many organizations by functioning as an open-source bastion host and operation and maintenance security audit system. It centralizes access to servers, databases, and other assets while providing comprehensive logging and auditing capabilities. However, prior to version 4.10.17, the application contained a significant server-side template injection vulnerability that allowed authenticated administrators with specific Applet Host management and deployment permissions to execute arbitrary commands on the JumpServer control node. This flaw stems from improper sanitization of user-supplied input within the IP/Host field or Core Service Address fields used during the configuration and deployment of applets, which are remote access components managed by JumpServer.
The technical root cause of this vulnerability lies in the integration between JumpServer’s web interface and its backend automation engine, Ansible. When an administrator with sufficient privileges attempts to deploy a new Applet Host or modify core service addresses, the provided values for these fields are passed directly into Jinja2 template contexts without adequate validation or escaping. Because Ansible utilizes Jinja2 for templating inventory files and playbook variables, any unsanitized input containing malicious Jinja2 expressions is evaluated by the engine during the deployment process. This evaluation allows an attacker to inject code that leverages Ansible’s execution capabilities to run arbitrary system commands on the underlying JumpServer host with the privileges of the service account running the automation tasks.
From a threat modeling perspective, this vulnerability represents a severe risk due to its potential for full server compromise. An authenticated administrator can exploit this flaw to achieve remote code execution (RCE) on the control node. This aligns closely with CWE-94, which describes Improper Control of Generation of Code or Script commonly known as injection attacks. Furthermore, in terms of offensive security frameworks such as MITRE ATT&CK, this vulnerability facilitates techniques related to Command and Scripting Interpreter abuse, specifically allowing an attacker to execute commands via a remote service like Ansible. The impact extends beyond mere command execution; it can lead to data exfiltration, lateral movement within the network by using JumpServer’s access credentials, or complete destruction of system integrity depending on the actions taken post-exploitation.
The operational impact is particularly acute because the vulnerability requires only authenticated administrative access with specific deployment permissions rather than full root-level control initially. This lowers the barrier for exploitation significantly compared to unauthenticated attacks. Once an attacker gains a foothold via this injection, they can manipulate the Ansible inventory data or playbook variables to execute payloads that compromise not just the JumpServer instance but potentially any systems managed through it if those credentials are reused or escalated. The ability to inject code into core service address fields also suggests potential for disrupting critical audit and access control functions, thereby undermining the primary security purpose of the bastion host itself.
To mitigate this vulnerability, organizations running versions of JumpServer prior to 4.10.17 must upgrade immediately to version 4.10.17 or later where these input validation issues have been addressed by the development team. In addition to patching, it is advisable to review access controls and ensure that Applet Host management permissions are granted only to trusted personnel with a strict need-to-know basis. Implementing principle of least privilege can reduce the attack surface for such internal threats. Furthermore, organizations should consider implementing network segmentation to isolate JumpServer control nodes from direct internet exposure and monitor logs for unusual Ansible execution patterns or unexpected outbound connections that might indicate exploitation attempts. Regular security audits and penetration testing focusing on template injection vectors are recommended to ensure ongoing resilience against similar flaws in automation-driven infrastructure management tools.