Una vulnerabilità critica scoperta in Ruflo permette a un attaccante di eseguire comandi da remoto senza autenticazione e di manipolare la memoria persistente di un sistema AI. Per un’azienda, questo significa non solo rischio di intrusione tecnica, ma anche esposizione di chiavi API, conversazioni e comportamenti futuri dell’assistente AI.
Il punto più importante è questo: se in azienda state sperimentando piattaforme AI open source o ambienti multi-agente esposti in rete, aggiornare il software non basta. Occorre verificare subito esposizione, credenziali, dati archiviati e integrità del sistema.
Che cosa è successo
Il 29 luglio 2026 The Hacker News ha riportato una vulnerabilità di gravità massima in Ruflo, piattaforma open source usata come “meta-harness” per orchestrare agenti AI con Anthropic Claude Code e OpenAI Codex. La falla è tracciata come CVE-2026-59726, con punteggio CVSS 10.0, e riguarda tutte le versioni precedenti alla 3.16.3.
Ruflo, in precedenza noto come Claude Flow, è pensato per coordinare workflow autonomi, swarm di agenti e sistemi conversazionali. Proprio questa natura lo rende particolarmente sensibile: non si tratta di una semplice applicazione web, ma di un motore che può eseguire strumenti, memorizzare stato e dialogare con servizi esterni tramite chiavi API.
Secondo i ricercatori, il problema nasceva da un bridge MCP (Model Context Protocol) esposto in rete senza autenticazione. In pratica, alcune configurazioni predefinite rendevano raggiungibile dall’esterno un endpoint capace di richiamare strumenti molto potenti, inclusa l’esecuzione di comandi di shell.
Perché la vulnerabilità è così grave
Non tutte le falle critiche hanno lo stesso impatto operativo. In questo caso il rischio è elevatissimo per tre motivi.
Il primo è l’assenza di autenticazione. Se l’istanza era raggiungibile in rete, un attaccante non doveva superare login, MFA o altri controlli: bastava inviare una richiesta HTTP all’endpoint esposto.
Il secondo è il tipo di strumenti accessibili. Le fonti parlano di 233 tool disponibili tramite il bridge MCP, tra cui esecuzione di comandi shell, operazioni su database, gestione degli agenti e accesso alla memoria. Questo trasforma una semplice esposizione di servizio in una compromissione quasi completa dell’ambiente.
Il terzo è la persistenza sull’AI stessa. Oltre al classico furto di credenziali o all’accesso al server, un aggressore poteva alterare il cosiddetto “learning store” o memoria dell’applicazione, influenzando le risposte future del sistema anche dopo la chiusura dell’incidente. È questo l’aspetto più nuovo e, per molte aziende, meno intuitivo.
Come funzionava l’esposizione
La configurazione predefinita del file docker-compose.yml associava la porta 3001 all’indirizzo 0.0.0.0, quindi a tutte le interfacce di rete. In altre parole, il bridge MCP non restava confinato alla macchina locale, ma risultava potenzialmente accessibile dall’esterno. Le fonti segnalano anche l’esposizione di MongoDB sulla porta 27017 nelle impostazioni di default.
Va detto che il livello di esposizione reale dipendeva dall’ambiente: firewall, security group e segmentazione di rete potevano limitare il rischio. Tuttavia, ogni istanza effettivamente raggiungibile via rete risultava sfruttabile senza autenticazione.
Questo è un dettaglio importante anche per le PMI: molte soluzioni AI vengono provate rapidamente in Docker o su server cloud, spesso con configurazioni standard. Se il progetto viene avviato “per test” e poi resta online, può trasformarsi in un punto di ingresso inatteso per un attaccante.
Quali dati e sistemi potevano essere compromessi
Una volta ottenuta l’esecuzione di comandi nel container del bridge, l’attaccante poteva muoversi ben oltre il servizio iniziale. In base a quanto riportato dalle fonti, erano possibili almeno questi impatti:
- lettura delle chiavi API usate da Ruflo per connettersi ai provider LLM;
- accesso alle conversazioni degli utenti archiviate sulla piattaforma;
- alterazione della memoria persistente dell’AI per condizionarne le risposte future;
- creazione di swarm o agenti sotto controllo dell’attaccante usando le chiavi della vittima;
- installazione di una backdoor persistente scrivendo payload malevoli nella directory
/app.
Per un’impresa il danno, quindi, non è solo informatico. Se nei prompt o nelle conversazioni sono presenti dati riservati, procedure interne, documenti sintetizzati o riferimenti a clienti, l’incidente può diventare anche un problema organizzativo e di conformità.
La correzione e le date da ricordare
La segnalazione responsabile è avvenuta il 30 giugno 2026. Il maintainer del progetto, Reuven Cohen, ha distribuito una correzione entro 24 ore. La versione da adottare è la 3.16.3 o successiva.
Le modifiche principali introdotte dal fix includono:
- binding del bridge MCP alla loopback interface per impostazione predefinita;
- controllo server-side più restrittivo sull’uso di
terminal_execute; - attivazione dell’autenticazione MongoDB;
- riduzione della superficie di esposizione delle configurazioni standard.
È una buona notizia che il progetto sia stato corretto rapidamente. Ma il fatto che la patch esista non cancella l’eventuale compromissione già avvenuta prima dell’aggiornamento.
Perché questo caso riguarda anche chi non usa Ruflo
Molte aziende potrebbero pensare: “Non usiamo Ruflo, quindi non ci interessa”. In realtà il caso è emblematico di un problema più ampio.
Le piattaforme AI moderne non sono semplici chatbot. Sempre più spesso hanno accesso a file, terminale, database, CRM, knowledge base e servizi cloud. Quando si combinano agenti autonomi, container, API key e memoria persistente, una configurazione sbagliata può aprire la porta non solo a un server, ma all’intero ecosistema operativo che l’AI tocca.
Inoltre, l’idea di “poisoning” della memoria AI introduce un rischio diverso dal malware classico: il sistema può continuare a funzionare, ma con comportamenti alterati, suggerimenti inaffidabili o istruzioni manipolate. È un incidente più difficile da notare rispetto a un blocco evidente del servizio.
Cosa significa per la tua azienda
Se in azienda usate strumenti AI self-hosted, ambienti di sviluppo con agenti o orchestratori open source, le azioni pratiche da fare sono queste.
1. Verificate subito se avete Ruflo installato o derivati simili.
Controllate server cloud, host Docker, macchine di test e repository interni. Spesso questi strumenti vengono attivati da consulenti, sviluppatori o team innovazione senza passare dall’inventario IT ufficiale.
2. Aggiornate almeno alla versione 3.16.3.
Se trovate Ruflo in uso, l’aggiornamento è il primo passo, ma non l’unico.
3. Chiudete l’esposizione di rete non necessaria.
Le fonti raccomandano di chiudere immediatamente le porte 3001 e 27017 se esposte. In generale, servizi AI, database e bridge interni non dovrebbero essere pubblici su Internet salvo casi eccezionali e con controlli robusti.
4. Considerate compromesse le chiavi API del modello.
Se l’istanza era raggiungibile, è prudente ruotare tutte le credenziali usate verso provider LLM. Questo vale anche per eventuali token di servizi collegati.
5. Verificate conversazioni, memoria e pattern store.
Non limitatevi ai log di sistema. Occorre controllare se ci sono tracce di contenuti iniettati nella memoria dell’AI o nel database dei pattern, perché potrebbero alterare il comportamento del sistema nel tempo.
6. Ricostruite i container da immagini pulite.
Le fonti segnalano la possibilità di persistenza. In questi casi è meglio evitare di “ripulire” semplicemente l’istanza esistente.
7. Portate gli ambienti AI sotto governo IT.
Un assistente che accede a terminale, file o database va trattato come un sistema critico, non come un semplice tool sperimentale. Servono monitoraggio, backup, gestione endpoint e regole di sicurezza coerenti. Se la vostra struttura è cresciuta rapidamente, può essere utile rafforzare sia la sicurezza informatica sia la gestione continuativa delle postazioni e dei server con servizi di desktop IT management.
8. Valutate l’impatto privacy.
Se il sistema contiene conversazioni, dati personali o informazioni di clienti e dipendenti, l’incidente va letto anche in ottica organizzativa e normativa. In questi casi conviene riesaminare ruoli, misure di protezione e trattamenti collegati all’AI, anche con un supporto dedicato alla compliance GDPR.
La lezione più importante: l’AI va amministrata come un’infrastruttura critica
Questa vicenda mostra con chiarezza un punto: quando un sistema AI può eseguire strumenti reali, leggere dati aziendali e memorizzare istruzioni persistenti, non è più un semplice progetto innovativo. È un’infrastruttura critica.
Le configurazioni di default, soprattutto in ambienti open source e containerizzati, non vanno mai date per sicure. E negli scenari AI il problema non è solo “entra o non entra”: conta anche se qualcuno può lasciare istruzioni nascoste che influenzeranno utenti, processi e decisioni in seguito.
Per le PMI italiane il messaggio è pratico: sperimentare va bene, ma con inventario dei sistemi, segmentazione di rete, credenziali separate, backup e responsabilità chiare. È così che si evita che un test promettente diventi un incidente costoso.
Domande frequenti
Se aggiorno Ruflo, il problema è risolto?
Non completamente. L’aggiornamento alla 3.16.3 corregge la vulnerabilità, ma se l’istanza era già esposta bisogna anche ruotare le chiavi API, verificare eventuali manomissioni e ricostruire l’ambiente in modo pulito.
Il rischio esiste solo se il server era visibile da Internet?
Il rischio maggiore riguarda le istanze raggiungibili in rete. Tuttavia anche un’esposizione interna, su reti poco segmentate o ambienti cloud mal configurati, può essere pericolosa.
Anche chi usa altri strumenti AI dovrebbe preoccuparsi?
Sì. Il caso Ruflo evidenzia un rischio generale: agenti AI con accesso a strumenti, database e memoria persistente devono essere gestiti con gli stessi criteri di sicurezza di un’applicazione critica.