.png)
Varonis Threat Labs identified a Local File Inclusion (LFI) vulnerability in the AWS Remote MCP Server that allows an authenticated user to read arbitrary files from the underlying operating system, possibly leading to an attacker obtaining credentials or other privileged information from the hosting server.
At a high level, the vulnerability was triggered by certain AWS commands allow input from local files. When those commands were processed by the MCP server, information from those files could unintentionally surface through error messages. We were able to reproduce this behavior against the official public AWS MCP endpoint, underscoring the real‑world risk of the issue.
AWS addressed the issue in aws-api-mcp-server version 1.3.9 and issued CVE-2026-4270. AWS and Varonis strongly recommend that all AWS users upgrade to the latest version and ensure any forked or derivative code is patched to incorporate the new fixes.
Continue reading to see the breakdown of what we found, why it matters, and what organizations should do next.
How we discovered the LFI vulnerability
This behavior is possible despite the MCP server being configured with `FileAccessMode=NO_ACCESS`and is present in all versions of the mcp server since 0.2.14.
The issue behind the LFI vulnerability stems from the AWS CLI shorthand syntax, which supports loading parameter values directly from local files. When passing such a command through the `aws___call_aws` tool exposed by the MCP server, file contents could be read through error messages.
Notably, we were able to reproduce this vulnerability against the publicly hosted AWS MCP endpoint at `aws-mcp.us-east-1.api.aws` which runs in an AWS-owned account distinct from the attacker’s own account.
What is AWS CLI Shorthand File Loading?
The AWS CLI shorthand syntax allows complex parameters to be expressed concisely and includes support for reading values from files using the `@=` operator. For example, AWS documentation shows file loading being used for certificate material:
sourceData={x509CertificateData@=file://root-ca.crt}
While this is expected behavior in a local CLI context, exposing this functionality through a remote execution service introduces additional risk.
How does the LFI vulnerability work?
When invoking the `aws___call_aws` tool on the AWS MCP server, it is possible to supply a CLI command that uses the shorthand file-loading syntax. The MCP server processes this command and attempts to read the referenced file from its own filesystem.
When passing a file with an incorrect format in this way, the command fails. However, the file’s contents are included in the resulting error message returned to the user. This effectively allows arbitrary file reads from the MCP server host.
This behavior occurs even when the MCP server is configured to disallow file access entirely.
Using an MCP debugging client (such as the MCP Inspector), an authenticated user can issue the following command via the `aws___call_aws` tool:
aws ec2 create-tags \
--resources <instance_id> \
--tags Key="yay",Value@=fileb:///etc/passwd
The command returns an error, but the error message includes the contents of `/etc/passwd`, confirming that the file was read from the server’s filesystem.
What is the impact on my organization?
The LFI vulnerability breaks the security boundary assumed by `FileAccessMode=NO_ACCESS` and enables:
- Arbitrary file reads from the MCP server host
- Potential disclosure of sensitive system, configuration files, or secrets
- Exposure of information about the underlying execution environment
Because the issue is present on a publicly hosted AWS MCP endpoint, the impact extends beyond self-hosted deployments. Anyone using an old version of the AWS MCP server are advised to upgrade it to the latest version.
Conclusion
Our discovery of the LFI vulnerability in AWS highlights the growing risks of exposing powerful CLI abstractions through remote execution services without fully accounting for implicit features such as file loading. Even well-documented and intentional CLI behaviors can become vulnerabilities when reused in new trust contexts.
This isn’t a one‑off bug. With attackers only needing access, it’s a pattern that will repeat as cloud services expose more automation and “convenience” features.
Special thanks to the AWS Security team for their quick response and for quickly remediating this issue.
What should I do now?
Below are three ways you can continue your journey to reduce data risk at your company:
Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.
See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.
Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.
