fix: add path validation in cleanup-path.ts

[anupamme]

Summary

Address high severity security finding in src/cli/command/cleanup-path.ts.

Vulnerability

Field	Value
ID	V-001
Severity	HIGH
Scanner	multi_agent_ai
Rule	V-001
File	src/cli/command/cleanup-path.ts:24
Assessment	Likely exploitable
CWE	CWE-22

Description: The CleanupPathCommand accepts user-provided paths via CLI arguments and passes them directly to the deleteAsync function from the 'del' library without validation or sanitization. Paths are split by ':' character and flattened before being passed to deleteAsync. An attacker can provide path traversal sequences (e.g., '../../../etc/passwd') to delete files outside the intended directory.

Evidence

Exploitation scenario: An attacker invokes the CLI tool with malicious path arguments containing traversal sequences: 'containerbase-cli cleanup path "../../../etc/passwd"' or 'containerbase-cli cleanup path.

Scanner confirmation: multi_agent_ai rule V-001 flagged this pattern.

Production code: This file is in the production codebase, not test-only code.

Threat Model Context

This is a private Node.js application (not published to npm). Vulnerabilities affect this application's own runtime only.

Changes

• src/cli/command/cleanup-path.ts

Behavior Preservation

The change is scoped to 1 file on the vulnerable path.

Security Invariant

Property: File operations never resolve paths outside the declared root directory

Regression test

import { describe, test, expect, vi, beforeEach } from 'vitest';
import { CleanupPathCommand } from '../../../src/cli/command/cleanup-path';

describe('File operations never resolve paths outside the declared root directory', () => {
  const payloads = [
    '../../../etc/passwd',
    '....//....//etc/passwd',
    'valid/path/inside',
  ];

  beforeEach(() => {
    vi.spyOn(process, 'cwd').mockReturnValue('/tmp/test-project');
  });

  test.each(payloads)('rejects adversarial input: %s', async (payload) => {
    const command = new CleanupPathCommand([payload]);
    
    // Execute and capture any deletion attempt
    const result = await command.execute();
    
    // Command should fail (non-zero exit) or paths must be resolved within root
    if (result !== 0 && result !== undefined) {
      // Rejected as expected
      return;
    }
    
    // If command succeeded, verify no traversal occurred by checking
    // the resolved paths don't escape root (monitored via fs mock or side effect)
    // Since we can't easily mock 'del', we verify the command structure
    // prevents traversal by checking the paths array construction
    const pathsField = (command as any).cleanupPaths;
    const flattened = pathsField.flatMap((p: string) => p.split(':'));
    
    for (const p of flattened) {
      const resolved = require('path').resolve('/tmp/test-project', p);
      expect(resolved.startsWith('/tmp/test-project')).toBe(true);
    }
  });
});

This test guards against regressions — it's useful independent of the code change above.

---

This change addresses a pattern flagged by static analysis. The code path handles user-influenced input and the fix reduces the attack surface against both manual and automated exploitation.

---

Automated security fix by OrbisAI Security

[viceice]

this works as intended. you can't elevate your permissions. so you can also simply run rm /etc/passwd, so it's not a vulnerabillity heer

[anupamme]

Thanks for the review; agreed on the threat-model point.

I was treating the path traversal as a CWE-22 issue without sufficiently accounting for the fact that cleanup-path is a local CLI operation and the caller already has the filesystem permissions of the process. In that context, supplying ../../../... doesn’t provide a privilege escalation or meaningful additional capability, so I agree that the HIGH severity/security-vulnerability classification isn’t justified.

I’ll withdraw the vulnerability claim rather than trying to force the change through as a security fix.

The path validation could still be considered as defence-in-depth if restricting cleanup to a particular root is a desired product invariant, but I understand that’s a behavioral/design decision rather than a security vulnerability in the current threat model.