A Perfect 10 for the Agent Control Plane: AWS's Loom Flaws Let Anyone Claim Super-Admin

On October 2, 2026, AWS published security bulletin 2026-124-AWS disclosing three vulnerabilities in Loom for AWS, the open-source AI agent orchestration platform maintained under AWS Labs. The headline flaw, CVE-2026-103956, carries a perfect CVSS v3.1 score of 10.0 — the maximum the scoring system can award. In deployments where no identity provider was configured, any unauthenticated network client could obtain full administrative authority over the agent control plane: registering malicious tool servers, reading stored integration credentials, and rewriting the IAM role policies attached to managed agent roles.

It is hard to overstate what that means in practice. The control plane of an agent orchestration platform is the layer that decides which tools agents may call, which credentials they use, and which cloud permissions they inherit. A super-admin takeover there is not a data leak — it is a transfer of the entire agentic stack to the attacker, with the victim’s AWS identity attached.

The anatomy of a 10.0

The CVSS vector string tells the whole story: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Network exploitable, low attack complexity, no privileges required, no user interaction, scope changed (the flaw crosses an authorization boundary), and total impact on confidentiality, integrity, and availability. Every factor that pushes a score up is maxed out. Affected versions span >=0 <1.6.1, meaning every release of Loom shipped before the fix was vulnerable.

The root cause is classified as CWE-306 (missing authentication for critical function) together with CWE-1188 (insecure default initialization). In other words: the authentication dependency in Loom simply did not enforce authentication on the application API when no identity provider had been set up. A related detail from the workaround guidance is telling — administrators are told to confirm that the environment variable LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset in any deployed environment. A convenience switch intended for local development, left reachable on a network-exposed backend, is the kind of default that turns a dev tool into an open door.

AWS addressed CVE-2026-103956 in Loom 1.6.1, released August 4, 2026. Credit for the coordinated disclosure goes to independent researcher Kenneth Cox.

The pair that came after: OAuth2 disclosure and SSRF

The bulletin’s other two findings are subtler but arguably just as dangerous in a multi-tenant or team setting, and both were only fully fixed in Loom 1.7.0:

CVE-2026-103957 (CWE-918, CWE-201) — an issue in Loom’s OAuth2 discovery handling. An authenticated user holding the mcp:write or a2a:write scope could configure a well-known discovery URL whose document instructed the backend to send OAuth2 client secrets — or another user’s access token — to a third-party-controlled endpoint. Notably, the 1.6.1 release had already blocked internal-address reach for this code path, but that partial fix did not stop the token disclosure. The complete fix only arrived in 1.7.0.

CVE-2026-103958 (CWE-918) — a server-side request forgery in the tool server (MCP) and remote agent (A2A) connection handling. The same privileged scopes let a user direct connection requests to arbitrary internal network locations — including the container’s credential-vending endpoint — and read the responses. On containerized AWS deployments, the credential-vending endpoint is precisely where ephemeral IAM role credentials live; SSRF against it is a direct path to assuming the workload’s identity.

The two flaws share a theme: the MCP and A2A integration surfaces — the exact protocols the agent ecosystem is standardizing on — are trusted to make outbound connections and handle OAuth2 flows, and that trust becomes a weapon as soon as a write-scoped account is compromised.

A fourth bug, next door

In a companion bulletin (2026-125-AWS) published within the same window, AWS also disclosed CVE-2026-104019, an OS command injection in the startup script of SageMaker Spaces within SageMaker Unified Studio, patched in SageMaker Distribution 4.1.11. Two bulletins, four CVEs, one theme: the AI tooling layer is now getting the kind of vulnerability attention — and producing the kind of vulnerability severity — that used to be reserved for perimeter software.

What operators should do now

AWS’s guidance is unusually concrete, and it doubles as a checklist for anyone running agent infrastructure:

1. Upgrade to Loom 1.7.0 (or at minimum 1.6.1 for the authentication bypass), and patch any forks or derivative code — since Loom is open source, AWS explicitly warns that forked copies must incorporate the fixes manually.
2. Until upgraded: ensure a Cognito user pool or an active external identity provider is fully configured before the backend is reachable beyond loopback, and restrict the mcp:write and a2a:write scopes (the g-admins-super, g-admins-mcp, g-admins-a2a, and g-admins-demo groups) to trusted administrators only.
3. After upgrading: rotate all OAuth2 client secrets configured for MCP/A2A integrations, revoke and re-issue any access tokens active during the affected window, and — if container role credentials may have been accessed — rotate the IAM role’s session credentials and review CloudTrail for unintended usage.

That last step matters because there is no way to tell, from the outside, whether a vulnerable deployment was touched. A 10.0 with no authentication requirement leaves no login trail of its own.

Why this keeps happening to agent platforms

This is not an isolated stumble. In August, research dubbed CoreBreak showed how CVE-2026-18830 in AWS Bedrock AgentCore let authenticated users execute configured tools while bypassing model invocation and its security controls — a “harness bypass” the researchers framed as a cross-platform class of agent-runtime flaws, not a one-off bug. Across the industry, flaw reports this year have hit agent guardrails, MCP tool proxies, and coding-agent sandboxes with increasing regularity.

The structural reason is straightforward. Agent orchestration platforms concentrate three things behind one API: credential storage, identity escalation, and network egress. Classic applications separate those concerns across tiers; agent platforms collapse them so a model can act. The result is that a single missing authentication check — CWE-306, one of the oldest weakness classes in the book — now yields a 10.0 instead of a 7.

The timing sharpens the point. This week alone has seen a wave of “decision model” launches built on agent infrastructure (Cloudflare’s Clef, Perplexity’s Decisions API with its open pplx-decider-v1-27b, Amazon’s own Strands Decider 2B), Microsoft’s Digital Defense Report concluding that AI has already tipped the near-term cyber advantage to attackers, and Apple tightening macOS Full Disk Access explicitly because of AI agent risk. The industry is wiring agents into everything at the same moment its security foundations are being stress-tested.

For teams building on Loom, the message is direct: this is a patch-now, rotate-everything event, not a read-and-file advisory. For everyone else shipping agent platforms, CVE-2026-103956 is the cleanest demonstration yet that in agentic architectures, “no identity provider configured” must never silently mean “everyone is an administrator.” The perfect score exists precisely because the failure mode is perfect: no credentials, no interaction, complete compromise.