# Attachment/Upload Tool Argument Reads Sensitive System File or Traverses Outside Workspace

- **Severity:** High
- **Signature ID:** `2d7b7587-7ea7-4267-871c-a06de10a319e`
- **CVEs:** CVE-2026-58499
- **MITRE ATLAS:** AML.T0057 (LLM Data Leakage)
- **OWASP:** ASI01 (Agent Authorization and Control Hijacking), LLM02 (Sensitive Information Disclosure)

## Summary

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.

## 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

## References

- https://agentthreatrule.org/en/rules/ATR-2026-02250
- https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-g5r6-gv6m-f5jv
- https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f
- https://nvd.nist.gov/vuln/detail/CVE-2026-58499

---
Source: https://www.netzilo.com/threats/atr-attachment-upload-tool-argument-reads-sensitive-system-file