CVE-2024-29202: Fit2cloud JumpServer RCE Vulnerability

CVE-2024-29202 Overview

CVE-2024-29202 is a Jinja2 template injection vulnerability in JumpServer, an open source bastion host and operations security audit system maintained by Fit2cloud. Attackers can inject malicious Jinja2 templates into JumpServer's Ansible integration to execute arbitrary code inside the Celery container. The Celery container runs as root and holds database credentials, so successful exploitation lets attackers steal credentials for every managed host or tamper with the database directly. The flaw is tracked under CWE-94: Improper Control of Generation of Code and is fixed in JumpServer v3.10.7.

Critical Impact

An authenticated low-privilege attacker can achieve root-level remote code execution inside the Celery container, exposing credentials for all managed assets and granting full database access.

Affected Products

• Fit2cloud JumpServer versions prior to v3.10.7
• JumpServer Celery container (Ansible task execution component)
• Deployments exposing the JumpServer Ansible playbook or task interface to authenticated users

Discovery Timeline

• 2024-03-29 - CVE-2024-29202 published to the National Vulnerability Database (NVD)
• 2025-03-25 - Last updated in NVD database

Technical Details for CVE-2024-29202

Vulnerability Analysis

JumpServer uses Ansible to run playbooks against managed hosts for tasks such as account rotation and asset operations. Ansible processes user-controllable fields through the Jinja2 templating engine before dispatching tasks. JumpServer fails to sanitize attacker-controlled inputs that flow into Jinja2 expressions, allowing template injection during playbook rendering.

When the crafted template renders inside the Celery worker, Jinja2 evaluates Python expressions reachable through object introspection. The attacker gains arbitrary command execution in the Celery container. Because Celery executes as root and is configured with direct database connectivity, the impact extends to credential theft for every managed asset and full read/write access to the JumpServer database.

Root Cause

The root cause is improper input validation on fields consumed by Ansible's Jinja2 renderer ([CWE-94]). JumpServer treats authenticated user input as trusted before it reaches the templating layer, so curly-brace expressions are evaluated rather than escaped.

Attack Vector

An authenticated attacker with low privileges submits a payload containing Jinja2 syntax into a JumpServer field consumed by an Ansible task. When the task executes, Celery renders the template and invokes Python primitives reachable from the Jinja2 sandbox, producing command execution as root inside the Celery container. Technical analysis is documented in the JumpServer GitHub Security Advisory GHSA-2vvr-vmvx-73ch and the SonarSource research blog.

// No verified public exploit code is referenced in the advisory.
// Refer to the SonarSource analysis for sanitized technical detail.

Detection Methods for CVE-2024-29202

Indicators of Compromise

• Unexpected child processes spawned by the Celery worker inside the JumpServer Celery container, especially shells such as sh, bash, or interpreters like python.
• Ansible task logs containing Jinja2 control sequences such as {{, }}, __class__, __mro__, or subprocess within user-supplied fields.
• Outbound network connections initiated by the Celery container to attacker-controlled hosts.
• Unauthorized reads or writes against the JumpServer database, including dumps of the assets_account or credential tables.

Detection Strategies

• Inspect JumpServer application logs and Ansible job output for template syntax in fields that should contain plain identifiers.
• Monitor container runtime telemetry for process lineage anomalies under the Celery worker, where only Python and Ansible binaries are expected.
• Alert on JumpServer database queries originating from unexpected sessions or returning bulk credential rows.

Monitoring Recommendations

• Forward JumpServer, Celery, and container runtime logs to a centralized analytics platform for correlation across job submission, template rendering, and process execution.
• Baseline the Celery container's normal process tree and file system writes, then alert on deviations.
• Enable audit logging on the JumpServer database and review for queries that touch credential or asset tables outside normal application flows.

How to Mitigate CVE-2024-29202

Immediate Actions Required

• Upgrade all JumpServer deployments to v3.10.7 or later, which fixes the Jinja2 template injection path.
• Rotate every credential stored or brokered by JumpServer, including SSH keys, database passwords, and cloud secrets, assuming exposure.
• Restrict network access to the JumpServer management interface so only trusted administrators can authenticate.
• Review Ansible job history and Celery container logs for evidence of template-injection payloads before the patch was applied.

Patch Information

Fit2cloud released the fix in JumpServer v3.10.7. Patch details and upgrade guidance are published in the JumpServer GitHub Security Advisory GHSA-2vvr-vmvx-73ch. Apply the upgrade through the standard JumpServer deployment process and verify the running version after restart.

Workarounds

• If immediate upgrade is not possible, limit JumpServer accounts permitted to create or modify Ansible-driven tasks to a small set of trusted administrators.
• Place JumpServer behind a network policy that blocks outbound traffic from the Celery container to untrusted destinations.
• Run the Celery container with the least privileges feasible and isolate its database role so it cannot read unrelated credential tables.

# Verify the installed JumpServer version after patching
docker exec jms_core bash -c "cat /opt/jumpserver/apps/jumpserver/const.py | grep VERSION"

# Confirm the Celery container image tag matches v3.10.7 or later
docker inspect jms_celery --format '{{.Config.Image}}'