CVE-2024-29201: Fit2cloud JumpServer RCE Vulnerability

CVE-2024-29201 Overview

CVE-2024-29201 is a code injection vulnerability in JumpServer, an open source bastion host and operations security audit system developed by Fit2cloud. Attackers can bypass the input validation mechanism in JumpServer's Ansible integration to execute arbitrary code within the Celery container. The Celery container runs with root privileges and holds database access, so successful exploitation enables theft of credentials and sensitive data across all managed hosts. Attackers can also manipulate the underlying database directly. The vulnerability is tracked under CWE-94: Improper Control of Generation of Code and is fixed in JumpServer v3.10.7.

Critical Impact

Authenticated attackers can achieve remote code execution as root inside the Celery container, compromising every host JumpServer manages and the JumpServer database itself.

Affected Products

• Fit2cloud JumpServer versions prior to v3.10.7
• JumpServer Celery worker container (Ansible execution path)
• All downstream hosts managed by vulnerable JumpServer instances

Discovery Timeline

• 2024-03-29 - CVE-2024-29201 published to NVD
• 2025-03-25 - Last updated in NVD database

Technical Details for CVE-2024-29201

Vulnerability Analysis

JumpServer uses Ansible to run jobs against managed hosts, executing playbooks inside a Celery worker container. The product applies input validation to user-supplied job parameters intended to block unsafe Ansible directives. CVE-2024-29201 demonstrates that this validation layer can be bypassed, allowing crafted job inputs to reach Ansible code paths that interpret them as executable instructions. The result is arbitrary command execution inside the Celery container.

The Celery container is privileged. It runs as root and holds database credentials required to coordinate jobs across the JumpServer cluster. An attacker who lands code execution inside this container inherits both properties. They can read or modify JumpServer's PostgreSQL data, extract stored SSH keys and credentials for managed assets, and pivot to every endpoint JumpServer administers. Public technical analysis is available in the SonarSource research blog.

Root Cause

The root cause is improper neutralization of user input passed into Ansible task execution [CWE-94]. The validation logic intended to restrict Ansible features did not account for alternate syntax and template constructs that Ansible still evaluates at runtime. Filtered tokens could be reintroduced through encoding or template expressions, producing code execution.

Attack Vector

Exploitation requires network access to the JumpServer web interface and a low-privileged authenticated account that can submit Ansible jobs. The attacker submits a crafted job whose parameters bypass validation but are processed by Ansible inside the Celery worker. Ansible executes the embedded payload, yielding shell access as root inside the container. No user interaction is required and the attack scope changes because compromise of the Celery container extends to managed hosts and the database.

No verified public proof-of-concept code is available. Refer to the JumpServer security advisory GHSA-pjpp-cm9x-6rwj for vendor details.

Detection Methods for CVE-2024-29201

Indicators of Compromise

• Unexpected child processes spawned by Celery worker processes inside the jms_celery container, particularly sh, bash, python, or outbound network utilities.
• Ansible job submissions containing template expressions, lookup plugins, or shell metacharacters in parameter fields normally restricted to host or asset identifiers.
• Unusual outbound connections from the JumpServer Celery container to attacker-controlled infrastructure.
• Read or write operations against the JumpServer PostgreSQL database originating from process contexts other than the standard JumpServer core service.

Detection Strategies

• Monitor process lineage inside the JumpServer Celery container and alert on shells or interpreters launched as children of celery worker processes.
• Inspect JumpServer application logs for job submissions with anomalous parameter content, including Jinja2 delimiters {{}} and Ansible lookup syntax in unexpected fields.
• Correlate authenticated low-privilege JumpServer user activity with bursts of Ansible job creation followed by outbound traffic from the Celery container.

Monitoring Recommendations

• Forward JumpServer audit logs, Celery worker logs, and container runtime logs to a centralized analytics platform for retention and query.
• Baseline normal Ansible job parameter content per user and alert on deviations that include code-like constructs.
• Track JumpServer version inventory across environments and flag any host running a release earlier than v3.10.7.

How to Mitigate CVE-2024-29201

Immediate Actions Required

• Upgrade all JumpServer deployments to v3.10.7 or later without delay, prioritizing internet-exposed and multi-tenant instances.
• Audit JumpServer user accounts and revoke job-execution permissions from accounts that do not require them.
• Rotate SSH keys, API tokens, and database credentials managed by JumpServer if the platform ran a vulnerable version with untrusted users.
• Review Celery worker container and PostgreSQL logs for signs of prior exploitation before the upgrade.

Patch Information

Fit2cloud released the fix in JumpServer v3.10.7. The vendor advisory GHSA-pjpp-cm9x-6rwj describes the patched validation logic. Operators using container deployments should pull the updated jumpserver/jms_core and jumpserver/jms_celery images that correspond to v3.10.7 or newer and redeploy the full stack.

Workarounds

• Restrict network access to the JumpServer web interface using firewall rules or a VPN, limiting reachability to trusted administrators while patching is scheduled.
• Disable or tightly scope Ansible-based job execution features for non-administrative roles until the upgrade is complete.
• Place the Celery container behind egress filtering so it cannot initiate arbitrary outbound connections to the internet.

# Upgrade JumpServer to a patched release (docker-compose deployment)
cd /opt/jumpserver-installer
./jmsctl.sh down
git fetch --tags
git checkout v3.10.7
./jmsctl.sh upgrade v3.10.7
./jmsctl.sh start

# Verify running version
./jmsctl.sh version