Three Flaws in AWS Loom Agent Platform Expose Admin Control and Cloud Credentials
AWS has published security bulletin 2026-124-AWS covering three vulnerabilities in Loom, the AWS Labs open-source AI agent orchestration platform. CVE-2026-103956 is an authentication bypass (CWE-306, CWE-1188) affecting Loom versions before 1.6.1, while CVE-2026-103957 (CWE-918, CWE-201) and CVE-2026-103958 (CWE-918) affect versions before 1.7.0 and both involve unsafe outbound request handling. Anyone running a self-hosted Loom deployment is in scope, and AWS notes that forked or derivative codebases carry the same defects until they pick up the upstream fixes. AWS classifies the bulletin as Important, meaning it requires attention. Fixed code exists: version 1.6.1 resolved the authentication bypass on its own, and version 1.7.0 resolves all three.
The authentication bypass sat in Loom's authentication dependency. In a deployment where no identity provider was configured, any network client that could reach the application API obtained full administrative authority over the agent control plane. That authority included registering tool servers, reading stored integration credentials, and rewriting the IAM role policies attached to managed agent roles. The two remaining issues require an authenticated user holding the mcp:write or a2a:write scope. For CVE-2026-103957, such a user could configure a well-known OAuth2 discovery URL whose document instructed the backend to deliver OAuth2 client secrets, or another user's access token, to an endpoint controlled by a third party; version 1.6.1 blocked internal-address reach on that code path but did not close the token disclosure. For CVE-2026-103958, the tool server (MCP) and remote agent (A2A) connection handlers could be pointed at arbitrary internal network locations, including the container's credential-vending endpoint, with the responses returned to the requester.
The common thread is that Loom sits on top of real AWS authority rather than beside it. A control plane that stores integration credentials and can rewrite IAM role policies is an attractive target in its own right, and an outbound request handler that will fetch the container credential-vending endpoint and hand back the response turns an application-layer flaw into a potential route to the underlying AWS role. The scope requirement on CVE-2026-103957 and CVE-2026-103958 limits exposure to users already trusted with MCP and A2A configuration, but the authentication bypass needed no credentials at all wherever an identity provider had not been wired up before the backend became reachable beyond loopback. On current exploitation status, FIRST EPSS places the probability of exploitation in the next 30 days at 0.5 percent for CVE-2026-103956, 0.4 percent for CVE-2026-103957 and 0.3 percent for CVE-2026-103958, and the bulletin describes coordinated disclosure rather than observed attacks. The practical consequence for affected operators is a credential-hygiene question as much as a patching one, because any OAuth2 client secret, user access token or container role session credential that existed during the affected window cannot be assumed to be private.
Attack Surface
Cloud Service, Web Application, Infrastructure
Tactics
Initial Access, Credential Access, Privilege Escalation, Discovery, Collection
Techniques
- T1190 – Exploit Public-Facing Application
- T1552.005 – Unsecured Credentials: Cloud Instance Metadata API
- T1528 – Steal Application Access Token
- T1078.004 – Valid Accounts: Cloud Accounts
- T1046 – Network Service Scanning
SuperPRO's Threat Countermeasures Procedures
- Upgrade Loom for AWS to version 1.7.0, the only release that fixes all three issues; version 1.6.1 closes the authentication bypass CVE-2026-103956 but leaves CVE-2026-103957 and CVE-2026-103958 open. Given low EPSS scores and no reported exploitation, schedule this in the next maintenance window, but treat internet-reachable or multi-tenant Loom deployments as same-day work.
- Confirm the environment variable LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset in every deployed non-local-dev environment, and verify that a Cognito user pool or an active external identity provider is fully configured before the Loom backend is reachable beyond loopback.
- Restrict the mcp:write and a2a:write scopes to trusted administrators only by auditing membership of the g-admins-super, g-admins-mcp, g-admins-a2a and g-admins-demo groups, and remove any demo or test accounts left in them.
- Rotate every OAuth2 client secret configured for MCP or A2A integrations, and revoke and re-issue any access tokens that were active while the deployment ran a version below 1.7.0.
- If container role credentials may have been reached through the MCP or A2A connection handlers, rotate the IAM role's session credentials and review CloudTrail for API calls made with the agent role from unexpected source addresses or at unexpected times.
- Patch any forked or derivative Loom codebase to incorporate the upstream fixes tracked as GHSA-vgmj-998f-r8mp, GHSA-jcxf-gpf4-58hm and GHSA-w6g6-h8pv-6mc7, rather than assuming the managed upgrade covers internal builds.
