AWS fixes Loom flaw that gave any network client admin rights on deployments without an identity provider

Loom for AWS before 1.6.1 trusted any network client as super-admin when no identity provider was configured CVE-2026-103956 : unauthenticated client, backend with no IdP, fixed super-admin identity, agent control plane. Fixed in 1.6.1 and 1.7.0.

Alex Kim
Threat intelligence editor · Published Oct 5, 2026, 5:24 AM EDT

AWS Loom before 1.6.1 treated every client as super-admin with no identity provider set (CVE-2026-103956). Upgrade to 1.7.4; 1.7.0 fixes two SSRF flaws.

AWS Labs' open-source agent platform Loom for AWS has three vulnerabilities, disclosed in AWS Security Bulletin 2026-124-AWS on 2 October 2026. The worst, CVE-2026-103956, lets any unauthenticated network client act as super-admin on a Loom backend that has no identity provider (IdP) configured. AWS fixed it in version 1.6.1 on 4 August 2026, and recommends moving to 1.7.0, which also fixes two authenticated server-side request forgery (SSRF) issues, CVE-2026-103957 and CVE-2026-103958. The bulletin is labelled "Important (requires attention)". It calls 1.7.0 the latest version, but Loom 1.7.4 (29 September) was already out, and 1.7.1 to 1.7.4 carry further security fixes, so we suggest 1.7.4 or later.

Credit goes to Kenneth Cox, who reported all three through coordinated disclosure.

Timeline

4 August 2026: Loom 1.6.1 is released. Its release notes already describe the bypass in public: the local-dev path "silently granting super-admin access" to any request, now gated behind an explicit opt-in and a loopback client.
20 September: Loom 1.7.0 is released (GitHub release timestamp).
22 to 29 September: Loom 1.7.1 to 1.7.4 follow, each with a "Security" section and none with a CVE.
2 October: AWS publishes the bulletin and the CVEs.
3 October: the third-party PoC repository below is created.

The flaw was therefore visible in release notes about two months before the CVE and bulletin. We do not know whether it was exploited in that time.

Who is exposed

CVE-2026-103956 affects Loom versions before 1.6.1 where no Amazon Cognito user pool and no active external IdP is configured. The GitHub advisory says this is the state of a freshly deployed instance before setup is finished, or any instance where IdP configuration becomes unreachable or is left unset.
CVE-2026-103957 and CVE-2026-103958 affect versions before 1.7.0 and need an authenticated user holding the mcp:write or a2a:write scope. By AWS's list, that means members of the g-admins-super, g-admins-mcp, g-admins-a2a or g-admins-demo groups.

What an attacker gets

CVE-2026-103956 (authentication bypass, CWE-306 and CWE-1188). According to the advisory, the backend's get_current_user dependency returned a fixed g-admins-super identity for every request when no IdP was set, without reading any Authorization header. AWS says that gives full administrative authority over the agent control plane. The GitHub advisory goes wider, saying an attacker could "read, create, modify, or delete every resource the platform manages (agents, memories, security/authorizer configuration, credentials, settings) and invoke any agent". AWS's own list: registering tool servers, reading stored integration credentials, and rewriting the IAM role policies attached to managed agent roles (we covered a similar LiteLLM proxy admin flaw). The GitHub advisory and the NVD record list a CVSS v3.1 score of 10.0 (Critical); that score is supplied by the CNA, and NVD had not yet completed its own analysis when we checked on 4 October. The AWS bulletin itself gives no score.

The 1.6.1 fix requires an explicit LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV opt-in and limits the bypass to loopback requests. Per the advisory, an IdP-less deployment is therefore no longer reachable as an open admin panel over the network, even if the opt-in is left set by mistake.

CVE-2026-103957 (OAuth2 discovery, CWE-918 and CWE-201). A user with write scope can register a tool server or remote agent using a well-known discovery URL whose document names a token endpoint controlled by a third party. Before 1.7.0 the backend's SSRF guard checked only that the target was a public HTTPS address, not that it matched the deployment's IdP. The backend would then send the integration's client secret, or in on-behalf-of mode another user's real access token, to that host. Version 1.6.1 blocked internal-address and metadata reach on this path but left the token disclosure open. GitHub rates it Moderate (6.2).

CVE-2026-103958 (SSRF, CWE-918). A user with write scope can register, update or test an MCP or A2A connection pointing at internal addresses, including the container's credential-vending endpoint, and read the response. Before 1.7.0 the requests were not validated against resolved IPs and redirect targets were not re-checked. The result can be disclosure of the application's own container role credentials. GitHub rates it High (7.6).

What defenders should do

Upgrade to Loom 1.7.0 or later, ideally 1.7.4 (29 September, the current release). 1.7.0 covers all three CVEs, and AWS asks fork and derivative maintainers to port the fixes. The later releases add hardening that the bulletin does not mention, per their release notes:
- 1.7.1 (22 September): closes a path where a security-scoped admin could map IdP groups to grant themselves super-admin, and blocks cross-group access to agents and memories by ID.
- 1.7.2 (26 September): more group-isolation fixes, covering MCP and A2A resources, managed roles and credential token minting.
- 1.7.3: global settings routes now require super-admin.
- 1.7.4: approval decisions now check who owns the request.
If you cannot upgrade yet:
- For CVE-2026-103956, fully configure Cognito or an external IdP before the backend is reachable beyond loopback, and make sure LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset in every deployed environment. The advisory adds that restricting network or security-group access helps but does not close the issue.
- For the other two, limit mcp:write and a2a:write (the four g-admins groups above) to trusted administrators. AWS says this lowers the likelihood but does not close the issue without the code fix.
After upgrading, clean up, per AWS:
- Rotate OAuth2 client secrets configured for MCP and A2A integrations.
- Revoke and re-issue access tokens that were active during the affected window.
- If container role credentials may have been accessed, rotate the IAM role's session credentials and review CloudTrail for unintended use.
Check for earlier tampering. Because CVE-2026-103956 allowed IAM role policy rewrites and credential reads, any instance that ran before 1.6.1 with no IdP and a reachable backend should have its managed agent role policies and stored integration credentials reviewed. This is our inference from the bulletin's impact description; AWS lists the rotation steps above but does not give a detection checklist.

Public exploit material

A third-party repository, abraxas/cve-2026-103956-loom-unauth, claims to demonstrate the bypass. We have not verified it and do not vouch for it. The repository was created on 3 October 2026, the day after the bulletin. None of the three CVEs was in CISA's Known Exploited Vulnerabilities catalogue when we checked on 5 October, and we found no source confirming exploitation in the wild. Treat any unpatched, IdP-less instance reachable from a network as at risk.