AWS Loom Vulnerabilities: A Hardening Checklist for Teams Running AI Agents

On October 2, 2026, AWS published security bulletin 2026-124-AWS covering three issues in Loom for AWS, which it describes as an AWS Labs open-source AI agent orchestration platform. The most serious one, CVE-2026-103956, lets any network client take full administrative control of the agent control plane in a deployment that has no identity provider configured. Source

You may never run Loom. The bulletin is still a useful case study, because the failure modes are not specific to one product. They are the same ones any team hits when it stands up an agent platform quickly: a login that is optional in setup, tool connections that call out to addresses a user supplies, and credentials that sit one hop away from the agent. This post walks through what AWS disclosed, then turns it into a checklist you can apply to your own agent stack.

What AWS disclosed

The bulletin lists three issues, all fixed in Loom 1.7.0, with the first also fixed earlier in 1.6.1. Source

• CVE-2026-103956, authentication bypass. In versions before 1.6.1, any network client could get full administrative authority over the agent control plane, including registering tool servers, reading stored integration credentials and rewriting the IAM role policies attached to managed agent roles. This applied to a deployment where no identity provider was configured. The fix shipped in version 1.6.1, released August 4, 2026. Source

• CVE-2026-103957, OAuth2 token and credential disclosure. In versions before 1.7.0, an authenticated user with the mcp:write or a2a:write scope could set a discovery URL whose document made the backend send OAuth2 client secrets, or another user's access token, to a third-party endpoint. AWS says 1.6.1 blocked internal-address reach on this path but did not fully fix the token disclosure. Source

• CVE-2026-103958, outbound request handling. In versions before 1.7.0, a user with the same scopes could direct tool server and remote agent connection requests to arbitrary internal network locations, including the container's credential-vending endpoint, and read the responses. Source

The CVE records give the severity. CVE-2026-103956 is rated 10.0 critical under both CVSS 3.1 and 4.0. CVE-2026-103957 is rated 6.2 medium under 3.1 and 8.2 high under 4.0, and CVE-2026-103958 is rated 7.6 high under 3.1 and 8.3 high under 4.0. Source Source Source

AWS credits Kenneth Cox for coordinated disclosure. Source

Why the "no identity provider" case matters

The GitHub advisory for the critical bug is direct about how ordinary the condition is. It says that when no Amazon Cognito user pool and no active external identity provider were configured, the authentication function returned a fixed super-admin identity for any request, unconditionally. It adds that this is not a rare edge case: it is the state of a freshly deployed instance before an operator has finished identity provider setup, or any instance where that configuration becomes unreachable or is left unset. Source

That is the lesson worth keeping. The flaw was not an exotic exploit chain. It was a default that failed open. In many teams, the first version of an internal agent platform is exactly that: set up on a Friday, reachable from the company network, with login "to be added." Any network client that could reach the backend during that window needed no credentials, according to the advisory. Source

The fix, per the advisory, makes the unauthenticated mode an explicit opt-in through a setting named LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV and limits the bypass to requests from loopback, so a deployment without an identity provider can no longer be reached as an open admin panel over the network even if the opt-in is left set by mistake. Source

Two-step patching: why 1.6.1 was not enough

A detail that is easy to miss: patching to 1.6.1 closed the critical bug but not the other two. AWS recommends upgrading to the latest version, 1.7.0, and also asks teams to make sure any forked or derivative code includes the new fixes. Source

The practical point for operations teams is that a patch for one CVE can leave related issues open. When a bulletin lists several issues, read the fixed-in version for each. Then upgrade to the version that covers all of them, not the first version that quiets the loudest alert. If your team forked the code, the fork needs the fixes too.

What AWS says to do

The bulletin gives interim and follow-up steps. Until you can upgrade: Source

• Make sure a Cognito user pool or an active external identity provider is fully configured before the backend is reachable beyond loopback.

• Confirm the unauthenticated local-dev setting is unset in any deployed environment.

• Limit the mcp:write and a2a:write scopes to trusted administrators. AWS notes this lowers the likelihood of the other two issues but does not fully close them without the code fix.

After upgrading, AWS lists three follow-ups: rotate any OAuth2 client secrets configured for MCP and A2A integrations, revoke and re-issue access tokens that were active during the affected window, and, if container role credentials were accessed, rotate the IAM role's session credentials and review CloudTrail for unintended usage. Source

A hardening checklist for any agent platform

These points come from the failure patterns in the bulletin, applied to any agent stack. They are our recommendations, not AWS guidance.

1. Fail closed. If identity configuration is missing or unreachable, the platform should refuse requests, not grant access. Test this on purpose by pointing a staging copy at a broken identity provider and confirming nothing loads.

2. Treat tool connections as outbound requests you control. CVE-2026-103957 and 103958 both involve a user-supplied address that made the backend call out. Allowlist the hosts a tool server or remote agent may reach, block internal and metadata ranges, and log every new registration.

3. Keep the credential-vending endpoint out of reach. The bulletin names the container's credential-vending endpoint as a target. Use the platform's strongest metadata protections, and give each agent role only the permissions that agent needs.

4. Narrow the scopes that can register tools. In Loom, the write scopes were the gate. Review who holds the equivalent in your stack, and require review for new tool servers the way you do for new code dependencies.

5. Separate pilots from production. Pilots tend to run with relaxed auth. Give them a network boundary of their own, and set a date after which an unauthenticated instance is shut down.

6. Plan for rotation. AWS's follow-up list is mostly rotation: client secrets, tokens, role credentials. If you cannot rotate an agent's secrets in an afternoon, find out why before you need to.

7. Watch the platform's advisories. Subscribe to the vendor's security bulletin feed and assign an owner. The Loom fix for the critical issue shipped on August 4 and the bulletin followed on October 2, which means a team tracking releases but not advisories could have missed the reason to upgrade. Source

Where this fits for Codesprint clients

Teams we work with rarely lack agent demos. What they lack is the unglamorous layer around them: identity, network boundaries, scoped permissions, rotation and monitoring. The Loom bulletin is a clear example of why that layer needs an owner from day one.

Our AgentOps services cover this work: reviewing how your agents authenticate, where they can call out, what they can reach, and how you would respond if a credential leaked. If you want a second pair of eyes on an agent platform before it goes live, contact us.