High 2026-07-11

Download/Attachment Tool Directed to Write Outside Its Sandbox via Absolute-Path Filename

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.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID: bddc178c-c740-4238-bfdc-4b546b75be4d
Severity: High
CVEs: CVE-2026-10277 CVE-2026-57571

Classification

AML.T0053 · AI Agent Tool Invocation ASI02 · Tool Misuse and Exploitation LLM08 · Vector and Embedding Weaknesses

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\<name>\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