Amazon Web Services published security bulletins on October 2 disclosing four vulnerabilities across two of its AI agent products: Loom for AWS, an AWS Labs open-source platform for orchestrating AI agents and the tool servers they call, and Amazon SageMaker Unified Studio, the managed environment where data teams build and deploy models and agents together. Three of the flaws sit in Loom; the fourth is a command injection bug in SageMaker's workspace startup process.
The headline flaw, tracked as CVE-2026-103956, is as severe as the scale allows: 10.0 under both CVSS 3.1 and CVSS 4.0. In any Loom deployment without an identity provider configured, the authentication dependency let any network client obtain super-admin authority over the agent control plane. From there, an attacker could register malicious tool servers the platform would then trust, read stored integration credentials, and rewrite the IAM role policies attached to managed agent roles.
Those three capabilities compound. Registering a tool server means the attacker decides what every agent can call. Reading credentials hands over the keys to whatever the deployment was wired into, from calendars and ticketing systems to internal APIs. Rewriting IAM policies means the breach can outlive the patch, because privileges granted during the window persist in the account afterwards. AWS classified the issue under CWE-306 (missing authentication for critical function) and CWE-1188 (insecure default initialization of resource permissions).
There is an unusual detail in the timeline. The fix for CVE-2026-103956 landed in Loom 1.6.1, released on August 4 — roughly two months before the CVE was published on October 2 at 19:16 UTC. Teams that happened to upgrade in the ordinary course of things were protected without knowing it; teams that pinned a version, the disciplined choice, were exposed for two months with no advisory to act on. AWS's bulletin nonetheless directs users to 1.7.0, not 1.6.1, because the two sibling flaws in the same bulletin require the higher release. The company also notes that forked or derivative deployments must be patched separately.
The second flaw, CVE-2026-103957, concerns unsafe OAuth2 discovery processing. An authenticated user holding the mcp:write or a2a:write scope could configure a malicious well-known discovery URL that makes the backend disclose OAuth2 client secrets, or another user's access token, to an attacker-controlled endpoint. The 1.6.1 release blocked access to internal addresses through this route but did not fully stop token disclosure; 1.7.0 closes it completely.
The third, CVE-2026-103958, behaves like a server-side request forgery. A user with the same scopes could force Loom's MCP tool-server or Agent2Agent remote-agent logic to connect to arbitrary internal destinations and return the responses, exposing data from a container credential-vending endpoint and potentially yielding temporary AWS credentials tied to the deployment's IAM role — the same category of metadata-endpoint theft that has driven some of the most damaging cloud breaches of recent years, now reachable through an agent platform's own request handling.
The fourth bug lives in SageMaker Unified Studio rather than Loom. CVE-2026-104019 is an OS command injection in SageMaker Space startup scripts, caused by insufficient sanitization of SageMaker connection details during startup validation. A project member could craft malicious connection data and execute arbitrary code inside another member's Space, breaking the tenant isolation a shared data science environment depends on. In projects with Trusted Identity Propagation enabled, a contributor-level user could obtain another member's temporary execution-role credentials and invoke downstream services on that user's behalf. Fixes shipped in SageMaker Distribution 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 and 4.4.3; 4.5.x is not affected, and users are told to restart affected Studio Spaces so the patched images take effect.
AWS's mitigation guidance goes beyond version bumps: configure a Cognito user pool or an external identity provider before exposing Loom beyond loopback access, make sure LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is not enabled in production, rotate OAuth2 client secrets, revoke and reissue tokens issued during the exposure window, rotate potentially exposed IAM session credentials, and review CloudTrail logs for suspicious activity. The broader lesson is structural. Agent control planes concentrate identity, stored credentials and dynamic tool discovery in one layer, so a single missing setting — not even a misconfiguration, just an absent one — can cascade into full account compromise. The deployments most exposed to this class of bug are the newest, fastest-moving pilots, precisely the ones least likely to have identity providers wired up on day one.
Comments (0)
Log in to join the discussion
Log InNo comments yet