Amazon Bedrock AgentCore: flaws that expose AWS credentials

Between late September and early October 2026, three pieces of research showed how agents built on Amazon Bedrock AgentCore, the AWS service for running artificial intelligence agents, could hand an attacker the AWS credentials of their execution role. The common thread is not a single flaw but a combination of three elements: an agent that can run commands or generate traffic, credentials reachable from the environment it runs in, and broader permissions than it needs.

What happened

• Two CVEs in the Python SDK (BeyondTrust). According to Infosecurity Magazine, reporting on research BeyondTrust published on 28 September, the Code Interpreter helper that installs Python packages turned a crafted package name into a shell command executed inside the sandbox. From there the researchers read the temporary credentials of the execution role.
• “AgentCorruption” (Zenity Labs). According to CSO Online, which received the report in advance, the researchers simply asked an agent for its credentials and got them. Dark Reading describes the now-patched flaw as a way to put an organisation’s entire AWS environment at risk starting from a single chatbot.
• AgentCore Harness (Palo Alto Networks Unit 42). On 18 September Unit 42 reported that, in the default configuration, the built-in shell tool, enabled by default and running as root, reaches the memory where credentials managed by AgentCore Identity are resolved to plaintext: with a prompt injection, an attacker can get the agent to exfiltrate them.

Technical details

CVE-2026-12530 affects the AgentCore Python SDK from version 1.1.3 to 1.6.0: an incomplete character blocklist allowed the package name check to be bypassed. AWS fixed it in 1.6.1 with a stricter validation rule, but BeyondTrust bypassed that too: CVE-2026-16796, which AWS lists for all versions before 1.18.1, used pip’s extras syntax to smuggle shell commands through. The fix is in 1.18.1. AWS scored both 7.3 under CVSS 3.1 and 8.4 under CVSS 4.0.

According to BeyondTrust, the Firecracker isolation of the sessions held: the weak point was the SDK helper. Three conditions were required: attacker-influenced input reaching install_packages(), a vulnerable SDK version, and a custom Code Interpreter with an execution role attached. The input can come from user-supplied package names, untrusted content processed by the agent, or dependency files in an untrusted repository. In AWS logs, BeyondTrust warns, the attacker’s activity can look like legitimate application activity.

In the chain described by Zenity, the agent reached the instance metadata service (IMDS) and returned a full set of temporary STS credentials (access key ID, secret access key and session token) that also worked from a machine outside AgentCore. Removing the agent’s HTTP tool was not enough: the isolation failure was at platform level, and the result was reproduced with other tools, including the Strands built-in shell tool. With ECR read permissions the researchers pulled the agent’s image, with its code and dependencies; since AgentCore names each repository bedrock-agentcore-<agent_name>, within seconds they retrieved the code of every agent in the region. The default role held read, write and delete permissions on various AgentCore and AWS services in the region: invoking other agents, reading conversations, poisoning memory to persist, harvesting credentials and API keys, running destructive actions.

Back in April, Unit 42 had reported that AgentCore Runtime used a microVM Metadata Service (MMDS) without session token enforcement: before AWS’s fixes, an SSRF could have been enough to extract credentials.

Indicative MITRE ATT&CK mapping, based on the reported facts: T1059 (Command and Scripting Interpreter), T1552.005 (Unsecured Credentials: Cloud Instance Metadata API), T1078.004 (Valid Accounts: Cloud Accounts).

Fix status and diverging positions

• For the two SDK CVEs, the fix is version 1.18.1 or later.
• Zenity reported the issues to AWS on 25 December 2025. On 14 February 2026 AWS moved AgentCore to IMDSv2 only, closing the initial vector, but on 22 June the default role’s permissions were unchanged. According to Zenity they were fixed between 22 June and 29 September; as of 8 October the attack path was no longer exploitable.
• Unit 42’s report on AgentCore Harness was closed by AWS as “informative” under the shared responsibility model.
• AWS maintains that Zenity’s research presents expected, documented behaviour as a vulnerability, and recommends granting execution roles only the permissions their agents need.

Impact for European and Italian companies

Anyone using AgentCore for customer- or employee-facing agents is exposed in proportion to the execution role’s permissions: stolen credentials do not stay in the sandbox. If the conversations or keys involved concern personal data, a breach assessment under the GDPR is needed. For NIS2 entities, cloud AI agents fall within the Article 21 measures: access control, supply chain security, vulnerability handling. The sources agree on one point: isolation is the platform’s job, but permissions are the customer’s responsibility.

What to do now

1. Update the AgentCore Python SDK to 1.18.1 or later in projects, pipelines and images.
2. Do not pass untrusted or model-generated package names to install_packages(), as AWS recommends.
3. Replace the default execution role with a per-agent role holding only the permissions it needs; no role at all where the code does not need AWS services.
4. Review the built-in tools: disable the AgentCore Harness shell tool and HTTP tools where they are not needed, and treat the remaining ones as high-risk.
5. Restrict agents’ outbound traffic and keep secrets out of images.
6. Watch the activity: monitor the Code Interpreter, baseline each agent’s identity and tool usage so anomalies stand out, and search AWS logs for use of agent role credentials outside their usual environment.

Last updated: 8 October 2026