Ruflo espone gli agenti AI, VMware corregge tre falle critiche

🛡️ Executive Summary

• Ruflo esponeva senza autenticazione 233 strumenti MCP, inclusa l’esecuzione di comandi, nelle installazioni Docker predefinite.
• Un attaccante può rubare chiavi API, leggere conversazioni e modificare la memoria persistente che orienta le risposte future degli agenti AI.
• Broadcom corregge in VMware due falle pre-auth di vCenter e una VM escape sfruttabile da un amministratore della macchina virtuale.

Ruflo e VMware hanno corretto vulnerabilità critiche capaci di compromettere due infrastrutture centrali per le aziende: gli orchestratori di agenti AI e le piattaforme di virtualizzazione. CVE-2026-59726 consentiva a un utente non autenticato di invocare strumenti MCP di Ruflo, eseguire comandi nel container, sottrarre chiavi dei provider e alterare la memoria persistente degli agenti. Broadcom ha invece pubblicato aggiornamenti per cinque falle in ESX, vCenter, Workstation e Fusion, comprese due vulnerabilità pre-auth da 9,8 in vCenter e una scrittura fuori limite capace di trasformarsi in una fuga dalla macchina virtuale verso l’host.

Ruflo lasciava il bridge MCP aperto sulla rete

Ruflo, progetto precedentemente conosciuto come Claude Flow, è una piattaforma open source per coordinare swarm di agenti, workflow autonomi e sistemi basati su Anthropic Claude Code e OpenAI Codex. Nelle versioni precedenti alla 3.16.3, il file docker-compose.yml collegava la porta 3001 del bridge MCP a 0.0.0.0, rendendo il servizio raggiungibile da tutte le interfacce di rete. Gli endpoint POST /mcp e POST /mcp/:group non richiedevano autenticazione e permettevano di invocare direttamente 233 strumenti, comprese funzioni per terminale, database, gestione degli agenti e memoria. L’esposizione effettiva dipendeva da firewall, security group e segmentazione, ma qualsiasi istanza raggiungibile risultava sfruttabile senza account e senza interazione dell’utente. Una singola richiesta JSON-RPC poteva richiamare ruflo__terminal_execute e avviare comandi all’interno del container con l’utente node, identificato dal valore uid 1000. La falla, denominata RufRoot dai ricercatori di Noma Security, ha ricevuto il punteggio massimo CVSS 10,0. Il problema sviluppa i rischi già descritti con la vulnerabilità RCE nel server MCP di Anthropic, ma sposta l’attacco dal singolo strumento a un orchestratore capace di controllare interi gruppi di agenti.

L’attaccante può rubare tutte le chiavi dei provider AI

L’accesso alla shell non resta confinato al bridge. Le chiavi utilizzate da Ruflo per collegarsi a OpenAI, Anthropic, Google e OpenRouter possono essere conservate nelle variabili d’ambiente del container e diventare quindi leggibili dall’attaccante. I token sottratti possono essere usati per consumare risorse a spese della vittima, interrogare modelli attraverso l’account compromesso o creare swarm controllati dall’esterno. Il database MongoDB risultava inoltre esposto su tutte le interfacce senza autenticazione nelle configurazioni Docker vulnerabili, permettendo di raggiungere conversazioni, dati degli utenti e informazioni operative. La compromissione di un orchestratore agentico assume così una dimensione diversa rispetto alla normale RCE su un’applicazione web: chi entra non acquisisce soltanto il server, ma anche le identità con cui gli agenti comunicano con i provider e gli strumenti aziendali. Il precedente sul tool poisoning nei server MCP e sul rischio di esfiltrazione per gli agenti AI aveva già mostrato come il protocollo possa trasferire fiducia a funzioni esterne; RufRoot dimostra che un bridge privo di autenticazione può consegnare direttamente all’attaccante tutte le capacità operative disponibili.

La memoria avvelenata sopravvive alla prima intrusione

La conseguenza più peculiare riguarda AgentDB, il sistema con cui Ruflo conserva pattern di apprendimento e informazioni persistenti utilizzate dagli agenti. L’aggressore può inserire voci malevole nel pattern-store, modificando le istruzioni che influenzano le risposte e il comportamento futuro del sistema. Questa forma di memory poisoning può continuare a produrre effetti dopo la chiusura della sessione iniziale e persino dopo l’applicazione della patch, se le informazioni alterate non vengono individuate e rimosse. Un pattern fraudolento potrebbe spingere gli agenti a scegliere strumenti controllati dall’attaccante, ignorare determinate verifiche, divulgare dati o applicare procedure operative manipolate. L’incidente non riguarda quindi soltanto integrità di file e container, ma la continuità cognitiva dell’applicazione. Un software tradizionale viene normalmente ripristinato sostituendo codice e configurazione; un sistema agentico richiede anche l’ispezione delle memorie, delle conoscenze accumulate e delle istruzioni persistenti. La dinamica è coerente con gli attacchi di prompt injection indiretta tramite repository GitHub contro gli agenti AI, ma in questo caso l’attaccante scrive direttamente nel deposito utilizzato per orientare tutte le esecuzioni successive.

Ruflo 3.16.3 modifica le impostazioni predefinite

La correzione pubblicata nella versione 3.16.3 vincola il bridge MCP a 127.0.0.1 per impostazione predefinita e impedisce l’avvio su un indirizzo pubblico quando non è configurato MCP_AUTH_TOKEN. La release introduce autenticazione Bearer, confronto del token a tempo costante, una allowlist CORS e un controllo server-side che disabilita terminal_execute salvo attivazione esplicita mediante MCP_ENABLE_TERMINAL=true. Anche MongoDB richiede ora autenticazione e la variabile MONGO_INITDB_ROOT_PASSWORD, mentre il filesystem principale del container viene montato in sola lettura con aree temporanee dedicate. Gli operatori che hanno esposto versioni precedenti devono chiudere immediatamente le porte 3001 e 27017, ruotare tutte le chiavi dei provider AI, controllare MongoDB e cercare voci agentdb_pattern-store non autorizzate. Il bollettino ufficiale di Ruflo su CVE-2026-59726 chiarisce che il semplice redeploy corretto non elimina i pattern già avvelenati e che le istanze compromesse devono essere ricostruite da immagini pulite.

VMware vCenter espone due vulnerabilità pre-auth

Il bollettino VMSA-2026-0006 corregge cinque vulnerabilità nei prodotti VMware, delle quali due interessano direttamente vCenter e possono essere sfruttate da un attaccante remoto con accesso di rete. CVE-2026-59309, valutata 9,8, è un bypass dell’autenticazione nel VMware Directory Service che permette di ottenere accesso non autorizzato al sistema. CVE-2026-59310, anch’essa da 9,8, è una directory traversal nel server Syslog di vCenter che può portare all’esecuzione di codice arbitrario. Broadcom non ha pubblicato dettagli tecnici sufficienti a costruire la catena completa e dichiara di non avere rilevato sfruttamento attivo, ma non offre workaround: l’unica remediation consiste nell’applicazione degli aggiornamenti. Le falle sono corrette in vCenter 9.1.0.0300, 9.0.2.0100 e 8.0 U3k, mentre VMware Cloud Foundation 5.x richiede una patch asincrona verso 8.0 U3k. La posizione centrale di vCenter amplifica l’impatto, perché la piattaforma controlla host, macchine virtuali, ruoli, credenziali e configurazioni dell’intera infrastruttura. I precedenti attacchi descritti nell’analisi sulle vulnerabilità VMware ESXi sfruttate nei ransomware mostrano perché una compromissione del piano di gestione possa diventare il passaggio iniziale verso cifratura, furto di dati e sabotaggio delle copie virtuali.

VMXNET3 permette la fuga dalla macchina virtuale

La terza vulnerabilità critica è CVE-2026-47876, scrittura fuori limite nell’adattatore di rete virtuale VMXNET3 di VMware ESX, valutata 9,3. Lo sfruttamento richiede privilegi amministrativi locali all’interno di una macchina virtuale configurata con questo adattatore, ma consente di eseguire codice sull’host ESX. Broadcom la classifica esplicitamente come virtual machine escape, perché rompe il confine che dovrebbe isolare guest e hypervisor. La necessità di essere già amministratori della VM riduce la superficie rispetto alle due falle pre-auth di vCenter, ma non rende il problema secondario: un attaccante che abbia compromesso un server virtuale può usare la vulnerabilità per raggiungere l’host e potenzialmente altre macchine ospitate sulla stessa infrastruttura. Le versioni corrette comprendono ESXi 9.1.0.0200-25557999, 9.0.2.0100-25595025 ed ESXi 8.0 U3k-25595708. Il rischio di catene guest-to-host era già emerso con gli exploit ESXi osservati negli attacchi reali per ottenere la fuga dalle macchine virtuali, nei quali l’accesso iniziale a un workload diventava il punto di partenza per compromettere l’intero livello di virtualizzazione.

Broadcom corregge anche disclosure, DoS e logging insufficiente

Il pacchetto VMware comprende altre due vulnerabilità con severità inferiore. CVE-2026-41703, valutata 7,6, è una lettura fuori limite in ESX che un utente con permessi per distribuire macchine virtuali può provocare per ottenere informazioni o causare una condizione di denial of service; su Workstation e Fusion l’impatto è limitato alla divulgazione di dati. CVE-2026-41709, valutata 2,7, riguarda invece una registrazione insufficiente delle operazioni effettuate da un amministratore malevolo. Quest’ultimo problema non consente da solo l’accesso, ma può rendere più difficile ricostruire attività svolte da un account già privilegiato. Broadcom ha corretto le falle in versioni differenti di ESX, Workstation, Fusion e Cloud Foundation e precisa che non esistono workaround per l’intero bollettino. Gli amministratori devono quindi consultare la matrice ufficiale, applicare gli aggiornamenti specifici per ciascun ramo e verificare che vCenter, host ESX e software desktop siano tutti coperti, evitando di considerare sufficiente il solo aggiornamento del server di gestione.

Agenti e hypervisor richiedono verifiche dopo la patch

Le vulnerabilità condividono la capacità di superare confini di fiducia, ma richiedono risposte differenti. Ruflo esponeva direttamente strumenti potenti senza autenticazione e permetteva di modificare anche la memoria persistente del sistema AI; VMware presenta invece due falle remote su vCenter e una VM escape che richiede il controllo amministrativo di un guest. Per Ruflo, la remediation deve includere rotazione delle chiavi, ricostruzione dei container, verifica del database e bonifica dell’AgentDB. Per VMware, gli amministratori devono installare le versioni corrette, restringere l’accesso a vCenter, cercare account o attività amministrative anomale e controllare gli host che eseguono VM con adattatore VMXNET3. La ricostruzione della vulnerabilità Ruflo MCP e il bollettino ufficiale Broadcom VMSA-2026-0006 mostrano che applicare una patch chiude il vettore noto, ma non annulla credenziali rubate, memorie AI alterate, sessioni amministrative create o accessi ottenuti dall’host. Quando il componente compromesso orchestra agenti o macchine virtuali, la fiducia deve essere ricostruita nell’intero ecosistema e non soltanto nel software vulnerabile.