CVE-2026-103956 – Loom für AWS – Kritisch – Authentifizierungsumgehung – unauthentifizierter Super-Admin, wenn kein IdP konfiguriert ist
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · cve-2026-103956-loom-unauth
Loom for AWS < 1.6.1 - AWS Labs
Wenn Cognito nicht gesetzt ist und kein externer IdP aktiv ist, übergibt get_current_user jeder Anfrage t-admin / g-admins-super. Das schließt Anfragen ohne Authorization-Header ein. Ein frisches Deployment vor der IdP-Einrichtung ist ein offenes Admin-Panel.
| ID | CVE-2026-103956 |
| CWE | CWE-306 / CWE-1188 |
| CVSS | Kritisch: 10.0 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Produkt | Loom for AWS |
| Betroffen | < 1.6.1. Lab-Pin v1.6.0 (8c658d61). Behoben in v1.6.1 (ccad5665). |
| Auth | unauthentifiziert |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
Der Angreifer übernimmt die Agent Control Plane ohne jegliche Zugangsdaten.
GET /api/auth/me ohne Header liefert username=local-dev, sub=local, Gruppen t-admin und g-admins-super. Jeder Scope in GROUP_SCOPES kommt mit dieser Identität.POST /api/mcp/servers ist 201. MCP, A2A, Agents, Memories, Security, Settings, Credentials und Admin-Audit hängen hinter derselben Dependency.GET /api/mcp/servers/{id}/export ist admin:write. Bei diesem Pin liefert es oauth2_client_secret aus SQLite zurück. Der CVE-Text nennt außerdem das Umschreiben von IAM-Rollen-Policies bei verwalteten Agent-Rollen; dieser Pfad erfordert AWS und liegt außerhalb dieses Loopback-Labs.v1.6.1 erfordert LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV plus einen Loopback-Client. Dieselbe Anfrage ist 401 (No identity provider configured).
AWS veröffentlichte CVE-2026-103956 mit GHSA-vgmj-998f-r8mp und Bulletin 2026-124-AWS. Ich habe awslabs/loom v1.6.0 (8c658d61) neben v1.6.1 (ccad5665) gepinnt und das Backend auf SQLite mit nicht gesetztem LOOM_COGNITO_USER_POOL_ID ausgeführt.
backend/app/dependencies/auth.py get_current_user prüft Cognito-Env und eine aktive IdP-Zeile. Beide leer: Es liefert UserInfo(sub="local", username="local-dev", groups=["t-admin", "g-admins-super"], scopes=ALL_SCOPES). Das Token wird nie gelesen.
Ich habe Stock-FastAPI auf Loopback 127.0.0.1:18180 (v1.6.0) und 18181 (v1.6.1) hochgezogen. Kein Frontend. Kein AWS. Unauthentifiziertes GET /api/auth/me auf 1.6.0 war 200 mit diesen Gruppen. Unauthentifiziertes POST /api/mcp/servers mit oauth2_client_secret=CVE-2026-103956-WITNESS war 201. GET /api/mcp/servers/1/export gab das Secret zurück. Auf 1.6.1 war dasselbe /api/auth/me 401.
SUCCESS CVE-2026-103956 me-http=200 me-user=local-dev me-sub=local me-groups=t-admin,g-admins-super mcp-create=201 export-has-secret=yes list-has-witness=yes patched-me-http=401 CVE-2026-103956-WITNESS
Bereits dokumentierte Irrwege: public.ecr.aws/docker/library/python:3.13-slim wurde zugunsten von Docker Hub python:3.13-slim übersprungen; erstes /health auf v1.6.0 war curl 52, während uvicorn gebunden war, dann 200; MCP-Create-Schema passte beim ersten POST, kein 422-Retry. Eine Reverse Shell. Theater. Das Orakel ist /api/auth/me plus das exportierte Secret.
cd lab
./run.sh
Ziel nur http://127.0.0.1:18180 (v1.6.0) und http://127.0.0.1:18181 (v1.6.1). run.sh klont diese Tags shallow, baut beide Backends und baut den Stack danach ab. SQLite. Keine Cognito-Env. Kein LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV auf dem gepatchten Service.
Upgrade auf 1.6.1 oder später. AWS empfiehlt 1.7.0 für die verwandten SSRF-/Token-Probleme. Der 1.6.1-Bypass ist Opt-in und nur Loopback. Bis dahin Cognito oder einen externen IdP fertigstellen, bevor das Backend über Loopback hinaus erreichbar ist, und LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV auf allem Deployten nicht setzen.
backend/app/dependencies/auth.py (get_current_user)