AWS Loom AI Agent Platform Flaw Handed Unauthenticated Attackers Super-Admin Control Over Agents, Credentials and IAM Policies

Amazon Web Services has disclosed three vulnerabilities in Loom for AWS, the open-source AWS Labs platform that organisations use to deploy and govern AI agents, MCP tool servers and agent-to-agent (A2A) integrations on Amazon Bedrock AgentCore. The most serious, CVE-2026-103956, carries a CVSS 3.1 base score of 10.0 in the project's GitHub advisory: on any Loom backend running without a configured identity provider, every incoming request — including one with no credentials at all — was treated as a super-admin. AWS says that access was enough to register tool servers, read stored integration credentials and rewrite the IAM role policies attached to managed agent roles. Two further server-side request forgery (SSRF) flaws, CVE-2026-103957 and CVE-2026-103958, let lower-privileged administrators leak OAuth2 secrets, other users' access tokens and the container's own role credentials. All three are fixed in Loom 1.7.0. Teams running Loom, or a fork of it, should confirm their version today and rotate the credentials AWS lists.

What AWS disclosed in bulletin 2026-124-AWS

AWS published Security Bulletin 2026-124-AWS on 2 October 2026, rating it "Important (requires attention)". The bulletin describes Loom as "an AWS Labs open-source AI agent orchestration platform" and recommends upgrading to version 1.7.0 and "ensuring any forked or derivative code is patched to incorporate the new fixes." The project README describes Loom as a unified management layer for agents, memory stores, MCP servers, A2A integrations and AWS Agent Registry governance, with Cognito-based authentication and scope-based authorization. That makes the control plane a high-value target: it handles IAM roles, credential providers and authentication flows on behalf of every agent it manages.

AWS credits Kenneth Cox for reporting the issues through coordinated disclosure. The three matching GitHub security advisories were published on the awslabs/loom repository on 2 October.

Root cause: CVE-2026-103956, a fail-open authentication dependency

CVE-2026-103956 is classed as CWE-306 (Missing Authentication for Critical Function) and CWE-1188 (Insecure Default Initialization of Resource). According to advisory GHSA-vgmj-998f-r8mp, when no Amazon Cognito user pool and no active external identity provider were configured, get_current_user in backend/app/dependencies/auth.py unconditionally returned a fixed t-admin/g-admins-super identity for any request, carrying "every scope in the system."

The advisory stresses that this was not an exotic configuration. It is the state of a freshly deployed instance before an operator finishes identity provider setup, and of any instance where the IdP configuration becomes unreachable or is accidentally left unset. Any client that could reach the backend in that window could read, create, modify or delete every resource Loom manages — agents, memories, security and authorizer configuration, credentials and settings — and invoke any agent.

The fix, shipped in Loom 1.6.1 on 4 August 2026, requires an explicit LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV opt-in and restricts the bypass to requests originating from loopback. According to the advisory, an IdP-less deployment can no longer be reached as an open admin panel over the network, even if that opt-in is mistakenly left set.

CVE-2026-103957: OAuth2 discovery sends secrets to attacker-chosen token endpoints

CVE-2026-103957 (CWE-918, CWE-201) affects MCP server and A2A connections configured for delegated OAuth2 authentication. A user holding the mcp:write or a2a:write scope could register a well-known discovery URL whose discovery document named a third-party-controlled token_endpoint. Before 1.7.0, the backend's outbound SSRF guard checked only that the target was a public HTTPS address, not that it matched the deployment's configured identity provider. The backend would therefore forward the resource's client secret (client-credentials flow) or, in on-behalf-of mode, another user's real access token to that host.

The advisory notes that 1.6.1 closed internal-address and cloud-metadata reach on this code path but left the "any public HTTPS host" trust issue open. The 1.7.0 release notes say the fix now requires a deployment-trusted issuer host before any OAuth2 token exchange sends a secret or token, and extends an IP-validated, DNS-pinned fetcher to other outbound OAuth2/OIDC calls, including OIDC discovery, JWKS and the login-callback token exchange (PR #49).

CVE-2026-103958: connection sinks reach the credential-vending endpoint

CVE-2026-103958 (CWE-918) affects registering, updating or testing an MCP tool server or A2A remote agent connection. A scoped user could supply an endpoint_url/base_url pointing at an internal address, including the container's IMDS/credential-vending endpoint. Before 1.7.0, these requests were not validated against the resolved IP and redirect targets were not re-checked, so a request, and through a redirect its response body, could expose the application's container role credentials or the contents of internal services. The fix is in PR #32.

Exploitation status and severity

AWS has not said whether any of the three flaws has been exploited in the wild, and none appears in CISA's Known Exploited Vulnerabilities catalog as of 4 October. The CVSS 3.1 scores in the GitHub advisories are:

• CVE-2026-103956: 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). The CVE record also carries a CVSS 4.0 score of 10.0.
• CVE-2026-103958: 7.6 High (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N)
• CVE-2026-103957: 6.2 Medium (AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N)

The two SSRF issues require an authenticated account with elevated scopes. Under the advisories' workaround text, those scopes belong to the g-admins-super, g-admins-mcp, g-admins-a2a and g-admins-demo groups. In practice, though, CVE-2026-103956 hands every scope to an unauthenticated caller on an IdP-less deployment. On those instances the bugs stack: an attacker with no credentials gets admin rights, and the SSRF paths then open the way to the container's AWS role credentials.

Timing also matters. The CVE-2026-103956 fix shipped publicly on 4 August, about two months before the CVE and bulletin. Anyone comparing the 1.6.1 diff could have spotted the authentication change long before 2 October. Loom deployments that have not been upgraded since early August should be treated as exposed.

Affected and fixed versions

AWS's bulletin names 1.7.0 as the target version. The repository has since tagged 1.7.1 through 1.7.4 (the latest dated 29 September). Their release notes list further security hardening: loom:group resource isolation on single-object routes, a block on admins granting themselves super-admin scopes through IdP group mappings, tighter scopes on global settings routes, and an ownership check on human-in-the-loop approval decisions. None of these later fixes carries a CVE in the AWS bulletin. Even so, moving to the newest tag is the sensible target.

Defensive playbook

1. Find every Loom deployment and fork. Include local-dev and "Phase 1/Phase 2" instances that an engineer may have exposed beyond loopback, and any internal derivative of the code.
2. Confirm the running version and upgrade to 1.7.0 or later (current tag: v1.7.4):

   # In your Loom checkout or fork
   git fetch --tags origin
   git describe --tags
   git log --oneline -1
   
   # Move to the latest release tag and redeploy
   git checkout v1.7.4

3. Confirm an identity provider is live before exposure. AWS's workaround for CVE-2026-103956 is to make sure a Cognito user pool or an active external IdP is fully configured before the backend can be reached beyond loopback, and that LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset in every deployed environment. On ECS, check the task definition:

   aws ecs describe-task-definition --task-definition <loom-backend-task>   --query "taskDefinition.containerDefinitions[].environment[?name=='LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV']"

4. Restrict high-risk scopes until patched. Limit mcp:write and a2a:write (membership of g-admins-super, g-admins-mcp, g-admins-a2a, g-admins-demo) to trusted administrators. AWS notes this lowers the risk but does not close the issues without the code fix.
5. Rotate after upgrading. Following the bulletin, rotate every OAuth2 client secret configured for MCP/A2A integrations and revoke and reissue access tokens that were active during the affected window.
6. Audit IAM on managed agent roles. CVE-2026-103956 allowed IAM role policies on managed agent roles to be rewritten. Review recent policy changes on those roles. This CloudTrail query is a starting point; scope it to your Loom-managed role names:

   for ev in PutRolePolicy AttachRolePolicy UpdateAssumeRolePolicy; do
     aws cloudtrail lookup-events     --lookup-attributes AttributeKey=EventName,AttributeValue=$ev     --start-time 2026-07-01T00:00:00Z     --query "Events[].[EventTime,Username,Resources[0].ResourceName]" --output table
   done

7. Check for credential use outside the container. If container role credentials may have been read via CVE-2026-103958, rotate the role's session credentials as AWS advises and look in CloudTrail for that role's activity from unexpected source IPs.
8. Review the Loom inventory itself. Look for MCP servers, A2A agents, authorizers or credential providers that nobody on the team registered, especially any whose endpoints or discovery URLs point outside your organisation.

Also from AWS this week: SageMaker Distribution command injection (CVE-2026-104019)

An hour after the Loom bulletin, AWS published Security Bulletin 2026-125-AWS for CVE-2026-104019 in Amazon SageMaker Distribution. The startup script in a SageMaker Unified Studio Space runs a network validation against every SageMaker connection in a project. AWS says improper sanitisation of connection details during that check could let arbitrary code run in the Space of another project member. In projects with Trusted Identity Propagation enabled, a user with project contributor permissions or higher could obtain another member's temporary execution role credentials and call downstream services on their behalf.

Fixed images are 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 and 4.4.3. Lines 2.8.x–2.13.x and 3.3.x–3.8.x are end-of-support and will not be fixed, and 4.5.x is not affected. AWS says Spaces pick up the latest patch of their minor line on restart, so it recommends restarting affected Spaces. There is no workaround.

Both bulletins point to the same pattern. Agent control planes and AI development environments now hold IAM role credentials and delegated tokens, and in both cases a single missing check let one user act with another identity's cloud permissions.