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."

Update 2026-09-24 — Unit 42: AgentCore Harness's default configuration lets a prompt-injected shell tool read the vault's secrets in plaintext; AWS closed the report as "informative" under shared responsibility

Palo Alto Unit 42 published "A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity" on 2026-09-18. Finding: in AgentCore Harness's default configuration, credentials stored encrypted in AgentCore Identity are resolved into plaintext in the harness process when used, and the harness's built-in shell tool runs as root in the same process space — so a prompt injection that reaches the shell tool can read the resolved credentials and exfiltrate them. "Vaults protect at rest and in transit, not in use." This is not a CVE and there is no patch: AWS "reviewed and closed the disclosure report as informative under the AgentCore shared responsibility model, citing allowedTools scoping and egress filtering as customer-side controls." Unit 42's guidance, which this file adopts: restrict allowedTools to what a session actually needs (a shell tool is the one to remove first), apply least privilege to the Identity vault's service accounts, and monitor outbound traffic from harness containers. Status of this file is unchanged (patched, for the five CVEs above); the Unit 42 finding is a design exposure that stays open by design, in the same class as the CoreBreak tool-call-forgery entry for the same product.

Update 2026-10-07 — the Starter Toolkit's import path this time: crafted Bedrock Agent data becomes generated Python (CVE-2026-105812, 9.0) and crafted OpenAPI $refs become outbound requests and local file reads (CVE-2026-106032, 5.7); fixed 0.3.14, and AWS now calls the tool deprecated

AWS security bulletin 2026-127-AWS (2026-10-06) covers two issues in bedrock-agentcore-starter-toolkit 0.1.4 through 0.3.13, both in the agentcore import flow that turns an existing Bedrock Agent into AgentCore code:

  • CVE-2026-105812 — "Improper control of code generation in the agent import functionality … might allow an authenticated same-account actor to execute arbitrary code when a user imports and runs or deploys a Bedrock Agent, via crafted configuration values incorporated into generated Python source without safe literal encoding." The vendor GHSA (GHSA-37r5-8xpw-vxp9) rates it Critical 9.0; the CNA record carries CVSS 3.1 9.0 (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H) and CVSS 4.0 8.8. Execution is "with the privileges of either the local user or the AgentCore Runtime execution role." This is the same bug class as CVE-2026-11393 above (the collaborationInstruction triple-quote injection in the AgentCore CLI) in the Starter Toolkit's own generator — the third time in this file that agent metadata has been pasted into generated source.
  • CVE-2026-106032 — SSRF and local file read: "crafted external reference values in the OpenAPI content associated with a Bedrock Agent action group can cause unintended outbound requests and local file access during agent import." CVSS 5.7 (both versions); the importing user's environment makes the requests and reads the files.

Both need an authenticated principal in the same AWS account with permission to edit the agent's data-plane fields — a confused-deputy shape where the victim is whoever runs import next. Fixed 0.3.14; AWS says previously imported agents must be re-imported and redeployed and locally stored artefacts replaced, and both advisories note the Starter Toolkit is deprecated in favour of the @aws/agentcore npm CLI, "which does not have this vulnerability." Credit Koh Jun Sheng (@seankohjs). The bulletin index also lists 2026-126-AWS (QnABot Lambda hook, CVE-2026-105811) and 2026-125-AWS (SageMaker Distribution), both outside this file's product. Status unchanged (patched); the deprecation is the operational note — a deprecated generator that still has a PyPI release stream will keep receiving CVEs that only pip install --upgrade addresses.

Update 2026-10-11 — Zenity Labs' AgentCorruption (2026-10-08): one chat message to a public AgentCore agent returned the agent's execution-role credentials from the microVM metadata service, and the default role reached every agent, session, memory and secret in the account and region; AWS says "documented and expected," then narrowed the role

Zenity Labs (Tamir Ishay Sharbat and Lana Salameh) published a four-post series on 2026-10-08, presented at SecTor 2026 in Toronto, and The Next Web and The Register covered it on 10-08 and 10-09. This is a different finding from the Unit 42 harness-vault report above and from the five CVEs this file was opened for; no CVE was assigned.

What was found. Each AgentCore Runtime agent runs in a Firecracker microVM that exposes a microVM metadata service in the same way EC2 exposes IMDS. Any agent tool that can make an outbound request could reach it; Zenity names the Strands SDK's built-in http_request and shell tools, and says the flaw is platform-level, so any tool that generates traffic qualifies. The metadata returned the execution role's temporary STS credentials, usable from outside AgentCore, plus the container's image reference and instance tags holding certificate material and a presigned storage URL. The second half is the default execution role: scoped to all AgentCore resources in the account and region rather than to one agent, it allowed invoking other agents, reading other agents' sessions and conversation events, creating memory events, listing log groups, pulling container images, retrieving API keys and reading Secrets Manager secrets. Zenity used it to list every agent in the region, download their images and source, read conversations across agents and users, write a memory entry that made an agent fetch and follow a researcher-controlled page before answering, and pull third-party credentials from Secrets Manager.

Timeline, from Zenity's post. Report 1 (metadata access) sent 2025-12-25; AWS closed it as "informative" on 2026-04-12, citing its IMDS changes. Report 2 (the overprivileged default role) sent 2026-01-12; AWS said on 02-25 the team was working on it; the role was unchanged at Zenity's 06-22 re-review; on 09-29, during final pre-publication review, Zenity found the cross-agent invocation, conversation-read and region-wide Secrets Manager permissions removed and the role hardened. AWS says AgentCore has used IMDSv2 only since 2026-02-14, with newly deployed agents launching that way; Zenity's post does not say whether that alone closes the path, and tells readers to verify on their own agents.

AWS's position, quoted by The Next Web and in Zenity's post: "The behavior described is documented and expected." AWS says an agent can read its own execution role credentials through the metadata service by design, that cross-account access needs explicit grants on both the role and the target, and that "we recommend that customers grant their execution roles only the permissions their agents need." The Register adds that AWS said the research "inaccurately paints expected and documented behavior as a vulnerability."

What this changes for a reader. Status stays patched: the role is narrowed and IMDSv2 is enforced. What is not patched is the model of responsibility. A chat-reachable agent with any outbound-request tool is an SSRF client for the account it runs in, and the blast radius is whatever its role allows. Audit every AgentCore execution role for wildcard resources and cross-agent permissions, confirm agents deployed before 2026-02-14 were redeployed with IMDSv2, keep customer-facing and internal agents in separate accounts, and treat agent memory as attacker-writable state when any agent in the account is public.

Sources