PoCForge (Cyber Security) treats this as a test-and-harden problem for teams that run AWS Labs’ Loom agent orchestrator, forks of it, or SageMaker Unified Studio Spaces next to production data and IAM roles. This note stays on what the vendor bulletins and CVE records actually say, then turns that into an identity-provider decision, a scope matrix, a blast-radius map and a rotation checklist. It does not include requests, payloads or a proof of concept.
It is complementary to our existing cloud identity work — IAM attack paths and identity before configuration — and to when agents become the attack surface. Those pieces cover role graphs and prompt-to-tool abuse. This one is about the control plane that registers tools and the notebook Space that starts with someone else’s role. It is not a retelling of workload-identity destruction on Azure.
1. What AWS actually shipped
Loom is described in bulletin 2026-124 as an AWS Labs open-source AI agent orchestration platform. AWS recommends upgrading to 1.7.0 and patching forks. Three issues are in scope:
| CVE | Fixed in | Who can reach it | Impact AWS describes |
|---|---|---|---|
| CVE-2026-103956 | 1.6.1 (2 August 2026); still upgrade to 1.7.0 | Any network client, if no identity provider is configured | Super-admin on the agent control plane: register tool servers, read stored integration credentials, rewrite IAM role policies on managed agent roles. CWE-306 and CWE-1188. CVE record: CVSS 10.0 (3.1 and 4.0). |
| CVE-2026-103957 | 1.7.0 (1.6.1 only blocked internal-address reach) | Authenticated user with mcp:write or a2a:write |
OAuth2 discovery handling can be pointed at a document that sends client secrets, or another user’s access token, to a third-party endpoint, and can cause internal requests. CWE-918, CWE-201. |
| CVE-2026-103958 | 1.7.0 | Same write scopes | Tool-server (MCP) and remote-agent (A2A) connections can be aimed at internal addresses, including the container’s credential-vending endpoint, and the responses read. CWE-918. CNA scores CVSS 4.0 at 8.3 and CVSS 3.1 at 7.6. |
The CVE records were updated on 2 October 2026. A useful secondary summary is SecurityOnline’s Loom and SageMaker note. Prefer the AWS bulletin and cve.org when a blog and the vendor disagree.
CVE-2026-104019 is a separate product. Bulletin 2026-125 says the Studio Space startup script in SageMaker Distribution validates network connectivity against project connections. Unsanitised connection details could let a project contributor (or higher) run code in another member’s Space. Where Trusted Identity Propagation is enabled, that can expose the other member’s temporary execution-role credentials and allow calls to downstream TIP-enabled services as that member. There is no workaround. Supported images pick up the fix on the next Space start. End-of-support lines 2.8.x–2.13.x and 3.3.x–3.8.x have no fix and must move. 4.5.x is not affected, nor are builds before 2.8.0 and before 3.3.0. Fixed builds AWS names: 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 and 4.4.3.
2. Identity-provider decision tree
CVE-2026-103956 is conditional. The bulletin’s pre-upgrade control is: configure a Cognito user pool or an active external identity provider before the backend is reachable beyond loopback, and confirm LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV is unset outside local development. Use the tree with the people who deployed Loom, not as a scanner signature.
Was the API beyond loopback?
Was the application API reachable beyond loopback before 1.6.1? If nobody can show it was loopback-only, treat the control plane as exposed for the whole period it ran below 1.6.1 without an identity provider. Adding Cognito later does not erase that window.
No identity provider is the unauthenticated condition
No identity provider fully configured is the CVE-2026-103956 condition. Assume an anonymous client could have held super-admin: tool registration, stored integration secrets, and IAM policies on managed agent roles. Upgrade to 1.7.0, then run the rotation checklist. Do not stop at 1.6.1 while CVE-2026-103957 and CVE-2026-103958 still apply.
An active IdP changes the question
If Cognito or an external identity provider was active the whole time, the unauthenticated super-admin path is not the one the bulletin describes. Still confirm the local-dev bypass flag is unset in every deployed environment, including forks and staging that were briefly public.
Who holds mcp:write and a2a:write?
Are mcp:write and a2a:write limited to a named admin set? If those scopes were broad before 1.7.0, CVE-2026-103957 and CVE-2026-103958 were available to anyone in the write groups, including demo groups AWS names. Restricting groups reduces likelihood. AWS says it does not close the issue without the code fix.
A private image tag is not a patch
Bulletin 2026-124 includes forked or derivative code. Diff the authentication dependency and the outbound connection handling against 1.7.0, or rebuild from the fixed release.
Walk this with the people who deployed Loom. It is a decision, not a scanner signature.
3. Scope matrix
AWS names the groups that carry the dangerous write scopes: g-admins-super, g-admins-mcp, g-admins-a2a and g-admins-demo. In an authorised assessment, export membership and answer the matrix. Do not demonstrate token disclosure.
Could this principal register or test a tool server?
- Pre-1.7.0
- This scope is enough for the authenticated tool-server issues AWS describes.
- Evidence
- Group export, identity-provider group mapping, break-glass accounts.
- After 1.7.0
- Re-test that only intended administrators retain the scope.
Could this principal register a remote agent with delegated auth?
- Pre-1.7.0
- Same authenticated population as mcp:write for the OAuth discovery issue.
- Evidence
- Group export, plus which agents use OAuth discovery.
- After 1.7.0
- Rotate OAuth client secrets used by those integrations.
Union of control-plane admin
- Pre-1.7.0
- Includes policy edits on managed agent roles if CVE-2026-103956 applied.
- Evidence
- CloudTrail on PutRolePolicy, or the equivalent, for agent roles.
- After 1.7.0
- Diff role policies against the last known-good template.
Was a demo group left outside the lab?
- Pre-1.7.0
- A demo group in a deployed environment widens the write-scope population.
- Evidence
- Environment inventory: production, staging, sales, workshop.
- After 1.7.0
- Remove demo membership outside an isolated lab.
Any request was enough
- Pre-1.6.1
- The bulletin says scopes do not matter when no identity provider is configured.
- Evidence
- Deployment date, version, and whether the API left loopback.
- After the fix
- An identity provider is required before the API leaves loopback.
Select a scope or group. Evidence to collect is configuration and logs, not a demonstration of token disclosure.
4. Blast-radius map
Select a starting condition. The panes stay inside what the two bulletins describe. They are not an attack procedure.
Super-admin over the agent application API
Downstream of that condition: tool servers you did not register, integration credentials stored by Loom, and IAM policies attached to managed agent roles. Those roles are the bridge into the rest of the account. Pair this with a review of which data and APIs the agent roles can touch — the same question as in cloud IAM attack paths, asked of identities an anonymous client could have rewritten.
Whoever is in the write groups
A principal who already has mcp:write or a2a:write can, on versions before 1.7.0, cause OAuth material or another user’s access token to leave the deployment, and can read responses from internal addresses including the container credential endpoint. Blast radius is that population, not the whole internet. Demo and shared-admin groups make the set larger than the architecture diagram suggests.
Not the Loom API
A project contributor can reach code execution in another member’s Studio Space via connection properties consumed at startup. With Trusted Identity Propagation, temporary execution-role credentials for that member are in play, and therefore every downstream service that trusts that role. Restarting Spaces applies the image fix; it does not tell you whether a previous start already ran. End-of-support minor lines stay vulnerable until migrated.
Three separate conditions from the two bulletins. Not a chain, and not an attack procedure.
5. Assume breach after the upgrade
1.6.1 closed the unauthenticated path on 4 August 2026, but the coordinated disclosure and the public bulletin landed on 2 October 2026. Anything that was reachable without an IdP before 1.6.1 had a long quiet window. Anything with broad write scopes before 1.7.0 had a second window that 1.6.1 did not fully close. SageMaker’s fix applies on restart, so a Space that has not restarted is still on the old validation script even though AWS has deployed patched images.
Authorised test objectives, in order:
- Inventory every Loom deployment, fork and workshop copy. Record version, whether an IdP was configured, and whether the API was reachable off-loopback.
- Inventory SageMaker Unified Studio projects: Distribution minor line, Space last-start time, and whether Trusted Identity Propagation is on.
- For Loom below 1.7.0, upgrade first. Restrict write scopes as a compensating control only until the upgrade, and say so in the report — AWS is explicit that restriction is not a fix.
- Diff managed-agent IAM policies and tool-server registrations against the change record. Look for registrations and policy versions with no matching ticket.
- Review CloudTrail for use of container or execution roles in the exposure window. The bulletin asks for this if container role credentials were accessed; do it whenever you cannot prove they were not.
- Restart supported Spaces. Plan migration for 2.8–2.13 and 3.3–3.8. Confirm 4.5 or a fixed patch level after restart, not merely that “the service is AWS-managed”.
Production destruction, live token theft and policy tampering are out of scope. Prove the condition with version, configuration and log evidence.
6. Rotation checklist
Taken from the “after upgrading” section of bulletin 2026-124, plus the IdP and SageMaker actions the same publications require. Tick these in the engagement file. The counter is local to the browser.
After 1.7.0 (and after Space restarts)
0 checked
Ticks stay in this browser. They are not written back to the engagement file.
7. How this shows up in a VAPT
On a cloud security assessment, fold Loom and Studio Spaces into the identity scope rather than an “AI feature” appendix. The findings that matter are: unauthenticated control-plane exposure, write scopes wider than the admin set, agent roles that can change themselves or reach data planes, Spaces that share a project with TIP, and end-of-support images still starting. Retest is a version check plus a fresh group export, not a second exploit attempt.
Related notes in this set: self-hosted GitLab AI Gateway (a different trust boundary: template sandbox to the gateway host) and helpdesk as a launch point (an agent as the intruder, not as the product). SageMaker’s neighbour-credential issue is closer to identity before configuration than to prompt injection.
Sources
- AWS security bulletin 2026-124-AWS (published 2 October 2026)
- AWS security bulletin 2026-125-AWS (published 2 October 2026)
- CVE-2026-103956, CVE-2026-103957, CVE-2026-103958, CVE-2026-104019
- SecurityOnline summary (secondary)
Frequently asked questions
Does CVE-2026-103956 affect every Loom deployment?
No. AWS and the CVE record limit the unauthenticated super-admin outcome to deployments before 1.6.1 where no identity provider is configured. Deployments with Cognito or an external IdP still need 1.7.0 because CVE-2026-103957 and CVE-2026-103958 are fixed only there, and they apply to authenticated users who hold mcp:write or a2a:write.
Is restricting admin groups a workaround?
For the two authenticated issues, AWS says restricting those scopes to trusted administrators reduces likelihood but does not fully close the issue. For CVE-2026-103956 the pre-upgrade control is an identity provider plus keeping the local-dev bypass unset. SageMaker CVE-2026-104019 has no workaround; restart supported Spaces and leave end-of-support lines.
Should we rotate credentials after upgrading?
Yes, when the bulletin’s conditions may have been met. Rotate MCP/A2A OAuth client secrets, revoke and re-issue access tokens from the affected window, and if container role credentials may have been read, rotate those session credentials and review CloudTrail. Upgrading alone does not invalidate secrets that already left.
Does this replace a cloud penetration test?
No. It is a focused control-plane and Space review that should sit inside a human-led cloud assessment: real principals, real role policies, version evidence and a retest. It is not a scanner plugin and it is not a proof-of-concept exercise.