AWS patched a perfect-10 flaw in its AI agent platform. The fix shipped two months before anyone was told.

Three CVEs, one of them a perfect 10

On 2 October 2026 at midday Pacific, AWS published security bulletin 2026-124-AWS covering three vulnerabilities in Loom for AWS, which the bulletin describes as "an AWS Labs open-source AI agent orchestration platform." Loom is the layer that registers tool servers, holds integration credentials and hands agents their IAM roles. It is the thing an agent runs inside.

The top entry, CVE-2026-103956, carries a base score of 10.0 under both CVSS 4.0 and CVSS 3.1. Ten is the ceiling. Worth noting who set it: AWS scored its own flaw, as the CVE numbering authority for its products, and the NVD record still reads "NVD assessment not yet provided" for NIST's own view. A vendor marking itself at the maximum is a vendor not minimizing, which is the direction you want that bias to run. The other two, CVE-2026-103957 and CVE-2026-103958, carry AWS scores of 8.2 and 8.3 under CVSS 4.0. AWS credited Kenneth Cox for working through coordinated disclosure, and recommends everyone move to version 1.7.0.

None of the three involve a model doing anything. That is the point worth sitting with.

The flaw that needed no credentials at all

AWS states the critical issue plainly: "An issue in the authentication dependency in Loom for AWS versions <1.6.1 allowed any network client to obtain full administrative authority over the agent control plane."

What full administrative authority buys an attacker is listed in the same sentence: registering tool servers, reading stored integration credentials, and rewriting the IAM role policies attached to managed agent roles. Register a tool server and you choose what the agents call. Read the stored credentials and you have the keys to whatever those agents were integrated with. Rewrite the IAM policies and you decide what the agents are permitted to do inside the account.

The precondition is the uncomfortable part. It applied "via any request to the application API in a deployment where no identity provider was configured." No exploit chain, no authentication, no user interaction. Just an unauthenticated request to a Loom deployment that nobody had wired an identity provider into yet.

AWS's interim workaround names the specific trap: "Ensure a Cognito user pool or an active external identity provider is fully configured before the backend is reachable beyond loopback, and confirm LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset in any deployed (non-local-dev) environment."

A convenience flag for local development, left set in something reachable from a network. It is one of the oldest failure modes in software, now sitting under an agent control plane.

The two that needed only a scope

The other pair are server-side request forgery, and they matter because of where the requests land.

CVE-2026-103958 let an authenticated user holding the mcp:write or a2a:write scope point tool server and remote agent connection requests at "arbitrary internal network locations," which AWS says includes the container's credential-vending endpoint, and read the responses back. The credential-vending endpoint is how a container gets its IAM session credentials. Reaching it from inside the request handler is a credential leak with extra steps.

CVE-2026-103957 is the same class in the OAuth2 discovery path: a user with those scopes could set a well-known discovery URL whose document told the backend to send OAuth2 client secrets, or another user's access token, to an endpoint the attacker controlled.

AWS's own note on that one is the most instructive line in the bulletin: "The 1.6.1 release blocked internal-address reach for this code path but did not fully address the token disclosure." The first fix closed the obvious half and left the other half open until 1.7.0.

The timeline deserves a second read

Here is the detail most coverage skipped. The CVSS 10.0 authentication bypass "was addressed in version 1.6.1, released 2026-08-04."

That is nearly two months before the bulletin that explained what 1.6.1 actually fixed. Anyone who upgraded in August for ordinary reasons was protected and did not know why. Anyone who did not upgrade was running an unauthenticated super-admin hole through all of August and September with no public signal that it mattered.

This is not a scandal. Coordinated disclosure routinely puts the patch before the paperwork, and AWS says CVE-2026-103956 "was independently addressed in version 1.6.1," which reads like a fix that landed before anyone connected it to the reported issue. But it does change what the bulletin is for. If you run Loom, the useful question is not "should I patch," it is "what was my version doing in August," and then AWS's post-upgrade list: rotate the OAuth2 client secrets, revoke and reissue access tokens that were active during the window, and if container role credentials were reachable, rotate the IAM session credentials and go read CloudTrail.

What this says about agent platforms

Agent security coverage has been dominated by model-shaped threats, and for good reason: we have written about a poisoned lead making Salesforce's AI agent leak data, and the industry keeps announcing platforms to keep agents from going rogue.

This bulletin is a reminder that the first wave of real, scored, patched agent vulnerabilities is not about the model at all. It is missing authentication, over-broad write scopes, and a backend that will fetch a URL you hand it. Ordinary web security, in code that is roughly a year old, holding credentials for every system the agents touch.

That combination is what makes an orchestration layer a high-value target. A normal web app leaks its own data. An agent control plane leaks the credentials and the permissions for everything the agents were connected to, and it does it while holding the ability to add new tools the agents will dutifully call.

Our take

AWS handled this the way you want a vendor to handle it: scored honestly at the ceiling, documented the exact preconditions, published workarounds that name the specific environment variable, credited the researcher, and told customers precisely which secrets to rotate afterward. The bulletin is better than most.

The lesson is for everyone deploying this category rather than for AWS. If your agent platform has an admin API, assume it is the most sensitive service you run, and treat "no identity provider configured yet" as a production outage rather than a setup step you will get to. The mundane part of the stack is where the 10.0 lives.