JumpServer: Jinja2 injection in Applet Host fields executes commands on the control node

Impact

Jinja2 expressions placed in the IP/Host or Core Service Address field are evaluated by Ansible during Applet Host deployment, giving arbitrary command execution on the JumpServer control node itself. A bastion host is the concentration point for operator access: it holds or brokers the credentials for the machines behind it and keeps the session audit trail. Code on that node therefore reaches beyond the bastion to whatever it fronts, and can tamper with the recording of what happened. The flaw requires an already-privileged administrator account, so the realistic threat is a lower-trust admin escalating to the host, or a compromised admin session turning into fleet-wide credential access rather than an external break-in.

Who can reach it

Network access to the JumpServer web interface with an authenticated administrator account holding Applet Host management and deployment permissions. High privilege is required.

What to do

Upgrade to JumpServer 4.10.17, which contains the fix; this is a service upgrade and restart of the JumpServer deployment, not a node maintenance window. Review who currently holds Applet Host management rights, and given that the flaw runs code on the node that stores connection credentials, treat any suspicion of use as a reason to rotate the assets' credentials.

References