CVE-2026-75914: Improper Link Resolution and Path Traversal in CodeWhale image_analyze Tool

CodeWhale is an open-source, terminal-based autonomous coding assistant implemented in Rust. To assist developers with visual assets, CodeWhale integrates a vision subsystem featuring the image_analyze tool. This tool exposes an attack surface by accepting directory path parameters from the agent's current workspace, reading the specified target files, and transmitting them to a configured vision model endpoint for text extraction or description.

To prevent the autonomous agent from accessing host resources outside its intended scope, the application establishes a logical workspace boundary. All tool execution is intended to be confined within this root workspace directory. However, in versions prior to 0.8.64, the path validation implementation relied exclusively on abstract string parsing rather than physical filesystem-backed validation, which completely bypassed this confinement boundary.

This vulnerability is highly relevant in autonomous agent workflows where the agent operates on untrusted codebases or repositories cloned from the internet. An attacker can structure a malicious repository to include nested symbolic links. When CodeWhale executes tools over this directory, the security boundaries fail, allowing the agent to read arbitrary host files, including configuration files, credentials, and local system parameters.

The underlying vulnerability is an instance of CWE-59 (Improper Link Resolution) leading to CWE-22 (Path Traversal). The core defect resides in the path validation logic of the image_analyze tool located in crates/tui/src/vision/tools.rs. Before opening a file, the application validates the candidate path parameter (image_path) using the standard library's logical path parsing API.

Specifically, the validator scans the path's components to check if any of them match Component::Prefix, Component::RootDir, or Component::ParentDir (such as ..). If these components are absent, the application assumes the path is a safe relative path and joins it to the workspace root directory. This model is fundamentally flawed because it operates entirely on the lexical structure of the path string and does not inspect the underlying physical filesystem objects.

Under standard operating systems, a symbolic link (symlink) is a filesystem object that references another file or directory path. A symlink's directory entry contains only a standard, benign name (for example, leak.png). Because the name contains no relative traversal tokens, it passes the lexical verification check. When the application subsequently invokes filesystem operations such as std::fs::read on the resolved workspace path, the operating system kernel transparently follows the symlink to its physical destination outside the workspace, resulting in an unauthorized out-of-bounds file read.

In the vulnerable implementation, the application checks path safety lexically and immediately appends the input to the workspace path without resolving the physical destination. This can be seen in the following code block:

// Vulnerable Implementation (Before 0.8.64)
let image_path_buf = Path::new(image_path);
if image_path_buf.components().any(|c| {
    matches!(
        c,
        Component::Prefix(_) | Component::RootDir | Component::ParentDir
    )
}) {
    return Err(ToolError::execution_failed(
        "image_path must be a relative path within the workspace and cannot escape it.",
    ));
}
let resolved_path = context.workspace.join(image_path_buf);
let (image_data, mime_type) = Self::read_image_file(&resolved_path).await?;

The patch introduced in version 0.8.64 resolves this defect by establishing a safe path resolver function, resolve_image_path. This function canonicalizes both the workspace root and the candidate path before performing a safety check. Canonicalization resolves all symbolic links, relative segments, and redundant separators, converting the path into its unique absolute physical representation on the filesystem.

// Patched Implementation in 0.8.64
fn resolve_image_path(workspace: &Path, image_path: &str) -> Result<PathBuf, ToolError> {
    let image_path_buf = Path::new(image_path);
    if image_path_buf.components().any(|c| {
        matches!(
            c,
            Component::Prefix(_) | Component::RootDir | Component::ParentDir
        )
    }) {
        return Err(ToolError::execution_failed(
            "image_path must be a relative path within the workspace and cannot escape it.",
        ));
    }
 
    // Establish a verified canonicalized baseline for the workspace root
    let workspace = workspace.canonicalize().map_err(|e| {
        ToolError::execution_failed(format!("Failed to resolve workspace path: {e}"))
    })?;
    
    // Construct the absolute candidate path and canonicalize it to resolve symlinks
    let candidate = workspace.join(image_path_buf);
    let resolved = candidate.canonicalize().map_err(|e| {
        ToolError::execution_failed(format!("Failed to resolve image file: {e}"))
    })?;
    
    // Verify the physical target path resides strictly inside the canonical workspace prefix
    if !resolved.starts_with(&workspace) {
        return Err(ToolError::execution_failed(
            "image_path must resolve within the workspace and cannot escape it.",
        ));
    }
    Ok(resolved)
}

By comparing the canonicalized representation of the target path with the canonicalized workspace root using resolved.starts_with(&workspace), the application ensures that any attempt to follow a symlink that points to an external resource is detected and blocked before any read operations occur.

To exploit this vulnerability, an attacker must have the ability to supply or modify files within the directory where the CodeWhale agent is executing. This is typically achieved when the user clones an untrusted public repository or opens a project workspace containing malicious structures configured by an external threat actor.

The attacker first creates a symbolic link inside the project directory, giving it a filename that resembles a standard image file but targeting a sensitive resource on the host operating system. The following shell commands demonstrate this step on a Unix-like system:

# Establish a symbolic link pointing to the host's primary user account database
ln -s /etc/passwd ./leak.png

Once the symlink is placed, the attacker triggers the agent to run the image_analyze tool on the crafted path. The tool validates `