AWS patches four vulnerabilities in its Loom agent platform and SageMaker

AWS released security fixes for four vulnerabilities on October 2 affecting its open-source Loom AI agent orchestration platform and Amazon SageMaker Unified Studio. The flaws could let attackers bypass authentication, steal OAuth2 tokens and temporary cloud credentials, reach internal services, and run code in another user's environment, according to GBHackers' review of the bulletins.

What Loom is

Loom for AWS is an AWS Labs open-source platform for building, deploying, and operating AI agents on Amazon Bedrock AgentCore Runtime and AWS Strands Agents. It bundles a management UI, Cognito-based authentication, MCP server and Agent2Agent integrations, IAM role handling, and cost tracking. In other words, it is exactly the kind of privileged control plane that attackers want: one compromise can reach every agent, credential, and cloud role behind it.

The three Loom flaws

The highest-impact issue, CVE-2026-103956, comes from a problem in Loom's authentication dependency. On deployments without an identity provider configured, any network client could gain full administrative control of the agent control plane, register malicious tool servers, pull stored integration credentials, and alter IAM role policies tied to managed agent roles. AWS classified it under missing authentication for a critical function and fixed it in Loom 1.6.1, released August 4. But AWS says to skip straight to 1.7.0, which also fixes the other two.

CVE-2026-103957 affects releases before 1.7.0 and concerns unsafe OAuth2 discovery processing. An authenticated user holding the mcp:write or a2a:write scope could point Loom at a malicious discovery URL and make the backend hand over OAuth2 client secrets or another user's access token to an attacker-controlled endpoint.

CVE-2026-103958 is an outbound-request handling flaw that resembles server-side request forgery. The same scoped users could force Loom's MCP tool-server or Agent2Agent logic to connect to arbitrary internal destinations and return the responses. That could reach a container credential-vending endpoint and yield temporary AWS credentials usable against the associated IAM role.

The SageMaker flaw

The fourth issue, CVE-2026-104019, is an OS command injection bug in the SageMaker Space startup scripts caused by insufficient sanitization of connection details during startup validation. A project member could craft malicious connection data and execute code in another member's Space. In projects with Trusted Identity Propagation enabled, that escalates further: a contributor-level user could obtain another member's temporary execution-role credentials and call downstream services on their behalf. Fixes landed in SageMaker Distribution versions 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5, and 4.4.3. Version 4.5.x is not affected.

What to do now

AWS tells Loom operators to upgrade to 1.7.0 immediately, configure a Cognito user pool or external identity provider before exposing Loom beyond loopback, and confirm LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is not enabled in production. After patching, rotate OAuth2 client secrets, revoke and reissue tokens active during the affected window, rotate potentially exposed IAM session credentials, and sweep CloudTrail for suspicious activity. SageMaker Unified Studio users should restart affected Studio Spaces so the patched images take effect.

The pattern here is worth noting for anyone running agent infrastructure: agent platforms concentrate credentials, tool registrations, and cloud permissions behind a single control plane, so a missing-authentication default or an SSRF-adjacent request path becomes a skeleton key for the whole deployment.