CVSS score AWS assigned to both flaws (version 4.0): 8.4 (Source: Infosecurity Magazine, reporting AWS scores (September 29, 2026). Both also scored 7.3 under CVSS 3.1.)
A strong wall can hold while the door beside it stays open. That is the lesson in two flaws in the Python software development kit (SDK) for Amazon Bedrock AgentCore. The isolation held. The small piece of code that prepared its instructions did not.
BeyondTrust's researchers published a technical write-up on September 28. The flaws are CVE-2026-12530 and CVE-2026-16796. Both sit in the SDK's Code Interpreter helper, which installs software packages for AI agents.
What happened
An AI agent often needs a library before it can run code. The SDK's install_packages() helper turns a package name into an install command. BeyondTrust found that a crafted package name could smuggle shell commands into the Code Interpreter sandbox.
CVE-2026-12530 hit SDK versions 1.1.3 to 1.6.0. The helper screened names against a list of banned characters. That list was incomplete. AWS fixed it in version 1.6.1 with a stricter validation rule.
Then BeyondTrust found a way around the fix. CVE-2026-16796 abused pip's package extras syntax. Extras are optional add-ons that can be written into a package name. AWS lists every version before 1.18.1 as affected. The fix arrived in 1.18.1.
How the attack works
The isolation was not the weak point. BeyondTrust said the Firecracker isolation used for Code Interpreter sessions held. The weakness was in the helper that built the install command.
Once commands ran inside the sandbox, the researchers read temporary credentials for the Code Interpreter's execution role. That role is the identity the code uses to call AWS services. What an attacker could do next depended on its permissions. Overly broad permissions could open the way to other AWS services, BeyondTrust said.
Exposure took three conditions at once. Attacker-influenced input had to reach install_packages(). The SDK version had to be vulnerable. The Code Interpreter had to be a custom one with an execution role attached.
Why validating the name was not enough
The original flaw, CVE-2026-12530, was an incomplete blocklist. It banned some characters and missed others. AWS replaced it in version 1.6.1 with a stricter validation rule.
That new rule was then bypassed. BeyondTrust used pip's extras syntax to pass shell commands through it. The source does not explain why the new rule failed, or what kind of rule it was.
The following is the publication's view of the pattern, not the cause of this failure. Checking a name for bad content is a different job from building the command so that a name can never act as a command. The second approach removes the problem instead of chasing it.
Why agents raise the stakes
BeyondTrust named three ways hostile input could arrive. A user could supply a package name. An agent could pick one up from untrusted content it processed. Or a dependency file in an untrusted repository could carry it.
Two of those three routes need no person typing anything hostile. An agent reads a page or a repository and decides what to install.
This is where AI multiplies risk. It widens the paths by which outside text can reach a command line. AWS told customers to keep untrusted or model-generated package names away from the helper.
There is a detection problem too. BeyondTrust said the attacker's actions could resemble normal application activity in AWS logs. A security team may see ordinary-looking calls from a role it already trusts. The coverage does not describe attacks in the wild.
What leaders should ask
Put five questions to your cloud team. Which AgentCore workloads use the Python SDK, and is each on version 1.18.1 or later? Which use a custom Code Interpreter that has an execution role attached? Does that role need AWS access at all? Where it does, are its IAM permissions tightly scoped? Who reviews Code Interpreter activity, given that it can look routine?
BeyondTrust's own recommendations point the same way. Skip execution roles when code needs no AWS access. Tighten permissions when it does. Watch what the interpreter does. The patch closes two flaws. Tight permissions limit the damage from any flaw that puts code in the sandbox.
A sandbox is only as safe as the code that feeds it, and the credentials attached to it set the price of a mistake.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Infosecurity Magazine.
