Attachment/Upload Tool Argument Reads Sensitive System File or Traverses Outside Workspace
Some AI agent tools that upload files to services like Confluence or Jira take a file path and send whatever is at that path, without checking that the path is a normal, expected file. An attacker can point the upload at sensitive system files instead, and the tool will happily read and exfiltrate them disguised as a routine attachment.
How the attack works
An agent has a tool that attaches files to tickets, pages, or issues by taking a file path argument and opening that path on disk. Instead of an ordinary document path, the argument is set to something like /etc/passwd, /etc/shadow, /proc/self/environ, a file under ~/.ssh, or a path using multiple ../ segments to escape the intended workspace. The tool opens whatever path it's given and uploads the resulting bytes to an external destination such as Confluence or Jira as a normal-looking attachment. Because the read happens inside an upload API call rather than a direct file-read call, it does not look like a file-read to anyone monitoring the caller, and this can also be triggered indirectly through prompt injection with no direct access to the agent's tools.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 2d7b7587-7ea7-4267-871c-a06de10a319e
- Severity
- High
- CVEs
- CVE-2026-58499
Why it matters
Sensitive data such as SSH private keys, password files, or process environment variables (which often contain secrets) can be exfiltrated to an external system disguised as a routine file attachment, bypassing normal file-read monitoring.
What you can do
- →Validate and canonicalize file path arguments in any upload/attach tool before opening the file; reject absolute paths outside the intended workspace and reject paths containing traversal sequences.
- →Restrict the file system permissions of the process running the upload tool so it cannot read /etc/passwd, /etc/shadow, /proc/self/environ, or SSH key directories.
- →Log and review upload/attach tool calls whose file path argument targets system directories or contains repeated ../ segments.
- →Treat this as one exfiltration channel among several; also check tools that accept file paths for read, download, or export operations for the same missing validation.
Known benign look-alikes
- An upload/attach tool call referencing an ordinary user-owned file by absolute or relative path with no traversal and no system-sensitive target (e.g. file_path=/home/user/report.pdf, file_path=./invoice.pdf)
- A single ../ reference to a sibling directory in the same project (e.g. attachments=../shared/logo.png) -- only 2+ levels of traversal fire, since escaping one sibling directory is a normal same-project reference and not evidence of reaching a system path
- Documentation or tutorials that show the vulnerable code pattern as an example without an actual tool-call argument being set