AWS Bedrock AgentCore sandbox bypass allows covert DNS C2 and data exfiltration


A newly disclosed security issue in AWS Bedrock AgentCore Code Interpreter shows that sandboxed environments were not as isolated as many users likely assumed. BeyondTrust’s Phantom Labs said AWS Bedrock AgentCore Code Interpreter in Sandbox mode still allowed DNS resolution, which let researchers build covert command-and-control channels and exfiltrate data even when general outbound internet access was blocked.

The finding matters because AWS documentation now says Sandbox mode provides “limited external network access” and explicitly notes that the code interpreter can access Amazon S3 for data operations and perform DNS resolution. BeyondTrust said AWS had previously described Sandbox mode as offering “complete isolation with no external access,” and argued that this gap was large enough to undermine the service’s isolation guarantees for customers expecting a true no-egress environment.

According to BeyondTrust, the allowed DNS traffic was enough to support a full bidirectional channel. Researchers said they used DNS queries and responses to send commands into the sandbox and pull command output back out, effectively creating an interactive reverse shell over DNS.

What AWS Bedrock AgentCore Code Interpreter does

AWS Bedrock AgentCore Code Interpreter is a managed code execution tool for AI agents. AWS says it can run Python, JavaScript, and shell code on behalf of applications and agents, with network settings that include Sandbox, Public, and VPC-based configurations depending on the deployment model. AWS’s documentation also shows that users assign an execution IAM role to the interpreter, which determines what AWS resources the tool can access while running code.

That detail is central to the risk. If a sandboxed code interpreter retains access to AWS resources through its assigned IAM role, then a covert channel does not need full web access to become dangerous. BeyondTrust said the DNS path allowed commands to run under that execution role, which opened the door to listing S3 buckets and pulling sensitive content that could then be exfiltrated through DNS queries.

How the bypass works

BeyondTrust said Sandbox mode blocked normal internet traffic, but still permitted DNS A and AAAA lookups. Researchers tested this with Interactsh and confirmed that DNS requests could leave the supposedly isolated environment. From there, they built a proof of concept that encoded commands into DNS responses and encoded output into DNS subdomain requests sent back to attacker-controlled infrastructure.

In practical terms, that gave the researchers a covert control channel that sat inside the DNS layer rather than a standard outbound session. Because DNS often receives different treatment than regular web traffic, the researchers argued that this behavior could let attackers hide command traffic and data theft inside activity many defenders do not immediately view as suspicious. That is the core reason the issue stands out. It is not just a leak. It is a workable channel.

Why IAM permissions make this far more serious

The DNS bypass on its own would already be a problem for any product marketed as isolated. The bigger issue is what a code interpreter can do once it executes commands with its IAM role. AWS documentation makes clear that the runtime role defines what AWS resources the interpreter can access. BeyondTrust said that through the DNS shell they were able to use AWS CLI commands with the interpreter’s role and access S3 data, including sensitive files.

That means the real impact depends heavily on how broadly customers configure those roles. A tightly scoped IAM policy could limit the damage. A generous one could turn a covert DNS tunnel into a path for data theft, secrets exposure, and access to other cloud resources. This is one reason AWS now recommends VPC mode for customers that want complete control over traffic rather than relying on Sandbox mode.

AWS Bedrock AgentCore Sandbox Bypass Flaw

Disclosure timeline and AWS’s response

BeyondTrust said it disclosed the issue to AWS through HackerOne on September 1, 2025. The researchers said AWS acknowledged and reproduced the issue, deployed an initial fix on November 1, 2025, then rolled that fix back. According to the disclosure, AWS later told BeyondTrust that it would not issue a permanent code fix and would instead update the documentation to clarify that Sandbox mode permits DNS resolution and recommend VPC mode for customers that need stricter isolation. Public disclosure followed on March 16, 2026.

AWS’s current documentation reflects that change in emphasis. Rather than describing Sandbox mode as a complete no-network environment, the docs now frame it as a mode with limited external network access and specifically note DNS resolution. AWS also provides separate guidance for VPC mode configuration, which gives customers more direct network control.

Why this matters for AI agent security

The vulnerability highlights a broader issue with AI code execution services. These systems are powerful because they let agents run code, process data, and interact with cloud services. That same power makes mistakes in isolation, permissions, and dependency handling much more dangerous. BeyondTrust framed the Bedrock AgentCore issue as part of a growing AI attack surface, where prompt injection, dependency abuse, or code manipulation could become the initial step that eventually reaches cloud data through the interpreter’s privileges.

There is also earlier research pointing to related isolation concerns in AgentCore environments. Sonrai Security reported in September 2025 that sandboxed Bedrock AgentCore code interpreters could still expose execution role credentials through the microVM metadata path, which it described as another way attackers could abuse sandboxed interpreters even without broad internet access.

What security teams should do now

Teams using Bedrock AgentCore Code Interpreter should review their network mode assumptions first. Sandbox mode should not be treated as equivalent to zero egress, because AWS documentation now explicitly says it allows DNS resolution and S3 access for data operations. Organizations that need tighter controls should evaluate VPC mode and confirm how DNS, routing, and egress are handled in their own setup.

They should also audit execution IAM roles immediately. The safest setup is one that gives the interpreter only the minimum permissions needed for its task. If a code interpreter can read broad S3 data or other sensitive services, then any successful sandbox bypass becomes far more damaging. AWS’s own setup documentation makes clear that the execution role defines what resources the interpreter can touch, so that role deserves the same scrutiny as any other privileged workload identity.

Bedrock AgentCore network modes at a glance

Network modeWhat AWS saysSecurity takeaway
SandboxLimited external network access; can access Amazon S3 for data operations and perform DNS resolutionNot a true no-egress environment
PublicAllows access to public internet resourcesHighest exposure if not tightly controlled
VPCCustomer-managed network controls through VPC configurationBest fit when stricter traffic control is required

Key risks from the disclosure

  • DNS can act as a covert command-and-control path even when general outbound traffic is blocked.
  • Data exfiltration risk rises sharply if the code interpreter’s IAM role can access sensitive AWS resources.
  • Customers may overestimate Sandbox mode if they assume it means complete network isolation.
  • AI code execution services create a wider blast radius when network controls and permissions do not align.

Bottom line

The AWS Bedrock AgentCore issue is not just another cloud misconfiguration story. It shows how a small exception in a managed sandbox, in this case outbound DNS resolution, can turn into a covert control path with real data theft potential when the workload also holds useful IAM permissions.

For customers, the lesson is clear. Do not treat “sandbox” as shorthand for total isolation without checking the exact network behavior, and do not give AI execution environments more AWS access than they absolutely need. In Bedrock AgentCore, those two decisions can determine whether a DNS leak stays minor or becomes a full exfiltration channel.

FAQ

What is the AWS Bedrock AgentCore sandbox bypass?

BeyondTrust said AWS Bedrock AgentCore Code Interpreter in Sandbox mode still allowed DNS A and AAAA queries, which let researchers build covert C2 and exfiltration channels despite broader outbound restrictions.

Did AWS fix the issue?

According to BeyondTrust, AWS acknowledged the issue but ultimately chose not to ship a permanent code fix, instead updating documentation and recommending VPC mode for customers that need stricter isolation.

Why is DNS access such a problem here?

Because BeyondTrust showed it could use DNS itself as the transport for commands and data, which turned a limited exception into a working reverse shell and exfiltration path.

How does IAM increase the impact?

AWS says the code interpreter runs with an execution role that defines what AWS resources it can access. If that role is broad, an attacker who gains code execution can use it to reach sensitive data.

What should AWS customers do?

Review Bedrock AgentCore network modes, move sensitive workloads to VPC mode where needed, and lock down execution IAM roles to least privilege.

Readers help support VPNCentral. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more

User forum

0 messages