AWS Bedrock AgentCore — 5 CVEs across the CLI, Python SDK, Starter Toolkit, and InvokeHarness API, including a recurring argument-injection bug the first fix didn't fully close

View raw markdownEdit on GitHub ↗

TL;DR

AWS's own security bulletins disclosed five separate CVEs in Amazon Bedrock AgentCore — the SDK/CLI toolchain for building and deploying AI agents on AWS — between March and August 2026: a critical (CVSS 9.0) code-injection flaw in the AgentCore CLI's agent-import command (CVE-2026-11393), two CVEs for the same root cause in the Python SDK's install_packages() Code Interpreter helper (CVE-2026-12530, then CVE-2026-16796) — the second one published just five days before an earlier sweep, meaning the first fix didn't fully close the hole — a high-severity (CVSS 7.5) build-time code-injection bug in the separate Starter Toolkit (CVE-2026-4269) via missing S3 bucket-ownership verification, and a fifth, distinct-root-cause CVE (CVE-2026-18830, CVSS 8.6) in the managed InvokeHarness API, part of the cross-vendor CoreBreak tool-call-forgery pattern also found in Google ADK and the Vercel AI SDK (see 2026-08-corebreak-agent-harness-tool-call-forgery.md for the full cross-vendor writeup). All five are patched, but the install_packages() recurrence is a textbook case of this repo's "incomplete fix ≠ patched" pattern: if you upgraded to the version that fixed CVE-2026-12530, you were still vulnerable to CVE-2026-16796 until a second, later update.

What happened

CVE-2026-11393 — AgentCore CLI code injection via triple-quote escaping (critical, CVSS 9.0)

Published 2026-06-08. The agentcore add agent --type import command generates Python source code from a Bedrock Agent's configuration, interpolating the agent's collaborationInstruction field into a triple-quoted Python docstring — but the code only escaped single quotes, not triple-quote sequences. Any authenticated user in the same AWS account holding the bedrock:AssociateAgentCollaborator IAM permission could craft a collaborationInstruction value containing """ to break out of the docstring boundary and inject arbitrary Python code into the generated source file, which then executes when the developer runs the imported agent. Affected: AgentCore CLI 0.4.0–0.14.1 (and preview builds 0.3.0-preview.7.0–1.0.0-preview.8). Patched: 0.14.2 (1.0.0-preview.9 for preview builds).

CVE-2026-12530 — Code Interpreter install_packages() argument injection, round one (high, CVSS 7.3/8.4)

Published 2026-06-17. The install_packages() method of the Bedrock AgentCore Python SDK's Code Interpreter client builds a pip install shell command from caller-supplied package name arguments, using an incomplete blocklist to sanitize them. A crafted package-name argument could smuggle pip flags past the filter — notably --index-url (redirecting package resolution to an attacker-controlled PyPI mirror) and -r (reading and exposing arbitrary files inside the sandbox). Affected: bedrock-agentcore 1.1.3 through versions before 1.6.1. Patched: 1.6.1.

CVE-2026-16796 — the same install_packages() bug, still exploitable after the first patch (high, CVSS 7.3/8.4)

Published 2026-07-23 — over a month after CVE-2026-12530's fix shipped, and just five days before this sweep. AWS's own advisory describes the identical root cause ("improper neutralization of argument delimiters in the install_packages() method"), but this time lists the affected range as all versions before 1.18.1 — meaning 1.6.1, the version that was supposed to fix CVE-2026-12530, was still vulnerable to a variant of the same argument-injection technique. This repo's "incomplete fix ≠ patched" caution applies directly: anyone who upgraded to 1.6.1 in response to the June CVE and considered themselves done was still exposed for another month. Patched: 1.18.1 (per AWS Security Bulletin 2026-065-AWS and GHSA-j6g5-3hh3-pgw8).

CVE-2026-4269 — Starter Toolkit S3 ownership-confusion build-time code injection (high, CVSS 7.5)

Published 2026-03-16, predating the other three CVEs in this cluster but only folded into this advisory now. The Bedrock AgentCore Starter Toolkit (a separate package from the CLI and core SDK covered above) did not verify ownership of the S3 bucket it used during the agent build process. An attacker who could claim or predict the expected bucket name — a classic S3 confused-deputy / bucket-takeover pattern — could inject malicious code into the build artifact, which then executes inside the AgentCore Runtime. Only builds performed after 2025-09-24 are affected; builds performed before that date, or with a toolkit already on 0.1.13+, are not. Affected: Starter Toolkit < 0.1.13. Patched: 0.1.13. Confirmed via both AWS's own security bulletin and an independent NVD fetch (CWE-283 Unverified Ownership, CWE-340 Generation of Predictable Numbers or Identifiers).

CVE-2026-18830 — InvokeHarness API tool-call forgery, bypasses the model entirely (high, CVSS 8.6)

Published as part of the CoreBreak cross-vendor disclosure (Black Hat USA 2026, researchers Hedi Ingber and Aviyam Ivgi of Stealth). An authenticated remote caller could place a tool-use content block directly into the final message of an InvokeHarness request; the event loop dispatched the named tool immediately without routing the decision through the model first — a different root cause from the four CVEs above (which are all argument/code-injection bugs in developer-facing tooling), and one that also affected Google's Agent Development Kit and the Vercel AI SDK's agent harnesses independently. Affected the managed InvokeHarness API before 2026-07-31. AWS added server-side validation rejecting caller-supplied tool-use blocks, applied automatically to the managed service — no customer action required. Full cross-vendor detail, including the Google ADK and Vercel AI SDK instances of the same pattern: 2026-08-corebreak-agent-harness-tool-call-forgery.md.

All four argument/code-injection CVEs above require an authenticated user with some level of existing access (same-account IAM permission for CVE-2026-11393, sandbox-reachable authenticated access for the two install_packages() CVEs, control over or prediction of an S3 bucket name for CVE-2026-4269) — none is a fully unauthenticated, internet-facing RCE. But Code Interpreter sandboxes and build pipelines are explicitly designed to run untrusted, agent-generated code and artifacts, and each of these bugs defeats a trust boundary that feature exists to provide.

Am I affected?

# Check your installed bedrock-agentcore SDK version
pip show bedrock-agentcore 2>/dev/null | grep -i version

# Check your AgentCore CLI version
agentcore --version 2>/dev/null

# Check your Starter Toolkit version (package name may vary by install method — check your requirements/lockfile)
pip show bedrock-agentcore-starter-toolkit 2>/dev/null | grep -i version
  • If bedrock-agentcore is below 1.18.1, you are exposed to at least one of the two install_packages() CVEs (and possibly both, depending on your prior version).
  • If your AgentCore CLI is below 0.14.2, upgrade before using agentcore add agent --type import against any Bedrock Agent collaborator you don't fully trust.
  • If your Starter Toolkit is below 0.1.13 and you've run a build since 2025-09-24, upgrade and treat any build artifacts produced in the interim as unverified.

If you are affected

→ playbooks/rotating-cloud-credentials.md — if a Code Interpreter sandbox may have been used to redirect package installs or read sandbox files, treat any credentials reachable from that sandbox as potentially exposed. → playbooks/auditing-a-vibe-coded-repo.md

Prevention

→ prevention/agent-sandboxing.md — treat any AI-agent code-execution sandbox (Code Interpreter, and equivalents in other agent frameworks) as a trust boundary that needs its own patch cadence, separate from the agent framework's headline version. → prevention/supply-chain-attack-surface.md

Why this matters for vibe coders

Amazon Bedrock AgentCore is AWS's answer to "build an AI agent that can run code" — the same category as LangChain/LangGraph, Semantic Kernel, and the other agent SDKs this repo already tracks a steady stream of CVEs against. This cluster is a clean illustration of two patterns this repo flags repeatedly: decorator/annotation-as-documentation isn't a security boundary (the CLI trusted collaborationInstruction as inert text, not code that would be interpolated into a docstring), and a patched CVE number doesn't mean the underlying bug is actually closed — verify against the current patched version, not just "I updated once."

Sources