CVE-2025-14306: Robocode Path Traversal Vulnerability

CVE-2025-14306 Overview

A directory traversal vulnerability exists in the CacheCleaner component of Robocode version 1.9.3.6. The recursivelyDelete method fails to properly sanitize file paths, allowing attackers to traverse directories and delete arbitrary files on the system. This vulnerability can be exploited by submitting specially crafted inputs that manipulate the file path, leading to potential unauthorized file deletions.

Critical Impact

Remote attackers can exploit this directory traversal flaw to delete arbitrary files on the target system without authentication, potentially causing data loss, service disruption, or enabling further attacks by removing security controls or critical system files.

Affected Products

• Robocode version 1.9.3.6
• Robocode CacheCleaner component
• Systems running the affected Robocode version with exposed file operations

Discovery Timeline

• 2025-12-09 - CVE CVE-2025-14306 published to NVD
• 2026-01-28 - Last updated in NVD database

Technical Details for CVE-2025-14306

Vulnerability Analysis

This vulnerability is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), commonly known as a directory traversal or path traversal vulnerability. The flaw exists within the recursivelyDelete method in the CacheCleaner.java file located at robocode.core/src/main/java/net/sf/robocode/cachecleaner/.

The vulnerable implementation accepts a file path without performing any canonical path validation or base directory boundary checks. An attacker can supply a malicious path containing directory traversal sequences such as ../ to escape the intended cache directory and target arbitrary files anywhere on the file system accessible to the application's execution context.

The attack is network-accessible and requires no authentication or user interaction, making it highly exploitable. Successful exploitation results in complete compromise of confidentiality, integrity, and availability of both the local system and potentially connected systems, as attackers can delete critical files including configuration files, databases, logs, or security mechanisms.

Root Cause

The root cause of this vulnerability is the absence of canonical path validation in the recursivelyDelete method. The original implementation directly operates on the provided File object without verifying that the target path remains within an authorized base directory. This allows specially crafted input containing path traversal sequences to bypass intended directory restrictions.

Attack Vector

The vulnerability is exploitable over the network with low attack complexity. An attacker can craft malicious input containing directory traversal sequences (e.g., ../../etc/important_file) that are passed to the recursivelyDelete method. Because the method recursively processes files without boundary validation, it will follow the traversal sequences and delete files outside the intended cache directory.

// Vulnerable code (before patch)
private static void recursivelyDelete(File file) throws IOException {
    if (file.exists()) {
        if (file.isDirectory()) {
            final File[] files = file.listFiles();

            for (File f : files) {
                recursivelyDelete(f);
            }
        }
        if (!file.delete()) {
            throw new IOException("Failed deleting file: " + file.getPath());
        }
    }
}

// Patched code (after fix)
private static void recursivelyDelete(File file, File base) throws IOException {
    if (!file.exists()) {
        return;
    }
    
    // Security check to prevent directory traversal attacks
    if (!(file.getCanonicalFile().toPath().startsWith(base.getCanonicalFile().toPath()))) {
        throw new IOException("Security violation: Attempting to delete a file outside the allowed base directory: "
                + file.getCanonicalPath());
    }

    if (file.isDirectory()) {
        final File[] files = file.listFiles();
        // ... continues with secure deletion

Source: GitHub Commit Details

Detection Methods for CVE-2025-14306

Indicators of Compromise

• Unexpected file deletions in system directories outside the Robocode cache folder
• Log entries showing access to files containing path traversal sequences (../)
• File system audit events indicating deletion of files by the Robocode process in unauthorized locations
• Anomalous behavior in Robocode's CacheCleaner component including IOException errors referencing unexpected paths

Detection Strategies

• Monitor file system operations from Robocode processes for access patterns outside expected directories
• Implement application-level logging to capture all paths submitted to cache cleaning functions
• Deploy file integrity monitoring (FIM) on critical system directories to detect unauthorized deletions
• Review web application firewall (WAF) logs for requests containing path traversal patterns targeting Robocode endpoints

Monitoring Recommendations

• Enable detailed audit logging for file system operations on systems running Robocode
• Configure alerting for deletion operations that span multiple directory levels from the cache directory
• Implement real-time monitoring of the CacheCleaner component's file operations
• Review logs for IOException entries containing "Security violation" messages after patching (indicates blocked exploitation attempts)

How to Mitigate CVE-2025-14306

Immediate Actions Required

• Upgrade Robocode to a version containing the security patch (commit 26b6ba8ed5b2a11a646ce2d5da8d42cd53574b1f)
• Restrict file system permissions for the Robocode application to minimize potential impact
• Implement network segmentation to limit exposure of systems running vulnerable Robocode versions
• Audit recent file system activity for signs of exploitation

Patch Information

The vulnerability has been addressed in the official Robocode repository. The fix introduces a base directory parameter and implements canonical path validation to ensure that deletion operations cannot escape the authorized directory. The patched recursivelyDelete method now accepts both the target file and a base directory parameter, comparing the canonical paths to verify the target remains within bounds before proceeding with deletion.

Review the GitHub Pull Request #67 for the complete fix details and apply the patch by updating to the latest Robocode release or applying commit 26b6ba8ed5b2a11a646ce2d5da8d42cd53574b1f.

Workarounds

• Restrict network access to systems running vulnerable Robocode versions until patching is possible
• Run Robocode with a dedicated low-privilege user account with minimal file system access
• Implement additional access controls at the file system level to protect critical directories
• Consider containerizing Robocode deployments to limit file system access scope

# Configuration example - Restrict Robocode process file permissions
# Create dedicated user with limited access
sudo useradd -r -s /sbin/nologin robocode_user

# Set restrictive permissions on Robocode installation
sudo chown -R robocode_user:robocode_user /opt/robocode
sudo chmod -R 750 /opt/robocode

# Use read-only mount for sensitive system directories when running Robocode in containers
# docker run --read-only -v /path/to/cache:/cache:rw robocode:patched