Skip to content
AI.info

The Pulse

AWS Patches Loom Authentication Bypass and Two Token Flaws

AWS disclosed three security issues in Loom for AWS, including an authentication bypass that could expose the agent control plane when no identity provider was configured. The company recommends upgrading to version 1.7.0 and rotating poten

AWS Patches Loom Authentication Bypass and Two Token Flaws

AI.info Team · Written with AI ·

AWS disclosed three security issues in Loom for AWS on October 2, including an authentication bypass that could give an unauthenticated network client administrative control over the agent platform. The bypass affected deployments without a configured identity provider, and AWS says it was fixed in Loom version 1.6.1, released August 4. The company recommends updating Loom to version 1.7.0, which addresses all three issues.

AWS classifies the bulletin as “Important (requires attention),” not as critical. Its advice extends to organizations running forks or derivative builds: they should incorporate the fixes rather than assume an upstream version number alone resolves their exposure.

The bypass reached Loom’s agent control plane

The authentication flaw, tracked as CVE-2026-103956, affected Loom versions earlier than 1.6.1. In a deployment with no identity provider configured, any network client could make an application API request and gain full administrative authority over the agent control plane, AWS said.

That authority could let an attacker register tool servers, read stored integration credentials and rewrite IAM role policies attached to managed agent roles. AWS’s description makes the configuration condition central: the bypass applied where no identity provider was configured, rather than to every Loom deployment by default.

Two more flaws involved outbound requests

The other findings affect authenticated users with the mcp:write or a2a:write scope. CVE-2026-103957 involved OAuth2 discovery handling: a user could set a discovery URL whose document directed Loom’s backend to send OAuth2 client secrets or another user’s access token to an endpoint controlled by a third party. Version 1.6.1 blocked access to internal addresses in this code path, but AWS says that release did not fully close the token-disclosure issue; version 1.7.0 does.

CVE-2026-103958 affected connections to tool servers using MCP and remote agents using A2A. An authenticated user with the relevant write scope could direct connection requests to arbitrary internal network locations, including the container’s credential-vending endpoint, and read the responses. AWS says version 1.7.0 fixes this issue as well.

Updates are only part of the response

For deployments awaiting an update, AWS advises configuring a Cognito user pool or active external identity provider before making the backend reachable beyond loopback. It also says to ensure LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset in deployed environments. For the two outbound-request flaws, restricting the MCP and A2A write scopes to trusted administrators can reduce the chance of exploitation, but AWS says that restriction does not replace the code fix.

After upgrading, AWS recommends rotating OAuth2 client secrets used for MCP or A2A integrations and revoking and reissuing access tokens that were active during the affected period. If container role credentials may have been accessed, the company advises rotating the IAM role’s session credentials and reviewing CloudTrail for unintended use. AWS credits Kenneth Cox with collaborating through its coordinated disclosure process.

Source

Explore

More articles