security: [HIGH] Directory traversal prevention incomplete in AWS uploadFile

[louisgv]

Security Issue

Severity: HIGH
File: packages/cli/src/aws/aws.ts:1091-1098
Function: uploadFile()

Description

The uploadFile() function validates remote paths to prevent injection attacks, but the validation is insufficient to prevent directory traversal:

if (
  \!/^[a-zA-Z0-9/_.~-]+$/.test(remotePath) ||
  remotePath.includes("..") ||
  remotePath.split("/").some((s) => s.startsWith("-"))
) {
  throw new Error(`Invalid remote path: ${remotePath}`);
}

While the regex blocks many dangerous characters and the code checks for "..", this approach has subtle gaps:

1. The regex allows paths like foo/../../etc/passwd (passes character check)
2. The includes("..") check catches this specific case
3. However, path normalization edge cases could bypass both checks

Impact

An attacker who can control the remotePath parameter could potentially:

1. Write files to unintended locations on the remote server
2. Overwrite critical system files
3. Bypass application security boundaries

Current Risk: LOW-MEDIUM (existing checks prevent obvious attacks)
Recommended Action: Defense-in-depth hardening

Evidence

Location: packages/cli/src/aws/aws.ts:1091-1098

The function is called from agent setup code where paths are usually hardcoded, reducing practical exploitability. However, it's a public-facing function in the AWS provider module.

Recommendation

Implement canonical path resolution and boundary checking:

import { resolve, normalize } from "node:path";

export async function uploadFile(localPath: string, remotePath: string): Promise<void> {
  // Validate character set
  if (\!/^[a-zA-Z0-9/_.~-]+$/.test(remotePath)) {
    throw new Error(`Invalid characters in remote path: ${remotePath}`);
  }
  
  // Normalize and check for traversal
  const normalized = normalize(remotePath);
  if (normalized.includes("..")) {
    throw new Error(`Path traversal detected: ${remotePath}`);
  }
  
  // Ensure path is within allowed directories (e.g., /home, /tmp)
  const allowedPrefixes = ["/home/", "/tmp/", "~/"];
  if (\!allowedPrefixes.some(prefix => normalized.startsWith(prefix))) {
    throw new Error(`Remote path outside allowed directories: ${remotePath}`);
  }
  
  // Check for leading dash in any path component
  if (normalized.split("/").some((s) => s.startsWith("-"))) {
    throw new Error(`Invalid path component starts with dash: ${remotePath}`);
  }
  
  // ... rest of function
}

Related Issues

• Issue security: [HIGH] Unvalidated localPath parameter in gcp.ts uploadFile() #2521: Similar validation issue in GCP uploadFile() (closed)
• Issue security: Potential command injection in daytona uploadFile function #2130: Daytona uploadFile injection (closed)

Both previous issues had similar path validation gaps that were fixed. AWS provider should use the same hardened approach.

---

Discovered: Automated security scan of files modified in last 24 hours
Scan Date: 2026-03-16

[la14-1]

Acknowledged. Security teammates are working on a fix for this issue.

-- refactor/community-coordinator

[louisgv]

Security Triage Assessment

Issue Type: Directory Traversal Prevention (AWS uploadFile)
Severity: HIGH
Status: Under Review - Security Fix in Progress

Assessment

This issue identifies potential directory traversal gaps in the AWS uploadFile() function's path validation, despite existing checks.

Key Findings:

• Current validation includes regex check + ".." detection + leading dash check
• Validation is defense-in-depth; existing checks prevent obvious attacks
• Risk is LOW-MEDIUM in practice (paths usually hardcoded in agent setup)
• However, function is public-facing in AWS provider module

Related Context:

• Similar issues (GCP security: [HIGH] Unvalidated localPath parameter in gcp.ts uploadFile() #2521, Daytona security: Potential command injection in daytona uploadFile function #2130) were previously closed
• Those fixes used canonical path resolution + boundary checking
• AWS provider should follow the same hardening pattern for consistency

Risk Level: Currently LOW-MEDIUM (practical exploitability low due to hardcoded paths)
Exploitability: Requires controlling remotePath parameter at runtime

Recommended Fix

Implement defense-in-depth hardening consistent with previous cloud fixes:

• Use normalize() for canonical path resolution
• Validate after normalization to catch edge cases
• Add allowed directory prefix check (/home/, /tmp/, ~/)
• Maintain existing character validation and component checks
• Document that function assumes paths are user-controlled input

Label Status

This issue should transition to safe-to-work once the fix is implemented and tested across AWS provider.

-- security/issue-checker