Loom for AWS handed full agent control to anyone without an identity provider

2 October 2026. AWS publishes two security bulletins closing four flaws in Loom, its open-source AI agent orchestration platform, and in Amazon SageMaker Unified Studio. 2 October 2026. The most severe, CVE-2026-103956, lets any network client take full administrative control of the agent control plane whenever no identity provider is configured. 2 October 2026. Three further flaws expose OAuth2 secrets, temporary AWS credentials and code execution in another user’s workspace. Why it matters: the agent-orchestration layer — MCP and A2A — has become an attack surface in its own right, and the missing-authentication default is the clearest symptom of how young it is.

An agent platform shipped without authentication by default

Loom is AWS’s agent orchestrator: it connects MCP (Model Context Protocol) tool servers and remote A2A (Agent2Agent) agents to a central control plane that holds integration credentials and the IAM roles of the agents. CVE-2026-103956 strikes this core. It affects versions before 1.6.1 and stems from a flaw in the authentication dependency: when the deployment references no identity provider, any network client can seize the control plane.

The consequences are mechanical. An attacker can register malicious tool servers, read stored integration credentials, and modify the IAM role policies attached to managed agents. AWS classifies the flaw under CWE-306 — missing authentication for a critical function — and CWE-1188 — insecure default initialisation of resource permissions. In other words, the defect is not a subtle buffer overflow: it is a product that boots wide open until you wire in a directory. For an orchestrator that holds the keys to your agent fleet, that default is roughly equivalent to shipping a database with no root password.

Three flaws that follow the agent chain

The other three CVEs trace the exact path of an escalation inside an agent platform.

CVE-2026-103957 concerns OAuth2 discovery. An authenticated user holding the mcp:write or a2a:write scope can point the backend at an attacker-controlled well-known discovery URL, causing the backend to send OAuth2 client secrets or another user’s access token to that endpoint. The 1.6.1 fix blocked internal addresses on this path without eliminating token disclosure; only 1.7.0 fully closes it.

CVE-2026-103958 is an SSRF-style flaw in the connection logic of MCP tool servers and remote A2A agents. A user with mcp:write or a2a:write can force the platform to connect to arbitrary internal destinations and return their responses — including the container credential-vending endpoint, which issues temporary AWS credentials usable within the affected role’s permissions.

CVE-2026-104019 leaves Loom for SageMaker Unified Studio. It is an OS command injection in SageMaker Space startup scripts, caused by poor sanitisation of connection parameters. A project member can craft connection details that execute code inside another member’s Space. With Trusted Identity Propagation enabled, exploitation lets a contributor obtain another member’s temporary execution-role credentials and call downstream AWS services on their behalf.

The lesson extends beyond AWS

The thread running through these four flaws is not a product but a pattern. Agent platforms expose three surfaces that classical applications had learned to close: control-plane authentication, OAuth2 token handling between components, and outbound calls from a component into the internal network. Loom accumulates all three, and it does so on an MCP / A2A base that many teams reuse as-is in their own agents.

The missing-authentication default is the most instructive. A variable like LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV exists precisely for local-loop development — and AWS recommends verifying it is not set in production. This kind of toggle, which makes a convenient local mode dangerous in production, is becoming the signature of agent tooling. ETTAYEB has already documented the same risk on the MCP Python SDK side with OAuth credential theft — the repetition confirms the problem is structural, not circumstantial. What was once a niche concern for tool authors is now a default-posture question for every platform team that lets an agent reach production.

What to do

Remediation is twofold: upgrade, then clean up the traces.

• 1. Move Loom to 1.7.0. This is the release that closes CVE-2026-103957 and CVE-2026-103958 on top of CVE-2026-103956. Forks and derivative deployments must apply the same fixes.
• 2. Wire in an identity provider before exposing. AWS recommends requiring a Cognito user pool or an active external identity provider before exposing Loom beyond loopback.
• 3. Check the development variable. Ensure LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is not set in production.
• 4. Restrict write scopes. The mcp:write and a2a:write scopes should be reserved for trusted administrators.
• 5. Clean up after upgrading. Rotate OAuth2 client secrets, revoke and reissue tokens active during the exposure window, rotate any potentially touched IAM role session credentials, and review CloudTrail for suspicious activity.

For SageMaker, restart the affected Studio Spaces to load the patched images — versions 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 and 4.4.3 are fixed, and the 4.5.x branch is not affected.

The AI agent becomes a supply chain

The deepest point in these bulletins is that the AI agent has stopped being an isolated tool and become a supply chain: an orchestrator, MCP tool servers, remote A2A agents, each carrying its own tokens, secrets and privileges. Every link that connects to another is a trust boundary, and Loom shows what happens when those boundaries are not treated as such.

The parallel with the classic software supply chain is instructive. Where a malicious npm package exfiltrated secrets at install time, a malicious MCP tool server exfiltrates them at execution time — and can additionally reach the credentials of the container that hosts it. The fix is not only about patching Loom; it is about recognising that agents plugging into a control plane are runtime dependencies, not trusted extensions.

That has concrete consequences for how teams should review agent code. A tool server that receives a well-formed request is already inside your perimeter: it can read whatever the agent can read, and it can ask the orchestrator to connect elsewhere on its behalf. The scopes mcp:write and a2a:write are not mere permissions — they are the keys to lateral movement through every internal endpoint the orchestrator can reach. Treating them as such means inventorying every tool server, rotating their credentials on the same schedule as production services, and refusing the convenient default of running an agent platform wide open during the prototype phase, because prototypes have a way of becoming production.

Verdict

If you run Loom, move to 1.7.0 and wire in an identity provider before anything else — the software fix alone is not enough if your deployment remains without a directory. If you build your own agents on MCP or A2A, treat these four CVEs as a checklist for your own platform: authenticate the control plane by default, lock down OAuth2 discovery, and forbid outbound connections to internal credential endpoints. The clearest signal in these bulletins is that AWS itself had to patch its agent orchestrator three times in four months — the agent attack surface is real, and it will not close on its own.

References

• AWS Security Bulletin 124 — Loom for AWS (2 October 2026)
• AWS Security Bulletin 125 — Amazon SageMaker Unified Studio (2 October 2026)
• Cyber Press — AWS Fixes Critical Loom and SageMaker Flaws
• SecurityOnline — Loom for AWS and SageMaker Unified Studio Flaws Fixed