AWS lapper tre hull i agentplattformen Loom: CVSS 10 for admin-tilgang uten innlogging

AWS publiserte 2. oktober sikkerhetsbulletinen 2026-124-AWS om tre sårbarheter i Loom for AWS, AWS Labs' åpne plattform for å bygge og drifte KI-agenter på Amazon Bedrock AgentCore og Strands Agents. Den alvorligste, CVE-2026-103956, har CVSS-score 10,0 i GitHub-advisoryen. Når verken en Cognito-brukerpool eller en ekstern identitetsleverandør var satt opp, ga autentiseringslaget hver eneste forespørsel, også de uten Authorization-header, en fast super-admin-identitet med alle scopes i systemet.

Med den tilgangen kunne en hvilken som helst klient på nettverket registrere verktøyservere, lese lagrede credentials for integrasjoner og skrive om IAM-policyene til agentrollene, ifølge bulletinen.

«Dette er ikke et sjeldent hjørnetilfelle: det er tilstanden til en nyinstallert instans før en operatør har fullført oppsettet av IdP» — AWS, i GitHub-advisoryen for CVE-2026-103956

Fiksen kom allerede i versjon 1.6.1 4. august, nesten to måneder før hullet ble offentliggjort. Nå må du eksplisitt slå på LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV for å kjøre uten innlogging, og selv da slipper bare forespørsler fra loopback gjennom.

De to andre hullene krever innlogging, men bare med scopet mcp:write eller a2a:write, altså retten til å registrere en MCP-verktøyserver eller en A2A-agent. CVE-2026-103957 (CVSS 6,2) lot en slik bruker oppgi en discovery-URL for OAuth2 der dokumentet pekte token_endpoint mot en tredjepartsserver. Backenden sendte da klienthemmeligheten, eller i on-behalf-of-modus en annen brukers ekte access token, rett dit. SSRF-sperren sjekket bare at målet var en offentlig HTTPS-adresse, ikke at den tilhørte deployets egen identitetsleverandør. CVE-2026-103958 (CVSS 7,6) er klassisk SSRF: tilkoblingene til MCP-servere og A2A-agenter validerte verken oppløst IP eller redirect-mål, så en forespørsel kunne nå containerens credential-endepunkt og lese svaret.

Å begrense de to scopene til betrodde administratorer er eneste midlertidige tiltak for de to siste hullene.

«Dette reduserer sannsynligheten for at problemene utløses, men lukker ikke hullet helt uten kodefiksen» — AWS, i sikkerhetsbulletin 2026-124-AWS

Bulletinen anbefaler versjon 1.7.0 fra 20. september, men nyeste utgave er 1.7.4 fra 29. september. Release-notatene for 1.7.1 til 1.7.4 lukker flere tilgangshull: enhver innlogget bruker kunne avgjøre en annen brukers ventende human-in-the-loop-godkjenning hvis vedkommende kjente request_id, og admins for enkeltdomener kunne endre globale innstillinger for hele deployet.

For deg som bygger egen agentplattform er lærdommen konkret. Et MCP-register der brukere selv legger inn endpoint-URL-er er en SSRF-flate fra første dag, og hver utgående forespørsel må valideres mot oppløst IP også etter redirect, ikke bare mot vertsnavnet. En lokal dev-modus som slår av autentisering bør være opt-in og låst til loopback, slik Loom nå gjør.

Hva bør du gjøre?

1. Oppgrader til Loom 1.7.4, og sørg for at forks og kode du har avledet fra prosjektet får de samme fiksene.
2. Sjekk at LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV ikke er satt i noe deploy utenfor lokal utvikling, og at Cognito eller en ekstern identitetsleverandør er aktiv før backenden kan nås utenfor loopback.
3. Roter OAuth2-klienthemmelighetene for MCP- og A2A-integrasjonene etter oppgraderingen, tilbakekall tokens som var aktive i perioden, og gå gjennom CloudTrail hvis containerrollens credentials kan ha blitt lest.