system: OPERATIONAL
← back to all hacks
AGENTS CRITICAL NEW

AWS Loom agent platform: unauthenticated admin access and SSRF in MCP/A2A connectors

AWS fixed an authentication bypass and two outbound-request flaws in Loom, its open-source agent control plane, plus a command injection in SageMaker Unified Studio Spaces.

2026-10-08 // 6 min affects: aws-loom, amazon-sagemaker-unified-studio, mcp-servers, a2a-connections

What is this?

On October 2, 2026, AWS published two security bulletins covering its agent tooling. Bulletin 2026-124-AWS concerns Loom, an AWS Labs open-source platform that orchestrates AI agents, MCP tool servers and A2A remote-agent connections. Bulletin 2026-125-AWS concerns the startup script used by Studio Spaces in Amazon SageMaker Unified Studio (SageMaker Distribution images). AWS rates both “Important”. GBHackers summarised them on October 5, 2026. The bulletin credits Kenneth Cox for collaborating on coordinated disclosure of the Loom issues; the SageMaker bulletin names no reporter.

This article is a defensive summary of the vendor bulletins. It contains no exploit details beyond what AWS itself published.

How it works

The Loom issues are three distinct weaknesses in one control plane:

  1. Missing authentication. In deployments with no identity provider configured, any network client could obtain full administrative control. According to AWS, that included registering tool servers, reading stored integration credentials and rewriting IAM role policies on managed agent roles. Fixed in Loom 1.6.1 (released 2026-08-04).
  2. Credential disclosure through outbound requests. A user holding the mcp:write or a2a:write scope could make the backend send OAuth2 client secrets, or another user’s access token, to a third-party endpoint. Version 1.6.1 blocked internal addresses on this path but did not fully close the token disclosure; Loom 1.7.0 does.
  3. Internal request forgery in MCP/A2A connections. The same write scopes let a user direct the backend to arbitrary internal network locations, including the container’s credential-vending endpoint, and read the responses. Fixed in 1.7.0.

The SageMaker issue is an OS command injection in the Space startup script. The script checks network access against a project’s SageMaker connections, but connection details were not sanitized properly. A project member with contributor permissions or higher could run code in another member’s Space and, where Trusted Identity Propagation is enabled, obtain that member’s temporary execution-role credentials.

Why it matters

An agent control plane concentrates trust: it stores integration secrets, decides which tool servers agents may call, and can hold permissions to change IAM. A missing-authentication flaw there turns a network-reachable service into an administrator account, and the connector flaws show how “can register an MCP server” can become “can read credentials the platform holds”. The same pattern appears across agent infrastructure, where the component that connects to tools is itself a high-value server-side client.

Defenses

  • Upgrade Loom to 1.7.0 and patch any fork or derivative code, as AWS recommends.
  • Never expose the backend without an identity provider. Configure an Amazon Cognito user pool or an active external IdP before binding beyond loopback, and confirm LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset in every deployed environment.
  • Restrict write scopes. Limit mcp:write and a2a:write to trusted administrators (the g-admins-super, g-admins-mcp, g-admins-a2a and g-admins-demo groups). AWS notes this reduces risk but does not replace the code fix.
  • After upgrading, rotate. Rotate OAuth2 client secrets used for MCP/A2A integrations, revoke and reissue tokens active during the affected period, and if container role credentials may have been reached, rotate the IAM role’s session credentials and review CloudTrail for unexpected activity.
  • Restart SageMaker Studio Spaces. The fix is deployed globally and applies on the next Space startup. No workaround is listed. Versions on end-of-support lines (2.8.x to 2.13.x and 3.3.x to 3.8.x) have no fix and should be moved to a supported line.
  • Harden the connector layer generally: resolve and validate destination addresses at connection time, block metadata and link-local ranges, and give each agent its own narrowly scoped role.

Status

ItemStatusReference
Loom authentication bypass (versions below 1.6.1)Fixed in 1.6.1 (2026-08-04) and 1.7.0CVE-2026-103956
Loom OAuth2 token and secret disclosure (below 1.7.0)Fixed in 1.7.0CVE-2026-103957
Loom MCP/A2A internal request forgery (below 1.7.0)Fixed in 1.7.0CVE-2026-103958
SageMaker Distribution Space startup command injectionFixed in 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5, 4.4.3; 4.5.x not affectedCVE-2026-104019

Sources