Breaking the AWS MCP Python Sandbox

A security researcher bypassed the Python restrictions in AWS's managed MCP Server, reaching system command execution inside the AWS Lambda sandbox that runs the `aws___run_script` tool, which AWS made generally available on May 6, 2026. The researcher, working with Claude Opus 4.6, built a Python CLI MCP client using `mcp-proxy-for-aws` and a limited-permission test IAM user to probe the tool, then defeated both of its protection layers: an AST-based static validator and a runtime layer that swaps builtins for restricted proxies such as `_safe_type()` and limits `open()`. The bypass matters because the tool executes agent-supplied Python inside AWS's environment using the user's IAM credentials.

Preface preface AWS announced the general availability of the AWS MCP Server https://aws.amazon.com/blogs/aws/the-aws-mcp-server-is-now-generally-available/ on May 6, 2026. It is a managed remote Model Context Protocol MCP server. An MCP server exposes certain tools/functions and lets your AI agent call them. It extends your AI agent’s capabilities. The AWS MCP Server makes this possible for coding assistants such as Claude Code, Kiro and Cursor to retrieve current AWS documentation, make AWS API calls using the IAM credentials supplied by the user, and provide guidance through skills. Those tools can be used for tasks such as retrieving account information or creating an EC2 instance. AWS’s MCP server provides a tool called aws run script . This tool accepts a short Python script as an argument and runs it in a server-side sandbox. Its purpose is to let an agent combine multiple AWS API calls, filter the responses and process the result in one request programatically, instead of making several separate calls. The idea of user-supplied Python code executing inside an AWS managed sandboxed environment is interesting aws run script runs the supplied code in an AWS Lambda sandbox. The sandbox restricts imports, builtins, attribute access and file operations. In this blog, I explain how I bypassed those Python restrictions and reached system command execution inside the Lambda environment. I performed this research collaboratively with Claude Opus 4.6. Discovery discovery Normally connecting the MCP server to Cursor or any other agent adds friction for security testing because your payloads have to pass through the AI agent which then invokes the tools. While it is fine for a while, but later it becomes a pain when your payloads starts become overly chaotic. So I quickly created a Python CLI as an MCP client that could let me enumerate the server’s tools and invoke them. The client used mcp-proxy-for-aws https://github.com/aws/mcp-proxy-for-aws , which signed requests with my local AWS credentials. I created a test IAM user in my AWS account with limited permissions for this assessment. This made it possible to send controlled inputs to each tool and examine the returned results. Although the Python code ran inside the Lambda, dangerous Python code was immediately blocked due to the custom sandbox implemented, to prevent code execution inside the Lambda runtime. I wanted to find out what actually prevented it from reaching the process, filesystem or environment beneath the Python sandbox. Understanding the Sandbox understanding-the-sandbox The submitted code passed through two layers of protection. Firstly, a static validator inspected the code’s Abstract Syntax Tree AST . An AST is a structured representation of source code. ASTs are used widely in compilers, code interpreters, linters, etc. An AST is a data structure containing the structural logic of the code such as imports, calls, attribute reads and assignments. The validator in the sandbox used AST to parse the Python script passed into aws run script to reject certain malicious looking operations before the code gets executed. Secondly, a runtime layer replaced builtins with restricted implementations or proxy objects. In this context, a proxy is a replacement object that acts like the original object but limits how it can be used. For example, instead of the real type , the script gets safe type which returns restricted proxy classes that block access to sensitive attributes. The sandbox also limited open to control file access. For example, reading sensitive attributes through obj. class was blocked. The getattr builtin was also blocked, as was importing operator to call operator.attrgetter . getattr is simply another way to read an attribute. In normal Python, two lines produce the same output: python from types import SimpleNamespace person = SimpleNamespace name="John Doe", age=900 print person.name John Doe print getattr person, "name" John Doe They both read name from person . When the attribute name is determined at runtime, getattr is useful, as the attribute name can be passed as a string. The sandbox covered both of these common forms of attribute access. It did not account for structural pattern matching. The Flaw: Attribute Reads Hidden in a Pattern the-flaw-attribute-reads-hidden-in-a-pattern Python 3.10 introduced structural pattern matching through match/case . It checks whether a value fits a pattern and can bind parts of that value to names. A class pattern first checks an object’s type, then reads attributes from it. Here is an example: python from collections import namedtuple Coordinate = namedtuple "Coordinate", "x", "y" location = Coordinate 10, 20 match location: case Coordinate horizontal, vertical : print horizontal, vertical This would print 10 20 . Python decides which attributes go into horizontal and vertical by looking at match args on the class. print Coordinate. match args 'x', 'y' Names wrapped in double underscores are often called dunder names dunder comes from double underscore . They are special names used by Python’s object model. For the Coordinate class, match args contains: "x", "y" So the first position in the pattern reads x and the second reads y . This tuple can be changed: Coordinate. match args = "y", "x" With that change, the exact same pattern prints 20 10 . The tuple controls which attributes Python reads for the positional entries in the pattern. PEP 634 https://peps.python.org/pep-0634/ class-patterns specifies this class-pattern behaviour. CPython performs these attribute lookups internally, so they happen even if the getattr builtin exposed to user code has been removed. That matters for an AST validator. The validator on the sandbox only looks at the structure of the submitted code, and it was built to reject nodes that read sensitive attributes, such as obj. class an attribute access or getattr obj, " class " a call to a blocked builtin . A class pattern produces neither. In the AST, it is a single ast.MatchClass node containing the class name and the names to bind. The attribute name never appears in the code at the point where the read happens. It is stored in match args , and Python only looks it up while evaluating the pattern at runtime. Here is the same Coordinate example with match args pointed at a different attribute: Coordinate. match args = " class ", match location: case Coordinate c : print c This prints <class ' main .Coordinate' . The pattern Coordinate c has a single positional entry, so Python reads the first name in match args , which is now class , from location and binds the result to c . The code above never directly specified location. class , but that value came up in c . Two conditions had to hold in the sandbox for this to be useful: - Assigning to match args was permitted. The validator blocked reading dunder attributes but it checked writes only against a short denylist of dunder names, and match args was not on it. - Class patterns still performed their implicit reads, because the check lives inside CPython and not in the validator or the replaced builtins. Together with those two, we can read attributes that the normal syntax could not reach. class is just an example here. This same trick works for any attribute name, including the ones the sandbox was intended to block. There was one more hurdle. The validator also rejected dunder names written as plain strings. So " class ", was blocked. I got around this by building the string at runtime using chr , where the validator could not see it: " class " blocked by the validator chr 95 2 + "class" + chr 95 2 allowed chr 95 is the underscore character. I used this for every dunder name in the chain such as reduce ex , globals and import . Building the Escape Chain building-the-escape-chain I began with collections.namedtuple , which was available in the sandbox. Calling it creates a tuple subclass with named fields, like Coordinate in the earlier example. The resulting class’s match args can be reassigned. This was useful because the sandbox removed build class from the exposed builtins, preventing ordinary class definitions. However, namedtuple creates its class internally using type ... , so this allowed standard-library function still gave me a way to obtain a class and control its match args . Recovering a Real Function recovering-a-real-function There were probably many other candidates, but after testing several, I ended up with reduce ex . reduce ex belongs to Python’s serialization support. When pickle needs to reconstruct an object later, it can ask the object for a recipe: a callable, arguments and any required state. After changing the namedtuple class’s match args to " reduce ex ", , a class pattern retrieved the instance’s reduce ex method. Calling it with protocol 4 returned a recipe whose first element was copyreg. newobj . copyreg. newobj was a real Python function, rather than a proxy function in the sandbox. This is important because a function defined in Python exposes globals which is a dictionary of global names in the module where it was defined. The globals for copyreg. newobj included builtins , the original Python builtins dictionary. builtins contains import , which we can use to load different modules. If I could recover that original import function, I could import os and subprocess . The next challenge was obtaining the real function’s globals with another class pattern. The namedtuple pattern couldn’t be reused here, because a class pattern checks its subject with isinstance , and copyreg. newobj is a function, not a namedtuple. I needed a class pattern for functions. The Proxy That Completed the Chain the-proxy-that-completed-the-chain Normally, type returns an object’s actual type. For a Python function, that is the function type types.FunctionType , which is immutable, so Python rejects attempts to add attributes to it. For example, assigning match args to the real function type produces: TypeError: cannot set ' match args ' attribute of immutable type 'function' Since the sandbox stopped me from defining my own class, this looked like a dead end. The sandbox replaced type with safe type , which was meant to return restricted proxy classes that block dangerous attributes. I called it on a throwaway function, type lambda: None . Inside the sandbox, the same assignment that fails in normal Python went through without an error. I only understood why later, once the finished escape let me read the sandbox’s logic. For any object, safe type tries to return a restricted copy of its real type by subclassing it. Python does not allow subclassing the function type, so for functions that attempt fails. The fallback then builds a brand-new proxy class from scratch. That new class blocks a few dangerous attribute reads, but it is an ordinary class created while the program runs, so its attributes can be changed. The sandbox returned a mutable replacement for an immutable type. So I set the proxy’s match args to " globals ", , using the same technique explained before. A class pattern only works on objects of the right type. When the proxy was asked whether copyreg. newobj was a function, it said yes. So the pattern matched. Python then read globals from the real function. The proxy did not restrict this access because the inspected function was an original “non-proxied” object. Its globals gave me the real Python builtins dictionary. By calling its import function, I could then import os and subprocess . The AST validator missed the implicit reads from the class patterns. The runtime proxy gave the missing piece for the chain: a mutable class that still passed isinstance for real functions, which let me set match args on it. The full chain is as follows: php namedtuple - match args - reduce ex - copyreg. newobj - type proxy - match args - globals - builtins - import - subprocess - id Confirming Command Execution confirming-command-execution Once I could import subprocess , I used my Python MCP client CLI to execute id in the Lambda environment. It returned: uid=993 sbx user1051 gid=990 groups=990 This confirmed command execution as the Lambda user beyond what the Python sandboxed environment was meant to allow. Running env also exposed the Lambda execution role’s credentials in these variables: AWS ACCESS KEY ID AWS SECRET ACCESS KEY AWS SESSION TOKEN The credentials belonged to the role attached to the Lambda sandbox, not the IAM user I used to connect to the MCP server. The escape also allowed filesystem reads, including reads of the sandbox’s own Python source. The root filesystem was read-only and /tmp was writable as in a normal Lambda function. The Impact the-impact The Python sandbox escape gave me command execution and access to the process environment inside my session’s Lambda container: - System command execution as the Lambda user. - Disclosure of the Lambda execution role credentials. - Read access to the files available to that user, including the sandbox implementation. The recovered sandbox Lambda role credentials received explicit deny errors for every AWS API call except for sts:GetCallerIdentity which is always available and does not require any permissions https://docs.aws.amazon.com/STS/latest/APIReference/API GetCallerIdentity.html . This limited what could be done. The credentials belong to an IAM role in the AWS-owned account and not a customer account, which I confirmed via the sts:GetCallerIdentity API response. In my testing, I found no access to other sessions or customer data and the escape was confined to the Lambda container created for my MCP client’s session. Closing Thoughts closing-thoughts The sandbox had two layers of protection. The AST validator blocked the usual ways of reading sensitive attributes, but Python’s match/case feature can read attributes without using any of them. The runtime layer replaced standard Python functions and objects with its own versions, which restricted certain capabilities and attributes. There was a gap in this implementation which finally completed the exploit chain. It is not easy to get sandboxes right. Python often has several ways to achieve the same thing. So, blocking the most obvious ones can still leave a less obvious one open. Also, replacing a built-in with a “safer” version can backfire if the replacement behaves differently from the original. You have to get right in all the ways possible. An attacker just needs to find one path to exploit. In this case, AWS’s other controls locked-down credentials, no internet access and a separate container per session in my testing limited the damage. Thanks for reading, and I’ll see you around on the next one : Vulnerability Disclosure Timeline vulnerability-disclosure-timeline - July 26, 2026 — Reported to Amazon AWS VDP via HackerOne - July 30, 2026 — Report validated by HackerOne and forwarded to AWS team - September 15, 2026 — Amazon AWS team acknowledged the report and confirmed a fix was in progress - October 23, 2026 — Vulnerability report marked as resolved - October 24, 2026 — Public disclosure