Veeam, Terraform MCP e n8n espongono credenziali e accessi aziendali

🛡️ Executive Summary

• Veeam, HashiCorp e Django correggono undici vulnerabilità tra furto di credenziali, isolamento cross-tenant, SSRF e scrittura di file.
• SMOKE#SCREEN usa falsi aggiornamenti Adobe e Zoom per installare agenti ScreenConnect firmati e ottenere accesso remoto persistente.
• GitGuardian trova 321 istanze n8n ancora accessibili con token API pubblicati su GitHub, esponendo workflow e credenziali collegate.

Veeam, HashiCorp e la Django Software Foundation hanno corretto complessivamente undici vulnerabilità che interessano console multi-tenant, server MCP e applicazioni web. Le falle più gravi permettono di impersonare agenti gestiti, riutilizzare token Terraform tra utenti diversi e trasformare lookup geografici in richieste di rete o scrittura di file. Parallelamente, la campagna SMOKE#SCREEN distribuisce ConnectWise ScreenConnect attraverso falsi aggiornamenti Adobe e Zoom, mentre una ricerca di GitGuardian ha individuato 321 istanze n8n ancora raggiungibili con token API esposti nei repository GitHub. I tre casi mostrano come credenziali, strumenti amministrativi e piattaforme di automazione possano amplificare una compromissione iniziale verso intere infrastrutture aziendali.

Veeam espone credenziali degli agenti gestiti

Veeam Service Provider Console è la piattaforma multi-tenant utilizzata da provider e managed service provider per amministrare backup, agenti e infrastrutture appartenenti a più clienti. Il bollettino Veeam dedicato alle vulnerabilità corrette nella versione 9.3 descrive quattro falle che interessano VSPC 9.2.1.33875 e tutte le precedenti build della generazione 9. La più grave, CVE-2026-58073, raggiunge un punteggio CVSS 4.0 di 9,5 e consente a un attaccante non autenticato di impersonare un agente gestito e ottenere le sue credenziali. L’elevata complessità dell’attacco impedisce di considerarla una compromissione immediata, ma l’assenza di autenticazione e il ruolo centrale degli agenti aumentano fortemente l’impatto potenziale. CVE-2026-58072, valutata 9,0, permette invece a un utente con privilegi limitati di scrivere file arbitrari sul server di gestione, creando un percorso verso l’esecuzione remota di codice. Le altre due vulnerabilità consentono di esaurire la memoria dell’host senza autenticazione e di accedere temporaneamente all’API di un’appliance con i privilegi di Portal Administrator dopo l’avvio di una sessione amministrativa. Tutte le falle sono corrette in Veeam Service Provider Console 9.3.0.35057. L’urgenza è rafforzata dai precedenti che hanno già mostrato come le vulnerabilità Veeam possano esporre sistemi di backup e infrastrutture critiche: una console compromessa non contiene soltanto dati, ma relazioni di fiducia e credenziali verso gli ambienti amministrati.

Terraform MCP riutilizza token tra tenant diversi

Il Terraform MCP Server collega assistenti AI e agenti autonomi a Terraform Cloud o Terraform Enterprise, consentendo al modello di consultare organizzazioni, workspace, variabili e risorse tramite il Model Context Protocol. Le tre vulnerabilità corrette da HashiCorp interessano esclusivamente il trasporto Streamable HTTP utilizzato nei deployment centralizzati e multiutente; le installazioni locali che operano soltanto tramite stdio non risultano coinvolte. Nel bollettino HCSEC-2026-23 pubblicato da HashiCorp, CVE-2026-16498 viene descritta come una falla cross-tenant nella modalità HTTP stateless. La libreria MCP sottostante non assegnava identificatori di sessione univoci, mentre il server utilizzava proprio quegli identificatori per distinguere le credenziali dei diversi utenti. Il token Terraform fornito da un tenant poteva quindi essere riutilizzato nelle richieste successive di altri tenant, indipendentemente dalle credenziali presentate. La vulnerabilità ha ricevuto il punteggio massimo CVSS 10,0. La seconda falla, CVE-2026-16496, colpisce la modalità stateful, predefinita nei deployment centralizzati: la cache associava il client Terraform soltanto all’identificativo MCP e non al token originario, permettendo a chi ottenesse un session ID altrui di operare con le autorizzazioni della vittima. CVE-2026-14869 completa il quadro con una server-side request forgery: il middleware bloccava un indirizzo Terraform controllato dal client quando arrivava tramite header HTTP, ma non applicava lo stesso controllo al parametro della query. Un chiamante non autenticato poteva così indurre il server a trasmettere il proprio bearer token verso un endpoint ostile. Le tre falle sono corrette in terraform-mcp-server 1.1.0, mentre l’assenza di una patch richiede di limitare il listener HTTP ai soli utenti fidati. Il rischio si inserisce nella superficie già evidenziata con MCP stateless e i nuovi modelli di esecuzione degli agenti AI, dove un errore nella separazione delle sessioni può trasformare un protocollo di orchestrazione in un ponte tra identità differenti.

Django chiude scrittura di file, SSRF e XSS

Le versioni Django 6.0.8 e 5.2.17 correggono quattro vulnerabilità, la più importante delle quali interessa GeoDjango. CVE-2026-15307 deriva dalla possibilità di passare valori str e dict ai lookup spaziali interpretati da GDALRaster. A seconda del driver utilizzato, un input costruito appositamente può indurre il processo Django a inviare una richiesta verso una risorsa esterna oppure a scrivere un file sul filesystem. Se il file viene collocato in un percorso successivamente importato o elaborato dall’applicazione, la catena può arrivare all’esecuzione di codice. Il percorso documentato attraverso il pannello amministrativo richiede un account staff con permessi di visualizzazione su un modello registrato che contiene un campo spaziale. Nelle note di sicurezza ufficiali di Django 6.0.8 e 5.2.17, il framework specifica che la correzione impedisce l’impiego di dizionari e stringhe che non rappresentano geometrie GEOS valide. Le altre vulnerabilità riguardano un stored XSS nei valori URLField mostrati nell’amministrazione, un denial of service tramite collezioni geometriche profondamente annidate e un consumo eccessivo di memoria nella funzione check_for_language(). Le installazioni supportate devono essere aggiornate immediatamente, mentre i rami non più mantenuti potrebbero condividere parti del codice vulnerabile senza ricevere una correzione ufficiale.

Falsi aggiornamenti installano ScreenConnect firmato

La campagna SMOKE#SCREEN utilizza falsi aggiornamenti di Adobe e Zoom, richieste di revisione di documenti e strumenti di manutenzione per installare silenziosamente un agente ConnectWise ScreenConnect. L’analisi tecnica di Securonix sulla campagna ricostruisce almeno cinque catene di infezione basate su VBScript offuscati, file batch, loader .NET, pagine HTML contraffatte e un server WsgiDAV utilizzato sia per distribuire i payload sia per mantenere l’infrastruttura operativa.

Tutti i percorsi terminano con l’installazione di un pacchetto ScreenConnect legittimo, firmato con un certificato DigiCert valido e configurato per collegarsi a relay controllati dagli attaccanti. L’uso di un normale strumento RMM permette di ottenere desktop remoto, trasferimento di file, esecuzione di comandi e persistenza senza distribuire un RAT personalizzato. I loader più recenti tentano di disattivare AMSI, SmartScreen e Microsoft Defender, rimuovono il marcatore Zone.Identifier e utilizzano un prompt UAC per ottenere privilegi elevati. La distribuzione passa anche attraverso collegamenti Dropbox e Cloudflare Quick Tunnel, servizi che possono superare i controlli basati sulla reputazione dei domini.

Securonix ha individuato inoltre una variante .pkg per macOS, segnalando un’estensione della campagna oltre Windows. La tecnica è coerente con Operation BlueDash, che aveva usato falsi inviti Teams e Zoom per installare più strumenti RMM: il software di controllo remoto non è intrinsecamente malevolo, ma diventa indistinguibile da una backdoor quando viene distribuito senza consenso e collegato all’infrastruttura dell’attaccante.

I token n8n esposti aprono workflow e credenziali cloud

GitGuardian ha analizzato token n8n pubblicati accidentalmente nei commit GitHub a partire dall’aprile 2025, individuando 4.576 credenziali uniche associate a 1.255 hostname. Tra le 896 istanze ancora raggiungibili durante i test, 321 accettavano almeno uno dei token pubblicati, pari al 36% dei sistemi accessibili. La ricerca di GitGuardian sull’esposizione delle chiavi API n8n mostra che un token sufficientemente privilegiato può leggere le definizioni complete dei workflow, consultare dati di esecuzione, enumerare utenti e credenziali e creare nuove automazioni. L’attaccante non deve necessariamente decifrare direttamente i segreti: può costruire un workflow che utilizza le credenziali memorizzate e invia il risultato verso un endpoint sotto il suo controllo. Le configurazioni vulnerabili possono ampliare ulteriormente la catena.

Con CVE-2026-25053, un utente capace di creare o modificare workflow può abusare del nodo Git per leggere file accessibili al processo n8n, compresi la configurazione contenente N8N_ENCRYPTION_KEY e il database con le credenziali cifrate. La combinazione permette la decifratura offline dei segreti collegati a database, repository, servizi cloud, piattaforme AI e applicazioni SaaS. GitGuardian ha inoltre trovato 372 token MCP, sette dei quali ancora validi, e 129 istanze pubbliche configurate con chiavi di cifratura deboli già comparse su GitHub. La ricerca conferma quanto emerso con le falle RCE che hanno colpito i server n8n self-hosted: una piattaforma di automazione deve essere trattata contemporaneamente come ambiente di esecuzione, archivio di credenziali e nodo di accesso verso tutti i servizi integrati.

La bonifica richiede la rotazione dei segreti

Gli aggiornamenti chiudono le vulnerabilità software, ma non eliminano automaticamente credenziali già sottratte, agenti RMM installati o workflow creati dagli attaccanti. Le organizzazioni che utilizzano Veeam Service Provider Console devono installare la build 9.3.0.35057 e controllare agenti registrati, account, connessioni e attività amministrative anomale. I deployment Terraform MCP devono essere portati almeno alla versione 1.1.0, verificando la modalità di trasporto e ruotando i token che potrebbero essere passati attraverso cache condivise o endpoint manipolati. Django richiede l’aggiornamento alle versioni 6.0.8 o 5.2.17 e la revisione degli account staff autorizzati a interrogare modelli GeoDjango. Per SMOKE#SCREEN occorre cercare installazioni ScreenConnect non approvate, relay sconosciuti, modifiche alle difese Windows e connessioni verso infrastrutture Cloudflare temporanee. Nel caso n8n, la revoca del solo token esposto rappresenta il punto di partenza: devono essere controllati workflow, utenti, esecuzioni, nodi aggiunti e credenziali downstream, ruotando ogni segreto che l’account compromesso poteva utilizzare. La superficie comune non è una specifica CVE, ma la concentrazione di fiducia in console, agenti e piattaforme capaci di agire su numerosi sistemi con un’unica identità.