The Pulse
AWS corregge un aggiramento dell’autenticazione di Loom e due vulnerabilità relative ai token
AWS ha reso note tre vulnerabilità di sicurezza in Loom for AWS, tra cui un aggiramento dell’autenticazione che, in assenza di un provider di identità configurato, poteva esporre il piano di controllo degli agenti. L’azienda raccomanda di a
AI.info Team · Scritto con l’IA ·
Il 2 ottobre AWS ha reso note tre vulnerabilità di sicurezza in Loom for AWS, tra cui un aggiramento dell’autenticazione che poteva consentire a un client di rete non autenticato di ottenere il pieno controllo amministrativo della piattaforma degli agenti. La vulnerabilità interessava le installazioni prive di un provider di identità configurato e, secondo AWS, è stata corretta nella versione 1.6.1 di Loom, rilasciata il 4 agosto. L’azienda raccomanda di aggiornare Loom alla versione 1.7.0, che corregge tutte e tre le vulnerabilità.
AWS classifica l’avviso come «Importante (richiede attenzione)», non come critico. Le sue raccomandazioni riguardano anche le organizzazioni che utilizzano fork o versioni derivate: dovrebbero integrare le correzioni, anziché presumere che il solo numero di versione del progetto originale elimini la loro esposizione.
L’aggiramento dell’autenticazione raggiungeva il piano di controllo degli agenti di Loom
La vulnerabilità nell’autenticazione, identificata come CVE-2026-103956, interessava le versioni di Loom precedenti alla 1.6.1. Secondo AWS, in un’installazione senza un provider di identità configurato, qualsiasi client di rete poteva inviare una richiesta all’API dell’applicazione e ottenere pieni privilegi amministrativi sul piano di controllo degli agenti.
Questi privilegi potevano consentire a un aggressore di registrare server degli strumenti, leggere le credenziali memorizzate per le integrazioni e riscrivere le policy dei ruoli IAM associati ai ruoli degli agenti gestiti. Nella descrizione di AWS, la condizione relativa alla configurazione è centrale: l’aggiramento dell’autenticazione si verificava dove non era configurato alcun provider di identità, non per impostazione predefinita in ogni installazione di Loom.
Altre due vulnerabilità riguardavano le richieste in uscita
Le altre vulnerabilità riguardano gli utenti autenticati con lo scope mcp:write o a2a:write. CVE-2026-103957 riguardava la gestione della discovery OAuth2: un utente poteva impostare un URL di discovery il cui documento induceva il backend di Loom a inviare i segreti del client OAuth2 o il token di accesso di un altro utente a un endpoint controllato da una terza parte. La versione 1.6.1 ha bloccato l’accesso agli indirizzi interni in questo percorso del codice, ma secondo AWS non ha risolto completamente il problema della divulgazione dei token; la versione 1.7.0 lo risolve.
CVE-2026-103958 interessava le connessioni ai server degli strumenti che utilizzano MCP e agli agenti remoti che utilizzano A2A. Un utente autenticato con il pertinente scope di scrittura poteva indirizzare le richieste di connessione verso posizioni arbitrarie della rete interna, compreso l’endpoint del container che fornisce credenziali, e leggere le risposte. Secondo AWS, anche questa vulnerabilità è corretta nella versione 1.7.0.
Gli aggiornamenti sono solo una parte della risposta
Per le installazioni in attesa di un aggiornamento, AWS consiglia di configurare un pool di utenti Cognito o un provider di identità esterno attivo prima di rendere il backend raggiungibile oltre l’interfaccia di loopback. Indica inoltre di assicurarsi che LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV non sia impostata negli ambienti in cui Loom è stato distribuito. Per le due vulnerabilità relative alle richieste in uscita, limitare gli scope di scrittura MCP e A2A agli amministratori fidati può ridurre la probabilità di sfruttamento, ma secondo AWS tale limitazione non sostituisce la correzione del codice.
Dopo l’aggiornamento, AWS raccomanda di sostituire i segreti dei client OAuth2 usati per le integrazioni MCP o A2A e di revocare e riemettere i token di accesso attivi durante il periodo interessato. Se è possibile che sia stato effettuato l’accesso alle credenziali del ruolo del container, l’azienda consiglia di sostituire le credenziali di sessione del ruolo IAM e di esaminare CloudTrail per individuare eventuali usi non previsti. AWS attribuisce a Kenneth Cox la collaborazione nell’ambito del suo processo coordinato di divulgazione.