Bedrock AgentCore Package Arguments Could Become Sandbox Commands — CVE-2026-16796
AWS has patched command injection in the install_packages() method of the Bedrock AgentCore Python SDK’s Code Interpreter client. Before version 1.18.1, a crafted package-name argument could bypass validation and let a remote authenticated user execute arbitrary commands inside the managed Code Interpreter sandbox. The issue is tracked as CVE-2026-16796 and GHSA-j6g5-3hh3-pgw8.
AWS’s advisory marks every bedrock-agentcore version before 1.18.1 as affected. The GitHub advisory rates the flaw high severity at CVSS 3.1 score 7.3; NVD also records a CVSS 4.0 score of 8.4. The published impact is command execution within the sandbox—not an escape into the host or AWS control plane—and the disclosure does not report exploitation in the wild.
The important trust boundary is the method argument. Package installation often looks like a routine dependency operation, but a package specifier is structured input interpreted by installation tooling. If an agent can derive that value from a prompt, document, repository, tool result, or remote user, the value is model-influenced untrusted data even when the application user has already authenticated.
The sandbox limits impact; it does not make injection acceptable
Code Interpreter exists to run code in an isolated managed environment. CVE-2026-16796 lets an attacker cross the SDK’s intended “package name” boundary and issue arbitrary commands in that environment. That can expose data already placed in the session, alter generated outputs, poison later computations, and use whatever network access or credentials the sandbox legitimately has.
A sandbox is therefore a containment layer after exploitation, not validation before it. Defenders should avoid inflating the confirmed scope into a host escape, but they should also avoid dismissing the flaw because execution remains isolated. The sensitivity of uploaded data, session lifetime, egress policy, reachable services, and credentials determines the practical consequence for each application.
The advisory’s remote-authenticated precondition describes access to the vulnerable application path, not necessarily direct access to the SDK object. An application can unintentionally provide the necessary influence by allowing an agent to choose dependencies on a user’s behalf. Indirect prompt injection is also relevant whenever untrusted content can shape that tool argument, although AWS does not claim a specific prompt-injection exploit chain.
Package names need a grammar, not a blocklist
AWS’s temporary guidance is explicit: do not pass untrusted or model-generated input into install_packages(). Where dynamic dependencies are unavoidable, applications should enforce strict PyPI naming rules and constrain extras to comma-separated identifiers before calling the SDK.
That calls for positive validation. Accept a narrowly defined package-name and version grammar, reject option-like prefixes and control characters, normalize once, and compare the normalized value with an application-owned allowlist. Do not depend on a list of dangerous shell tokens; structured package syntax has enough alternate forms that denylisting individual delimiters is fragile.
In higher-assurance systems, the agent should not choose arbitrary dependencies at all. Map a small set of task capabilities to preapproved, pinned packages or prebuilt interpreter images. This removes package-resolution authority from the model, improves reproducibility, and reduces exposure to dependency confusion and malicious package updates as well as argument injection.
Defensive response checklist
- Upgrade to 1.18.1 or later. Update
bedrock-agentcore, regenerate lockfiles, rebuild deployment artifacts, and verify the resolved version in every running application. - Find every caller. Search for
install_packages()and wrappers around the Code Interpreter client. Trace whether values can originate from prompts, files, web pages, repositories, API requests, or tool output. - Stop forwarding model output. Until patched, AWS says not to pass untrusted or model-generated input to the method. Prefer disabling dynamic installation over adding an improvised filter.
- Use a positive package policy. If dynamic installation remains necessary, validate strict package syntax, tightly constrain extras, and select from an application-owned allowlist of pinned dependencies.
- Review sandbox data. Identify secrets, source code, customer files, generated artifacts, and tokens exposed to Code Interpreter sessions. Rotate credentials if telemetry supports compromise.
- Constrain egress and identity. Give the interpreter no ambient credential or network route it does not need. Treat package indexes and artifact stores as explicit destinations.
- Inspect session telemetry. Look for unexpected package strings, option-like arguments, subprocess activity, outbound connections, modified output files, and anomalous package-index access.
- Add adversarial tests. Confirm that malformed specifiers, control characters, option prefixes, unexpected extras, URLs, local paths, and agent-generated free text are rejected before the SDK call.
The flaw reinforces a core agent-security rule: a typed tool signature does not make its string arguments safe. Once a value reaches a package manager, shell, query engine, browser, or cloud API, validation must match the downstream interpreter’s grammar and the application’s intended capability.
Containment remains essential, as the recent coding-agent sandbox escape review showed, but prevention and containment are separate controls. Patch the argument boundary, restrict what dependencies an agent may request, and keep the interpreter’s data, identity, filesystem, and network reach narrow in case another parser defect survives.
Sources: