All posts
Unproven Execution

AgentCore Vault Heap-View: Shell Shares Memory With Creds

Unit 42 showed AWS AgentCore Harness's default shell shares memory with the Identity vault, letting a support-ticket injection exfiltrate a live JWT

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
aws-agentcore unproven-execution prompt-injection nhi bedrock shared-responsibility

The Incident

On September 18, 2026, Palo Alto Networks Unit 42 published “A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity,” a controlled demonstration against AWS Bedrock AgentCore Harness showing that a prompt injection delivered inside a customer-support ticket drives the agent to read a live JSON Web Token out of the harness process’s own memory and POST it to an attacker-controlled endpoint. The root cause is architectural, not a bug fix away: the Harness’s built-in shell tool runs as root inside the same process where AgentCore Identity decrypts and holds OAuth and workload credentials for downstream SaaS and AWS calls. A legitimate shell call therefore has heap-view visibility into the Identity vault. In Unit 42’s write-up, the attacker never possessed AWS credentials of their own — a single poisoned ticket, consumed by the agent, was sufficient to lift the token.

AWS reviewed the disclosure under the AgentCore shared-responsibility model and closed it as informative, declining to assign a CVE or ship a code fix. The documented customer-side control is to scope allowedTools on each InvokeHarness call and to constrain network egress. The Cloud Security Alliance posted an independent corroborating research note dated September 19, 2026, which situates this as the third publicly disclosed 2026 AgentCore weakness after Agent God Mode and an earlier sandbox-escape / DNS-tunneling issue.

The heap-view vector is distinct from two already-tracked AgentCore CVE lines. CVE-2026-18830 (CoreBreak, AWS Security Bulletin 2026-073-AWS, CVSS v4 8.6) is tool-use-block forgery against the managed InvokeHarness and does not touch the Identity vault — SecurityV0 covered that on August 15, 2026. CVE-2026-12530 (BeyondTrust’s finding in the bedrock-agentcore Python SDK, AWS Security Bulletin 2026-044-AWS dated June 17, 2026) is a shell-command injection via a newline in a package name inside the Code Interpreter sandbox, first patched in 1.6.1. CVE-2026-16796 (AWS Security Bulletin 2026-065-AWS dated July 23, 2026) is the follow-on bypass of that fix, definitively addressed in 1.18.1. Neither SDK CVE describes heap-view credential theft, and the Unit 42 vector has no CVE at all.

MITRE ATT&CK coverage: T1552.004 (Unsecured Credentials: Private Keys — credential material lifted from process memory) for the exfiltration, and T1059 (Command and Scripting Interpreter) for the shell step.

The Authority Path That Failed

The identity carrying execution authority at the moment of failure was the AgentCore Harness process — a workload NHI running with the operator-attached AgentCore Identity grants. The scope that process held was its full built-in toolbelt (root shell among them) plus in-process access to the Identity vault that holds decrypted OAuth and workload tokens for every downstream API the agent is wired to call. The scope it exercised, steered by a hidden instruction in a legitimately-triaged ticket, was: read process memory, locate a live JWT, POST it externally. Those are the exact tool primitives the harness ships enabled; from the harness’s own point of view, nothing out of the ordinary happened.

The trust anchor that failed first is the architectural co-location: the vault and the shell live in the same process. Any tool with shell-equivalent authority — attached by default — can read the vault without going through the vault’s own API, which means every Identity grant is effectively ambient to anything in the toolbelt. Unit 42 reports that allowedTools is enforced on each InvokeHarness, so an operator who scoped tools once at CreateHarness and did not re-pass the restriction on invocation gets the default toolbelt at runtime. The gap between held and exercised authority is a pre-deploy, static property of the harness: a tool with heap-view authority over a credential vault is installed before the first ticket arrives, and the deploying operator never attested that specific grant.

SecurityV0 Perspective

This is unproven_execution at the managed-runtime layer. The Langflow CSV Agent + Python REPL case fit the same class because the framework attached a code-execution tool the operator never explicitly authorized; AgentCore Harness generalizes the pattern — the operator wired up an agent that triages tickets, and the managed runtime silently attached a root shell co-located with the credential vault, exceeding any scope the operator could have attested to. The AgentCore product family has now produced three orthogonal unproven-execution failure modes in under two months (CoreBreak’s tool-call forgery, the BeyondTrust SDK command-injection pair, and this vault heap-view), and SecurityV0’s thesis is unchanged across all three: operators need an evidence pack describing what authority a harness actually resolves at invocation, not what they configured at creation.

The evidence pack for this finding would show the resolved tool manifest at InvokeHarness time (not at CreateHarness), the process-isolation boundary between every tool and every live credential store, and a boundary alert when a tool with shell-equivalent authority is loaded into the same process as a decrypted vault. Pre-exfiltration it answers “which agents in production have a tool that can read the heap of the process holding our OAuth tokens?” Post-exfiltration it answers “which agent invocations had the harness’s shell tool enabled during the window the Identity vault held tokens we now need to rotate?”

What To Do

  • Scope allowedTools on every InvokeHarness call, not just at CreateHarness. Per Unit 42, enforcement is at invocation; a scoping decision made only at harness creation does not survive to runtime. Treat allowedTools as a per-call argument that must be set from a vetted allow-list on every call, and reject calls your gateway sees without it.
  • Remove the built-in shell from every AgentCore Harness that triages untrusted input. If an agent reads customer-support tickets, PR descriptions, email bodies, or web content, it is reading attacker-controllable text; a shell tool co-located with the Identity vault turns any of that text into a credential-exfiltration primitive. Replace the shell with a narrowly-scoped tool per task.
  • Rotate every AgentCore Identity grant held by a harness that ran with the default toolbelt against untrusted input. Enumerate the OAuth tokens and workload credentials AgentCore Identity has vended into each harness; for any harness whose runtime toolbelt included shell-equivalent authority while handling attacker-controllable content, rotate the full set and audit downstream calls those identities authorized during the exposure window.
  • Constrain network egress at the harness VPC and at AgentCore’s outbound filter. AWS’s own stated mitigation is egress filtering; a POST to an attacker webhook only lands if the harness can reach it. Pin egress to the explicit set of SaaS endpoints each agent is justified to call, and alert on destinations outside that set — the alert surfaces the exfiltration attempt even when the shell call itself looks ordinary.
  • Add a per-harness pre-deploy check that the resolved tool manifest at InvokeHarness time does not include a tool with shell-equivalent authority in the same process as a live credential vault. This is the SecurityV0 evidence pack and it is the only check that catches the class — static SBOM scans, prompt-injection filters, and CVE feeds all miss it because the architecture is working as designed.

Sources

All posts