AWS fixed a Bedrock AgentCore injection bug twice; the second fix's changelog named no CVE

The Python SDK for AWS's Bedrock AgentCore shipped an argument injection flaw in its install_packages() helper that took two fixes to close — and the second fix landed with a changelog entry that gave no sign a security issue was involved. A write-up on dev.to traces both rounds of the bug, from the first patch in v1.6.1 to a bypass closed in v1.18.1, in parallel with full research from BeyondTrust's Phantom Labs team published on September 28.

How the bug worked

AgentCore's Code Interpreter lets agents install Python libraries at runtime, and the SDK wraps pip install on their behalf: callers pass a list of package names and the SDK runs the install inside an isolated sandbox. According to the dev.to analysis and the advisories it cites — GHSA-6rfw-mq36-jm8h and AWS bulletin 2026-044-aws — versions 1.1.3 through 1.6.0 joined those strings into a shell command with almost no validation. A crafted package name could escape its position as a pip argument and execute attacker-chosen commands inside the sandbox, a CWE-88 argument injection; one demonstrated path used a newline to smuggle a second command.

NVD rates both CVEs at CVSS 3.1 7.3 and CVSS 4.0 8.4, marked Secondary and Awaiting Analysis. The scoring vectors cap direct impact at the sandbox boundary rather than the host or the AWS account. But the first advisory also flags that a crafted name could redirect pip to an attacker-controlled package index and expose sandbox files and environment variables — a meaningful distinction whenever sandboxes hold API keys, session tokens or source code.

Why the first fix did not hold

The first patch shipped in v1.6.1 on April 10, with the CVE-2026-12530 record following on June 17 and finder Sergio Garcia credited. The bypass exploited pip's extras syntax: strings in the package[extra1,extra2] form carried command substitution through a spot the new validation never inspected. That second flaw, tracked as CVE-2026-16796 and affecting every version below 1.18.1, was fixed on July 17 in PR #581, with its advisory published a week later.

Per the dev.to post, the v1.18.1 changelog says only that package specifier validation was tightened — no CVE number, no mention of injection. The actual fix reportedly pairs shlex-based quoting with a stricter allowlist for which extras syntax is permitted: parse the input rather than concatenate it.

The escalation research

BeyondTrust's Phantom Labs published their full findings on September 28 under the title "Package Name to Role Credentials in Code Interpreter", alongside a companion repository, agentcore-sandbox-breakout, demonstrating DNS and S3 exfiltration paths from these same sandboxes. The dev.to author is explicit that they have not reproduced the credential chain themselves, so the escalation from package name to role credentials stands as BeyondTrust's finding rather than an independently verified result.

Checking your own project

The two CVE ranges differ, which is the detail that trips up version checks: CVE-2026-12530 covers versions 1.1.3 up to 1.6.1, while CVE-2026-16796 covers everything below 1.18.1. The current release is v1.24.0, so a routine upgrade clears both. The dev.to post recommends checking the installed version against each range separately rather than trusting a blanket "before 1.18.1" cutoff, and grepping the codebase for install_packages call sites — every one is a place where a string that began life as model output, a config value or a user request becomes a command.

Why it matters

Two lessons come out of the timeline. First, any SDK helper that builds shell commands from free-form strings is a sink, and in agent stacks those strings rarely come from developers: package lists typically originate in a model's plan or a plugin manifest, so the trust boundary sits wherever LLM output touches the parameter. Second, watch the research clock, not just the patch clock: the second fix landed on July 17, but the deep research arrived on September 28 — a 73-day gap, as the dev.to author points out, during which deployments could remain quietly exposed even though a fix existed. The repeated pattern also suggests the first repair was shaped like a patch rather than a design change; parsing inputs instead of concatenating them is what finally closed the bug.