October 13, 2026

Also available as markdown

An open memory drawer where three cracked, compromised cards send red threads into an AI agent's network, turning the nodes they touch red.

Your AI Agent's Memory Is the New Backdoor. AWS Says It's Not a Vulnerability.

Executive Summary

On October 8th, Zenity Labs published AgentCorruption, a five-part research series on Amazon Bedrock AgentCore, and presented it at SecTor 2026 in Toronto. It starts with one prompt to one public-facing agent. It ends with the researchers reading private conversations across every agent in the same AWS account and region, pulling agent container images and source code, invoking internal agents they were never meant to reach, taking secrets out of Secrets Manager, and planting a memory that quietly steers an agent before every answer.

The memory step is the part to pay attention to. Credential theft is an incident. A planted memory is a backdoor. It survives the session that created it, it doesn't show up in a vulnerability scan, and the attacker can change what it does without ever touching it again.

AWS disputes the framing. In statements to The Next Web and Dark Reading, an AWS spokesperson said the research "inaccurately paints expected and documented behavior as a vulnerability." There's no CVE and no AWS security bulletin for it. AWS did change things along the way. New AgentCore agents have launched IMDSv2-only since February 14th, and Zenity says the default execution role was narrowed by September 29th. Zenity describes the issues as patched.

Whoever's right about the label, the execution role, the network path to the metadata service, and the memory store all sit in your account. That makes the defense yours.

One prompt, one agent, one account

The chain is short, and every link is ordinary.

  1. A normal tool. The target was a public-facing agent with a tool that can make web requests. That's a common, expected capability.
  2. An ordinary request. The researchers asked the agent, in plain language, to fetch data from the instance metadata service (IMDS) at 169.254.169.254.
  3. No network isolation. Per Zenity, AgentCore agents run in Firecracker microVMs that didn't block that traffic, so the agent returned the temporary credentials for its own execution role. Zenity says it got the same result through other tools, including a shell tool.
  4. A broad default role. The researchers then used those credentials from their own machine. The default role AgentCore attached to agents covered AgentCore resources across the whole account and region. With it, they listed every agent, pulled container images and source code, invoked internal agents, read private conversations, and retrieved API keys and other secrets from Secrets Manager, including credentials for services outside AWS.
  5. Persistence through memory. The same role could write to memory resources across the region. The researchers wrote a fake conversation event that AgentCore's memory system extracted into a lasting user instruction: visit an attacker-controlled page before every answer and follow what it says. By editing that page, they could change the agent's instructions at any time without planting a new memory. In Zenity's demo, a user kept chatting with the agent while it sent the conversation to the researchers' server.

Note what the prompt did and didn't do. The prompt got the credentials. The credentials did everything else, including the memory write. That matters for defense, because it means the fix isn't only about prompt filtering.

The IMDS access is the entry point. The broad execution role is the blast-radius amplifier. The memory store is the persistence mechanism. Take away any one of them and the chain gets much weaker. Take away the memory write and you're left with a one-time exfiltration instead of a standing foothold.

Memory is a code path, not just a data store

AgentCore memory has two layers. Short-term memory is the conversation itself. Long-term memory holds what the configured strategies extract from those conversations: facts, user preferences, summaries, and episodes. An agent retrieves those records and uses them to shape its next answer.

That's the useful part. It's also the dangerous part. Zenity's memory write-up shows the attacker didn't need to overwrite a long-term record directly. They only needed bedrock-agentcore:CreateEvent on memory/*. They wrote a short-term event framed the right way, and the memory strategy did the rest, turning it into something the agent believed the user wanted.

If a record can change what the agent does before every future interaction, it's not just data. It's instructions. Treat writes to it the way you'd treat writes to a config file or a system prompt.

What got patched, what didn't

AWS had two very different agent security stories in early October. If you only read the headlines, it's easy to mix them up.

Patched, with CVEs. On October 2nd, AWS published two security bulletins covering four CVEs.

Bulletin 2026-124-AWS covers Loom for AWS, an AWS Labs open-source agent orchestration platform:

  • CVE-2026-103956 (authentication bypass, CWE-306 / CWE-1188). In Loom before 1.6.1, with no identity provider configured, any network client could get full administrative authority over the agent control plane, including registering tool servers, reading stored integration credentials, and rewriting IAM role policies attached to managed agent roles. Fixed in 1.6.1, released August 4th, 2026.
  • CVE-2026-103957 (OAuth2 token and credential disclosure, CWE-918 / CWE-201). A user with the mcp:write or a2a:write scope could point a well-known discovery URL at a third-party endpoint and get the backend to send it OAuth2 client secrets or another user's access token. Version 1.6.1 blocked internal-address reach for this path but didn't fully close the disclosure. Fully fixed in 1.7.0.
  • CVE-2026-103958 (outbound request handling, CWE-918). The same scope holder could direct MCP tool-server and A2A remote-agent connections to internal network locations, including the container's credential-vending endpoint, and read the responses. Fixed in 1.7.0.

AWS credits Kenneth Cox for coordinated disclosure on the Loom issues.

Bulletin 2026-125-AWS covers SageMaker Unified Studio:

  • CVE-2026-104019 (OS command injection in the SageMaker Space startup script). Improper sanitization of connection details during a startup network check could let code run in another project member's Space. With Trusted Identity Propagation enabled, a project contributor or higher could get another member's temporary execution-role credentials. AWS deployed a global fix that applies to Spaces on their next restart. The fixed SageMaker Distribution versions are 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5, and 4.4.3. Lines 2.8.x through 2.13.x and 3.3.x through 3.8.x are end of support and have no fix.

Disputed, no CVE. AgentCorruption sits in a different place. There's no CVE, no bulletin, and nothing for a customer to install. AWS's statement to Zenity says "the behavior described is documented and expected" and that "AgentCore agents can access the credentials for their own execution role through the metadata service." It adds that an agent can reach resources in another AWS account only if the developer grants permissions on both the execution role and the target resource, and it recommends granting execution roles "only the permissions their agents need."

Two details are worth holding onto. First, Zenity's chain stayed inside one account and region, so the cross-account point doesn't really answer it. Second, AWS did change its defaults. IMDSv2-only for new agents since February 14th helps against simple fetch-only tools, but a tool that can send a PUT with custom headers can still get a session token. And IMDSv2 does nothing about memory writes made with credentials that are already stolen.

Why the split matters for your program. The CVE'd flaws are a patch-management problem. A scanner can find them and a version bump closes them. AgentCorruption is an architecture problem. It shows up only as configuration: what the role allows, what the agent can reach, and who can write to memory. Different teams, different processes, different evidence.

The pattern isn't new

Cloud security has been here before. The details differ, but the gap between what a vendor fixes and what the customer still owns keeps showing up in the same places.

Metadata services. IMDS has been the first stop after an SSRF for years. Zenity's Tamir Ishay Sharbat pointed to the 2019 Capital One breach in his SecTor talk. AWS's own SSM Agent had a version of it last month. CVE-2026-89049, published September 10th, let an authenticated user with port-forwarding permission use an alternate representation of a denied link-local address to get past the remote-destination denylist and potentially obtain the instance's temporary IAM role credentials. AWS fixed it in SSM Agent 3.3.4851.0. That one got a CVE and a patch. The lesson is the same either way: anything that can make requests from inside the workload can reach the credentials unless you block it.

AI gateways and "working as intended." LiteLLM's MCP auth bypass, CVE-2026-59822, let a fabricated Authorization header reach MCP tooling without a valid key. It's fixed in 1.84.0, and CISA added it to the KEV catalog on September 2nd. Wiz's research found that 9.6% of 3,074 public LiteLLM instances it scanned in February accepted the default sk-1234 master key or required no authentication at all. Wiz also showed that LiteLLM's pass-through endpoints could be pointed at the metadata service, even with IMDSv2. That feature isn't considered a vulnerability and wasn't fixed. It's the closest parallel to AgentCore: a documented feature that becomes an attack path once someone gets in.

Mitigations aren't fixes. In late September, Google's Mandiant and GTIG reported that ShinyHunters (UNC6240) had started using URL-encoded paths such as /%50SEMHUB/ to get past WAF rules blocking the vulnerable PeopleSoft /PSEMHUB/ endpoint, as BleepingComputer reported. Mandiant's advice was to install Oracle's update rather than rely on WAF rules. A stopgap control held until the attacker spent a little effort on it.

The common thread: the vendor ships the platform and the patches, and the customer owns the configuration that decides how far one mistake can go.

AI Governance remains the focus

Standards bodies are starting to write this down. On October 9th, the PCI Security Standards Council published Security Considerations for AI Systems. It's advisory, and existing PCI requirements take precedence, but it lines up closely with what AgentCorruption exposed.

  1. Least agency. The guidance limits each AI system to the access and capabilities its assigned tasks need. The AgentCore default role was the opposite: one agent's identity could act on every agent in the region.

  2. Don't combine the dangerous three. PCI SSC recommends against putting sensitive data access, external communications, and unrestricted input from untrusted sources in one AI system, and suggests splitting those duties across agents with different permissions when a workflow needs all three. Zenity's target agent took untrusted input from the public, could make outbound web requests, and ran under a role that reached Secrets Manager and memory. That's all three.

  3. Independent controls. The guidance says access restrictions should be enforced through independent controls, such as identity policies and network isolation, not by the AI itself. A prompt filter wouldn't have stopped this chain. A network block on the metadata address and a scoped role would have.

  4. A human owns the output. A suitable human should formally accept responsibility for AI output, and agents with access to cleartext cardholder data should get explicit human approval for actions involving that data. If you can't name the person who owns an agent's role and memory, start there.

  5. Test the safeguards first. PCI SSC recommends adversarial testing of controls before extensive functional testing, plus ongoing monitoring for behavior changes. A planted memory is exactly the kind of behavior change that monitoring should catch.

What to do

  1. Patch the CVE'd agent tooling first. If you run Loom for AWS, upgrade to 1.7.0, configure an identity provider before exposing it beyond loopback, then rotate OAuth2 client secrets, reissue tokens, and review CloudTrail as AWS's bulletin recommends. If you use SageMaker Unified Studio, restart your Spaces so the patched images apply, and move off the end-of-support lines. Update SSM Agent to 3.3.4851.0 or later and LiteLLM to 1.84.0 or later, and change any default LiteLLM master key.

  2. Give every agent its own least-privilege execution role. Don't run production agents on a default role. Scope each role to that agent's own runtime, memory, log groups, and secrets, using specific resource ARNs instead of wildcards. If your role was auto-created before Zenity's September 29th check, compare it with the current default and with what the agent actually uses.

  3. Block the metadata service from agent tools. Require IMDSv2, but don't stop there. Put HTTP-capable tools behind an egress allowlist that denies 169.254.169.254 and other link-local and internal ranges. If an agent doesn't need its own credentials from inside a tool call, make sure no tool can fetch them. Check agents deployed before February 14th first.

  4. Scope memory writes. CreateEvent and DeleteEvent on memory/* let one stolen identity rewrite every agent's memory in the region. Limit each role to its own memory resource. Keep memory-write permissions off any identity that also handles public input or makes outbound requests. For high-impact agents, route new long-term instructions through review instead of letting them land automatically.

  5. Audit and review memory. Pull the long-term records for your agents and look for anything that reads like a standing order: "always," "before responding," "no matter what I ask," or an embedded URL. Alert when memory events are written by an identity, or from an IP address, that isn't your agent runtime. Make memory review part of incident response, because rotating credentials won't remove a planted instruction.

  6. Watch for credentials used from the wrong place. In Zenity's chain, the execution role's credentials were used from the researchers' own machine. Alert when an agent role is used from outside your AWS environment, and when it calls APIs like ListEvents, InvokeAgentRuntime, or GetSecretValue against resources that aren't its own.

  7. Treat a clean scan as a starting point, not an approval. There's no CVE, signature, or version number for this chain. The evidence is in role policies, network paths, and memory records, so put those on your review checklist alongside the scanner output.

Sources