At SecTor 2026 in Toronto, researchers Tamir Ishay Sharbat and Lana Salameh of Zenity Labs detailed a flaw they termed AgentCorruption. The attack relies on SSRF, a technique where an application is manipulated into making unauthorized requests to internal resources. In this case, a single prompt to a public-facing AWS Bedrock AgentCore agent allowed an attacker to query the Instance Metadata Service (IMDS) at 169.254.169.254. Because the underlying Firecracker MicroVMs lacked sufficient network isolation, the agent could reach the metadata endpoint and retrieve temporary AWS credentials.
The technical chain is straightforward, but the consequences were amplified by default configuration choices. The default execution role for AgentCore was overprivileged, scoped to all resources within an entire AWS account and region rather than being restricted to the specific agent. This meant that once an attacker obtained the credentials for one agent, they effectively held the keys to the entire environment. The stolen credentials allowed for a range of actions: invoking any other agent in the region, reading private conversations, pulling ECR container images to steal source code, and retrieving sensitive data from AWS Secrets Manager.
Perhaps the most significant risk is memory poisoning. By using the CreateEvent function on BedrockAgentCoreMemory, an attacker can implant instructions that persist across sessions. This creates a scenario where users interact with what appears to be a trusted enterprise agent, while the agent is actually operating under attacker-controlled instructions. This is a persistent hijack, distinct from the transient nature of many other cloud-based attacks.
It is important to distinguish this from CoreBreak, which was previously covered on Forkast. While CoreBreak (CVE-2026-18830) involved the InvokeHarness API and bypassed model guardrails, AgentCorruption is an infrastructure-level issue. One concerns the model’s logic; the other concerns the platform’s identity and access management.
The response from AWS highlights a recurring tension in cloud security. When initially reported on December 25, 2025, AWS characterized the behavior as documented and expected, stating that agents can access credentials for their own execution role through the metadata service. However, the company subsequently shipped hardening measures. They made IMDSv2 the default for new deployments on February 14, 2026, and on September 29, 2026, they significantly reduced the permissions of the execution role, removing access for cross-agent invocation, conversation reading, and Secrets Manager access. As noted by The Register in its Oct 9 coverage, this characterization of the issue as merely documented behavior did not align with the scenario Zenity described.
The nine-month window between the initial report and the final permission reduction raises questions about the security posture of agents deployed during that period. While no CVE was issued and there is no evidence of in-the-wild exploitation, the delay underscores the risks inherent in relying on default configurations.
This incident fits into a broader pattern of trust-through-defaults, where systems ship with permissive settings that prioritize ease of use over security. We have seen this dynamic repeatedly, from Splunk Patroni and SonicWall SMA 1000 to the Ships Without Auth pattern. AgentCorruption is simply the latest iteration of this pattern, applied to AI agents.