Four bugs, one underlying theme
AWS disclosed four distinct vulnerabilities on October 2 across two of its AI agent products: Loom for AWS, an open-source platform for orchestrating AI agents and the tools they call, and Amazon SageMaker Unified Studio, the managed environment data teams use to build and deploy models and agents together. Three of the four, tracked as CVE-2026-103956, CVE-2026-103957, and CVE-2026-103958, live in Loom versions before 1.6.1 and 1.7.0. The fourth, CVE-2026-104019, is an operating system command injection flaw in SageMaker's startup scripts that lets one user's code run inside another user's isolated workspace.
The common thread across all four is not a single coding mistake but a category of risk specific to agent orchestration software: these platforms sit at the intersection of identity, credential storage, and dynamic tool discovery, and a flaw in any one of those three layers tends to cascade into the others. A credential leak in an agent platform is worse than a credential leak in a traditional application, because the agent itself may be configured to act autonomously on whatever it retrieves.
The admin-takeover bug
CVE-2026-103956 is the most serious of the four. In a Loom deployment that does not have an identity provider configured, any network client can gain complete administrative authority over the agent control plane. That is not a privilege escalation from a low-tier account; it is a path from no authentication at all to full administrative control, including the ability to register malicious tool servers that the platform will then trust and call on the agent's behalf. An attacker who registers a malicious tool server through this path can also retrieve stored integration credentials, the exact secrets a legitimate deployment uses to let agents reach calendars, ticketing systems, and internal APIs.
The detail that should worry security teams most is the default condition behind it: this bug only requires a missing identity provider configuration, the absence of a setting entirely, rather than a traditional misconfiguration where something was set incorrectly. Fast-moving teams standing up agent orchestration platforms for a pilot or proof of concept are precisely the ones most likely to skip identity provider setup in the name of speed, which means the deployments most exposed to this bug are often the newest and least scrutinized ones in an enterprise's growing AI portfolio.
Credential leakage through OAuth and SSRF-style flaws
CVE-2026-103957 exploits unsafe handling of OAuth2 discovery in Loom. An authenticated user with the right scopes can configure a malicious discovery URL that causes the platform to disclose OAuth2 client secrets, or another user's access token, to an endpoint the attacker controls. That turns a feature meant to let agents authenticate against external services into a mechanism for one user to steal another user's credentials inside the same shared platform, which is a particularly uncomfortable failure mode for any organization running multi-tenant agent deployments across teams.
CVE-2026-103958 behaves like a server-side request forgery vulnerability, letting a user force the platform to connect to internal destinations it should never reach on a caller's behalf. The practical outcome is exposure of temporary AWS credentials pulled from a container's metadata endpoint, the same category of credential theft that has driven some of the most damaging cloud breaches of the past several years, now reachable through an AI agent platform's own request-handling logic rather than through a traditional web application.
Why SageMaker's bug is a different kind of problem
CVE-2026-104019 sits apart from the three Loom flaws because it is a classic command injection bug in SageMaker Unified Studio's startup scripts, caused by insufficient sanitization of inputs that eventually reach a shell during workspace initialization. The effect is that one user's code can execute arbitrary commands inside another user's supposedly isolated workspace, breaking the tenant isolation that a shared data science environment depends on to let multiple teams work safely side by side on the same managed platform without stepping on each other's data or compute resources.
That isolation promise is central to how large organizations justify consolidating data science and agent development onto a single managed platform instead of standing up separate infrastructure per team. A bug that breaks it, even one patched quickly, is a reminder that the isolation boundary is a design claim that needs independent verification, not just a product description to take on faith.
What this means for enterprise AI platform teams
AWS moved fast here: bulletins went out October 2 recommending an upgrade to Loom 1.7.0 and specific SageMaker Distribution versions, and there is no indication in AWS's advisories of confirmed exploitation before the fixes shipped. That is the outcome every vendor wants, but it does not change the underlying lesson for any enterprise standing up its own agent orchestration layer, whether on Loom, a competing platform, or something built in house.
Identity provider configuration for agent platforms should be a hard requirement enforced by infrastructure as code, not a setup step a team can skip during a pilot. Credential handling for anything an agent touches needs the same scrutiny as a production payments system, because an agent that can be tricked into leaking a token can also be tricked into acting on an attacker's behalf with that token. Treat agent orchestration platforms as a new, high-value category in the vulnerability management program rather than a subset of general application security.
