abraxas/cve-2026-103956-loom-unauthCVE-2026-103956 - Loom per AWS - Critico - Bypass dell'autenticazione - super-admin non autenticato quando non è configurato alcun IdP
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · cve-2026-103956-loom-unauth
Loom for AWS < 1.6.1 - AWS Labs
Quando Cognito non è configurato e nessun IdP esterno è attivo, get_current_user assegna a ogni richiesta t-admin / g-admins-super. Questo include le richieste senza header Authorization. Un deploy appena eseguito prima della configurazione dell'IdP è un pannello di amministrazione aperto.
| ID | CVE-2026-103956 |
| CWE | CWE-306 / CWE-1188 |
| CVSS | Critical: 10.0 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Prodotto | Loom for AWS |
| Affetto | < 1.6.1. Pin del lab v1.6.0 (8c658d61). Corretto in v1.6.1 (ccad5665). |
| Auth | non autenticato |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
L'attaccante controlla il piano di controllo degli agenti senza alcuna credenziale.
GET /api/auth/me senza header restituisce username=local-dev, sub=local, gruppi t-admin e g-admins-super. Ogni scope in GROUP_SCOPES viene fornito con quell'identità.POST /api/mcp/servers non autenticato restituisce 201. MCP, A2A, agenti, memorie, sicurezza, impostazioni, credenziali e audit di amministrazione si trovano dietro la stessa dipendenza.GET /api/mcp/servers/{id}/export è admin:write. Su questo pin restituisce oauth2_client_secret da SQLite. Il testo della CVE menziona anche la riscrittura delle policy dei ruoli IAM sui ruoli degli agenti gestiti; quel percorso richiede AWS ed è al di fuori di questo lab su loopback.v1.6.1 richiede LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV più un client su loopback. La stessa richiesta restituisce 401 (No identity provider configured).
AWS ha pubblicato CVE-2026-103956 con GHSA-vgmj-998f-r8mp e il bollettino 2026-124-AWS. Ho messo a confronto awslabs/loom v1.6.0 (8c658d61) con v1.6.1 (ccad5665) ed eseguito il backend su SQLite con LOOM_COGNITO_USER_POOL_ID non impostato.
backend/app/dependencies/auth.py get_current_user controlla le variabili d'ambiente di Cognito e una riga IdP attiva. Entrambe vuote: restituisce UserInfo(sub="local", username="local-dev", groups=["t-admin", "g-admins-super"], scopes=ALL_SCOPES). Il token non viene mai letto.
Ho avviato FastAPI standard su loopback 127.0.0.1:18180 (v1.6.0) e 18181 (v1.6.1). Nessun frontend. Nessun AWS. GET /api/auth/me non autenticato su 1.6.0 restituiva 200 con quei gruppi. POST /api/mcp/servers non autenticato con oauth2_client_secret=CVE-2026-103956-WITNESS restituiva 201. GET /api/mcp/servers/1/export restituiva il segreto. Su 1.6.1 lo stesso /api/auth/me restituiva 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
Vicoli ciechi già registrati: public.ecr.aws/docker/library/python:3.13-slim è stato scartato per Docker Hub python:3.13-slim; il primo /health su v1.6.0 è stato curl 52 mentre uvicorn era in ascolto, poi 200; lo schema di creazione MCP ha corrisposto al primo POST, nessun retry 422. Una reverse shell. Teatro. L'oracolo è /api/auth/me più il segreto esportato.
cd lab
./run.sh
Target solo http://127.0.0.1:18180 (v1.6.0) e http://127.0.0.1:18181 (v1.6.1). run.sh esegue shallow-clone di quei tag, compila entrambi i backend, poi smonta lo stack. SQLite. Nessuna variabile d'ambiente Cognito. Nessun LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV sul servizio corretto.
Aggiorna a 1.6.1 o successivo. AWS raccomanda 1.7.0 per i problemi SSRF/token correlati. Il bypass di 1.6.1 è opt-in e solo su loopback. Fino ad allora, completa Cognito o un IdP esterno prima che il backend sia raggiungibile al di fuori del loopback, e mantieni LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV non impostato su qualsiasi cosa distribuita.
backend/app/dependencies/auth.py (get_current_user)