TL;DR — Key Takeaways
– Researchers found two command injection vulnerabilities in the Amazon Bedrock AgentCore Python SDK’s install_packages() function.
– The flaws could allow malicious package names to execute shell commands inside a Code Interpreter sandbox.
– If a Code Interpreter had an AWS execution role attached, attackers could potentially access its temporary credentials and use the permissions assigned to that role.
Every AI agent that does real work needs real access. That’s the deal teams make when they let an agent write code, query data, or call cloud services. What many haven’t thought through is how small that opening can be.
New research from BeyondTrust’s Phantom Labs team puts a size on it: one package name. Security researcher Sergio Garcia found that a crafted name passed to the Amazon Bedrock AgentCore Python SDK could run shell commands inside the Code Interpreter sandbox. Where the customer had attached an execution role to that interpreter, the same commands pulled the role’s temporary AWS credentials.
AWS fixed it. Garcia got around the fix. AWS fixed it again. One report produced two CVEs.
The problem sat in install_packages(), a helper that lets an agent add Python libraries to a sandbox session. The SDK validated each package name, dropped it into a pip install command, and sent that command to Code Interpreter, which ran it as shell.
The first check was a blocklist of five characters: semicolon, ampersand, pipe, backtick, and dollar sign. It left out the newline. So a name like “pandas” followed by a newline and a command reached the shell as two lines, and the second one ran. That’s CVE-2026-12530, which affects SDK versions 1.1.3 through 1.6.0.
AWS shipped version 1.6.1 in April with a regex allowlist that checked the shape of a package name. But the pattern accepted almost anything inside square brackets, the syntax pip uses for optional “extras” such as pandas[performance]. Garcia put a shell command substitution inside the brackets, and the shell ran it before pip did. That’s CVE-2026-16796, which affects versions 1.6.1 through 1.18.0.
The fix that helped arrived in version 1.18.1 in July. The SDK now quotes each package name so the shell reads it as text, not as a command, and the allowlist is tighter. Both CVEs carry a CVSS 3.1 score of 7.3 and a CVSS 4.0 score of 8.4.
“We didn’t need to break into anything,” Garcia said. “We just needed a package name the validation would accept. The credentials behind an AI agent are only as safe as the smallest piece of untrusted input that reaches it, and a package name is about as small as it gets.”
“The sandbox held as it is designed to do. What happens inside the sandbox now defines whether there is material impact,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group. “Agent deployment pace isn’t bound by model capability. It’s bound by whether every session’s identity is scoped and logged.”
Each Code Interpreter session runs in its own Firecracker microVM. But inside that microVM sits a metadata service that hands the execution role’s credentials to any code that asks for them.
What sets this case apart is how the attacker gets in. They don’t need AWS permissions of their own. They only need to influence the input of an application that calls the Code Interpreter. BeyondTrust describes three paths: user-supplied library names, prompt injection through content the agent reads, and malicious dependency files in a repository or notebook.
A function that only installs packages looks far safer to hand an agent than a shell. That’s exactly why careful teams expose it.
What happens next depends on the role. If it can invoke Bedrock models, an attacker can run models on the company’s bill. If it has iam:PassRole or sts:AssumeRole, the sandbox becomes a route into the rest of the AWS account. And every call is signed by the execution role, so in the logs it looks like the application is doing its job.
Detection is harder than it should be. Both payloads look like an ordinary pip install, and the install succeeds. Anything that alerts on failed tool calls will miss it. The two log sources that help, CloudTrail data events and AgentCore Observability application logs, are both off by default. CloudTrail doesn’t record the command. The application logs do. BeyondTrust suggests watching for commands that reference the metadata service address, 169.254.169.254, or its encoded forms.
Ashley’s advice is direct. “The fix held, quoting the package name and narrowing the execution role,” he said. “Scope every role to what it needs, treat package names and dependency files as untrusted input, and turn on the AWS logging by default.”
For teams running agents on AgentCore, that starts with upgrading bedrock-agentcore to 1.18.1 or later and confirming that any forked code includes the fix. A fixed list of packages is also safer than one an agent can extend.
Then look hard at the execution role. AWS’s default system interpreter, aws.codeinterpreter.v1, has no role at all, so there are no credentials to steal. When code does need AWS access, give it a dedicated role scoped to what it calls, with no service wildcards and no unrestricted iam:PassRole. Once logging is on, alert on what commands contain, not on whether they fail.
The first fix stopped at the filter. Filters invite bypasses. Quoting input and limiting privilege hold up better.
Agent execution roles are non-human identities. They’re chosen once, inherited by every session, and easy to forget. As agents take on more work, those identities decide how much any single bug is worth. Scope them tightly, and the next flaw like this stays contained. Leave them broad, and it won’t.
