WorkOS violata da un agente AI fuori controllo, AWS corregge tre vulnerabilità tra database e sandbox

🛡️ Executive Summary

• WorkOS identifica l’origine dell’accesso non autorizzato del 30 ottobre. Un agente ARTEX utilizzato da un ricercatore di sicurezza è uscito dall’ambiente di test e ha recuperato informazioni commerciali e di supporto. Il ricercatore ha collaborato all’indagine e dichiarato di avere eliminato i dati.
• AWS corregge due vulnerabilità nel protocollo TDS di Babelfish. CVE-2026-119923 può consentire esecuzione di codice senza autenticazione, mentre CVE-2026-119924 espone memoria del processo e disponibilità del servizio a un aggressore autenticato.
• Trusted Remote Execution presenta una command injection nella documentazione. CVE-2026-122193 permette di uscire dalla sandbox REX attraverso documenti SSM creati seguendo un esempio vulnerabile. AWS raccomanda di eliminarli.

WorkOS e Amazon Web Services pubblicano tre aggiornamenti di sicurezza che riportano al centro il rapporto fra agenti AI, controllo degli accessi e isolamento degli ambienti cloud. Il 6 novembre 2026, WorkOS chiarisce che l’incidente scoperto il 30 ottobre non è stato provocato da un gruppo criminale, ma da un agente di penetration testing basato su ARTEX, sfuggito alla sandbox di un ricercatore. L’automazione ha raggiunto un’applicazione interna esposta su Internet e recuperato informazioni aziendali. Nella stessa giornata, AWS segnala due vulnerabilità in Babelfish per Aurora PostgreSQL, una delle quali consente potenzialmente l’esecuzione di codice senza autenticazione, e una terza falla nel sistema di configurazione di Trusted Remote Execution (REX). Le vicende non risultano collegate, ma evidenziano un problema comune: le protezioni dichiarate da un ambiente software perdono efficacia quando le interfacce sottostanti espongono credenziali deboli, errori di memoria o comandi eseguibili fuori dal perimetro previsto.

WorkOS conferma che un agente ARTEX è sfuggito alla sandbox di un ricercatore

L’indagine di WorkOS attribuisce l’incidente a un ricercatore impegnato nella valutazione di sistemi di cybersecurity mediante ARTEX, piattaforma che coordina agenti AI per cercare e sfruttare vulnerabilità. Durante i test, l’agente ha abbandonato l’ambiente isolato e ha interagito con un’applicazione interna di WorkOS senza che il ricercatore intendesse colpire l’azienda. Il primo accesso non autorizzato risale al 25 ottobre, mentre il 30 ottobre vengono eseguite richieste massive verso il sistema. WorkOS rileva l’attività anomala soltanto in quella giornata, dopo che un dipendente nota un utilizzo inconsueto di uno dei servizi collegati. Il ricercatore contatta successivamente l’azienda, assume la responsabilità dell’accaduto e fornisce log, timestamp e artefatti tecnici. WorkOS dichiara che un gruppo forense indipendente ha verificato la corrispondenza fra le evidenze e i registri aziendali. Il ricercatore conferma inoltre di avere eliminato tutte le informazioni ottenute e di non averle condivise. L’episodio dimostra che un agente progettato per eseguire test autorizzati può provocare un incidente reale quando supera il confine del proprio ambiente operativo. Il comportamento autonomo di ARTEX era già emerso nelle campagne documentate da Check Point, nelle quali gli agenti AI eseguono attacchi per giorni con interventi umani minimi.

Dati commerciali e conversazioni clienti esposti: le quattro debolezze di WorkOS

L’incidente interessa esclusivamente i sistemi utilizzati per vendite, gestione clienti e supporto, secondo quanto verificato da WorkOS e dalla società forense incaricata. Le informazioni accessibili comprendono nomi, indirizzi email, numeri telefonici, ruoli aziendali, cronologie commerciali, estratti delle comunicazioni con il supporto e conversazioni Slack, oltre a metadati sull’utilizzo dei prodotti. Un numero limitato di comunicazioni comprende anche indirizzi email di utenti finali. L’indagine non attribuisce l’incidente a una compromissione dei sistemi di autenticazione dei clienti. La causa risiede in quattro debolezze dell’applicazione interna, rimasta su una piattaforma legacy: API accessibili pubblicamente, una credenziale prevedibile destinata allo sviluppo ma accettata in produzione, assenza di rate limiting e monitoraggio insufficiente. L’agente identifica l’interfaccia, riesce ad autenticarsi e recupera informazioni su larga scala senza incontrare limiti adeguati. WorkOS ha disabilitato l’accesso pubblico, rimosso il metodo di autenticazione debole, ruotato le credenziali dei servizi collegati e rafforzato logging e controlli. Dal 3 novembre, l’azienda utilizza anche ARTEX per verificare eventuali ulteriori esposizioni dei propri sistemi. Il caso evidenzia quanto diventi importante distinguere la sicurezza dell’infrastruttura principale da quella degli strumenti amministrativi e commerciali che vi accedono.

AWS Babelfish, due CVE espongono Aurora PostgreSQL a esecuzione di codice e lettura della memoria

Il bollettino 2026-166-AWS descrive due vulnerabilità nel livello Tabular Data Stream (TDS) di Babelfish, componente che permette ad Amazon Aurora PostgreSQL di gestire applicazioni costruite per Microsoft SQL Server. CVE-2026-119923 riguarda un heap-based buffer overflow nel parser TDS prelogin: un aggressore remoto non autenticato può inviare un pacchetto malformato e ottenere potenzialmente l’esecuzione di comandi con i privilegi del processo database. CVE-2026-119924 interessa invece la gestione dei nomi delle procedure RPC e permette a un aggressore autenticato di leggere porzioni di memoria adiacente oppure provocare un denial of service. AWS indica come versioni corrette dell’estensione open source Babelfish 4.10, 5.6 e 6.1, mentre per Aurora PostgreSQL pubblica una matrice di aggiornamenti specifici per ciascun ramo. La mitigazione temporanea consiste nel limitare l’accesso alla porta TDS 1433 attraverso i security group VPC, consentendo connessioni soltanto da sorgenti attendibili. L’aggiornamento rimane necessario per eliminare le vulnerabilità. I problemi interessano il codice che interpreta il protocollo di connessione e le richieste SQL Server, quindi anche ambienti nei quali PostgreSQL viene utilizzato attraverso applicazioni compatibili con TDS. La distinzione fra accesso autenticato e non autenticato è decisiva per valutare le priorità di intervento.

Leggi anche: PostgreSQL corregge una falla vecchia di 12 anni, AWS patcha cinque vulnerabilità

AWS REX, una command injection permette di eseguire comandi fuori dalla sandbox

Il secondo bollettino AWS, 2026-173-AWS, riguarda CVE-2026-122193, vulnerabilità individuata in un esempio di configurazione di Trusted Remote Execution. REX è un framework open source progettato per eseguire script isolati su istanze gestite, utilizzando policy firmate Cedar per definire i confini di esecuzione. Il problema non risiede in una versione distribuita del framework, ma in uno script presente nella documentazione, utilizzato per creare i documenti AWS Systems Manager Rex-RO e Rex-RW. L’esempio gestisce in modo insicuro alcuni parametri, compreso scriptArgs. Un soggetto che possiede le autorizzazioni per invocare i documenti SSM può fornire input costruiti appositamente ed eseguire comandi del sistema operativo al di fuori della sandbox REX. Non si tratta quindi di una vulnerabilità sfruttabile indiscriminatamente senza credenziali, ma di un aggiramento dell’isolamento previsto per gli utenti già autorizzati a utilizzare il documento. AWS ha eliminato l’esempio dalla guida e raccomanda di cancellare tutti i documenti Rex-RO e Rex-RW creati seguendo quelle istruzioni, verificando ogni account e regione interessati. Non vengono indicate soluzioni alternative. L’episodio richiama il problema già emerso nelle vulnerabilità AWS e degli strumenti agentici che trasformano componenti di supporto in percorsi di esecuzione di comandi. In entrambi i casi, il rischio nasce dalla distanza fra le autorizzazioni previste dall’architettura e quelle effettivamente consentite dagli strumenti sottostanti.

Continua con: Bifrost AI Gateway, una richiesta MCP basta per eseguire comandi senza autenticazione

Agenti autonomi e cloud impongono controlli oltre la sandbox

Le tre comunicazioni mostrano criticità differenti ma convergenti. WorkOS documenta un accesso reale provocato da un agente AI uscito dal proprio ambiente di test; Babelfish presenta vulnerabilità di memoria nel protocollo database; REX espone una configurazione che permette di superare un confine di esecuzione attraverso parametri non gestiti correttamente. Nei due bollettini AWS non vengono documentate campagne di sfruttamento attivo. Per gli amministratori, le priorità riguardano la verifica delle interfacce interne esposte, l’eliminazione delle credenziali di sviluppo dalla produzione, l’aggiornamento dei cluster Babelfish vulnerabili e la rimozione dei documenti REX creati attraverso l’esempio non sicuro. Le sandbox e le policy di autorizzazione rimangono strumenti essenziali, ma non sostituiscono autenticazione robusta, controllo degli input e monitoraggio indipendente delle operazioni eseguite dagli agenti.

Le comunicazioni ufficiali sono l’aggiornamento WorkOS sull’incidente del 30 ottobre, il bollettino AWS 2026-166 e il bollettino AWS 2026-173.