# Download/Attachment Tool Directed to Write Outside Its Sandbox via Absolute-Path Filename - **Severity:** High - **Signature ID:** `bddc178c-c740-4238-bfdc-4b546b75be4d` - **CVEs:** CVE-2026-10277, CVE-2026-57571 - **MITRE ATLAS:** AML.T0053 (AI Agent Tool Invocation) - **OWASP:** ASI02 (Tool Misuse and Exploitation), LLM08 (Vector and Embedding Weaknesses) ## Summary Some AI agent tools that download files or save email attachments trust the filename given by the remote server or website instead of checking it. An attacker can supply a full file path instead of a plain filename, making the tool write the file wherever they choose on disk. ## How the attack works A tool fetches a file over HTTP or saves an attachment, and reads the suggested filename from the server's Content-Disposition header, a webpage's suggested filename, or a save-path argument the caller provides. Normally this should just be a plain filename like 'invoice.pdf'. An attacker controlling the response (or injecting instructions the agent follows) instead supplies an absolute path or a Windows drive path, or points a save_path/attachment_path argument straight at a system startup or scheduling directory. The tool joins this value onto its save location without checking for absolute paths, so the write lands outside the intended downloads folder — for example into a cron directory, a systemd unit folder, a LaunchAgents folder, or over sensitive files like SSH keys or shell configs. ## Why it matters An attacker can plant a file that runs automatically at login or on a schedule, or overwrite security-relevant files, giving them persistent code execution on the host without needing a separate traversal exploit. ## What you can do - Reject any Content-Disposition filename or suggested_filename that is an absolute path, contains a drive letter, or contains a path separator — only accept bare filenames. - Resolve save/attachment path arguments and verify the result stays inside the intended downloads directory before writing. - Block writes to known persistence locations (cron directories, systemd unit paths, LaunchAgents, autostart folders) from download/attachment tools entirely. - Run download and attachment tools with a filesystem sandbox or restricted write permissions so even a bad path can't reach system directories. ## Known benign look-alikes - Content-Disposition filenames that are plain basenames with no path separator (the overwhelming majority of legitimate responses) - A save-path argument pointed at the tool's own configured downloads/attachments directory, even if that directory happens to be an absolute path under the user's home folder (Downloads, Documents, a project workspace) — this rule only fires on the specific system-persistence directories listed - A Content-Disposition or suggested_filename absolute/drive path that resolves into an ordinary Downloads/Documents/Desktop/Pictures/Music/Videos-style user folder (e.g. C:\Users\\Downloads\invoice.pdf) — v2 excludes these via the same destination-allowlist logic condition 2 uses, since this is the tool's normal download target, not a sandbox escape ## References - https://agentthreatrule.org/en/rules/ATR-2026-02142 - https://github.com/unclecode/crawl4ai/security/advisories/GHSA-2jq4-q6vv-4cp3 - https://github.com/j3k0/mcp-google-workspace/commit/89c091ecf8b9f9c7291d1af0b1966e271f86551c - https://nvd.nist.gov/vuln/detail/CVE-2026-57571 - https://nvd.nist.gov/vuln/detail/CVE-2026-10277 --- Source: https://www.netzilo.com/threats/atr-download-attachment-tool-directed-to-write-outside-its-sandb