Summary
A path traversal vulnerability in the get_resource tool of Amazon awslabs.aws-transform-mcp-server may allow files to be written outside the intended working directory. The issue becomes risky when a context-dependent actor can influence the savePath parameter and invoke the tool.
Affected context
The vulnerability affects versions 0.1.0 through 0.1.4 of the Amazon awslabs.aws-transform-mcp-server when the get_resource tool processes a caller-controlled savePath. Deployments are exposed when the tool can be reached by an actor who can supply path values without effective confinement to the designated working directory.
Exploit preconditions
- Attack surface: The
get_resourcetool and its file-saving functionality - Required access: Ability to invoke the tool and influence the
savePathparameter - Trigger point: Path resolution or file creation based on the supplied save location
- Why exploitation is possible: Insufficient pathname restriction may allow a path to escape the intended directory boundary
Why this happens
The underlying flaw is inadequate validation and containment of a user-influenced filesystem path. When an application accepts a path and does not reliably normalize it, verify its resolved location, and enforce the permitted directory boundary, traversal sequences or other path variations may reference locations outside the intended directory. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory.
Potential impact
- Arbitrary files may be created or overwritten outside the intended working directory
- Application configuration or operational data could be modified
- Malicious content could be placed where another process later consumes it
- Integrity of the host or connected development workflow could be reduced
- Further compromise may be possible if writable locations influence execution or privileged services
General mitigation guidance
Mitigation generally focuses on enforcing filesystem boundaries independently of caller-controlled path values.
Common defensive patterns include:
- Resolve candidate paths against a fixed trusted base directory before writing
- Reject paths whose canonicalized form falls outside the permitted directory
- Prefer generated filenames or controlled identifiers over arbitrary path input
- Apply strict allowlists for writable locations and file types
- Run the service with the least filesystem permissions necessary
- Use filesystem, container, and operating-system controls to limit writable areas
- Treat tool parameters as untrusted even when requests originate from an internal workflow
How teams detect issues like this
Organizations commonly detect path traversal risks through:
- Static analysis rules for file APIs that consume request or tool parameters
- Code review checks for path joining without canonicalization and boundary validation
- Tests covering traversal sequences, absolute paths, symbolic links, and platform-specific path forms
- Runtime monitoring for writes outside approved application directories
- Policy enforcement that restricts service write access to explicitly permitted paths
Automated code review and software composition tools may help identify unsafe path-handling patterns.
