Una campagna di scansione su larga scala sta prendendo di mira i server di sviluppo Vite esposti su Internet per leggere file sensibili e sottrarre credenziali cloud. Il problema riguarda ambienti che spesso vengono considerati “temporanei” o “solo per sviluppo”, ma che possono contenere segreti reali: file .env, configurazioni AWS e Azure, password di database e perfino file di stato dell’infrastruttura.

Per un’azienda il rischio è concreto: un server dev pubblicato per comodità, una porta Docker aperta o una configurazione frettolosa possono trasformarsi in un accesso indiretto agli account cloud e ai sistemi interni. Non è quindi una notizia che riguarda solo gli sviluppatori: riguarda continuità operativa, dati aziendali e responsabilità organizzative.

Che cosa è successo

Il 15 settembre 2026 The Hacker News ha riportato i risultati di un’analisi di F5 Labs su una campagna automatizzata osservata ad agosto 2026. L’obiettivo degli attaccanti sono i deployment di Vite, il noto strumento usato nello sviluppo di applicazioni web moderne, quando il server di sviluppo è raggiungibile dalla rete o direttamente da Internet.

Secondo i ricercatori, l’attività malevola sfrutta la vulnerabilità CVE-2026-39364, classificata con punteggio CVSS 8.2. Il difetto consente a un attaccante non autenticato di aggirare alcune restrizioni del server tramite la manipolazione dei parametri della query e ottenere in chiaro il contenuto di file che dovrebbero essere bloccati.

In pratica, l’attacco usa richieste HTTP verso l’endpoint /@fs/, indicando il percorso di file sensibili e aggiungendo parametri come ?raw, ?import raw o ?import url inline. In queste condizioni, il controllo che dovrebbe negare l’accesso a determinati file può essere bypassato e il server restituisce il contenuto con risposta HTTP 200.

Perché il difetto è pericoloso davvero

Il punto critico non è solo la vulnerabilità in sé, ma il tipo di dati che può esporre. Nei server di sviluppo finiscono spesso informazioni che in produzione verrebbero gestite con più attenzione: variabili d’ambiente, certificati, token, configurazioni di servizi esterni, credenziali per database o per i provider cloud.

F5 Labs ha osservato tentativi di raccolta mirata dei seguenti elementi:

configurazioni di ambiente;
credenziali AWS;
configurazioni e backup AWS;
file di stato dell’infrastruttura come terraform.tfstate e serverless.yml;
profili Azure;
dettagli di sistema e di ambiente come /etc/passwd, /proc/self/environ, /proc/1/environ e /proc/self/cwd/.env.

Quest’ultimo esempio è particolarmente significativo: leggere /proc/self/cwd/.env permette di puntare al file .env attivo del processo in esecuzione senza dover indovinare il percorso completo dell’applicazione. È un segnale di attaccanti che conoscono bene come sono costruiti gli ambienti di sviluppo moderni.

Se un file .env contiene chiavi API, password, stringhe di connessione o credenziali di amministrazione cloud, il passo successivo non è solo il furto del dato: può diventare accesso agli account, modifica di configurazioni, cancellazione di risorse, esfiltrazione di dati o distribuzione di malware.

Quando un server Vite è realmente esposto

Non tutte le installazioni sono automaticamente vulnerabili allo stesso modo. Dalle indicazioni pubblicate emerge che l’impatto richiede alcune condizioni precise.

Un’app risulta esposta se:

il server di sviluppo Vite viene reso accessibile in rete tramite --host o l’opzione server.host;
il file sensibile si trova in directory consentite da server.fs.allow;
il file è bloccato da un pattern di server.fs.deny, ma il controllo può essere aggirato con i parametri sopra descritti.

In configurazione predefinita, Vite si lega a localhost. Questo significa che il rischio aumenta quando un team modifica intenzionalmente il comportamento per permettere accesso da altre macchine, da container, da ambienti condivisi o da un indirizzo pubblico.

I casi più comuni, in azienda, sono meno “eccezionali” di quanto sembri:

un developer espone temporaneamente il servizio per fare una demo;
un container Docker pubblica una porta oltre il necessario;
un ambiente di test viene lasciato online dopo la fine del progetto;
un reverse proxy o una regola firewall consente accessi non previsti.

È proprio questa area grigia tra sviluppo, test e operatività a creare i problemi più seri.

Come si muovono gli attaccanti

La campagna descritta non sembra puntare a una singola azienda, ma a una raccolta massiva di bersagli esposti. In altre parole, non serve essere un’organizzazione “famosa” per finire nel mirino: basta avere un server raggiungibile e mal configurato.

Le richieste osservate usavano user-agent falsi che imitavano crawler noti e bot di intelligenza artificiale, tra cui Googlebot, ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot e Amazonbot. Inoltre includevano intestazioni X-Forwarded-For e X-Real-IP contraffatte, nel tentativo di aggirare liste di controllo basate su IP e rendere più difficile l’analisi dei log.

Una quota significativa del traffico malevolo, secondo quanto riportato, proveniva da indirizzi associati a Stati Uniti, Belgio, Paesi Bassi, Singapore e Taiwan, con uso di range Google Cloud Platform della serie 34.x e 35.x. Anche questo è un dettaglio importante per le aziende: filtrare “il cloud” o fidarsi automaticamente di traffico proveniente da grandi provider non è una strategia sufficiente.

Perché una PMI dovrebbe preoccuparsi

Molte piccole e medie imprese pensano che il proprio rischio cyber riguardi soprattutto PC, email o ransomware. In realtà, una parte crescente dell’esposizione nasce da strumenti di sviluppo, integrazioni cloud e ambienti ibridi gestiti in modo informale.

Se la vostra azienda si appoggia a software house, freelance, team interni o fornitori che sviluppano applicazioni web, questo tema vi riguarda anche se non sapete cosa sia Vite. Il punto è semplice: un ambiente dev con dati o credenziali reali può diventare una scorciatoia per entrare nei sistemi aziendali.

Ecco le conseguenze più probabili:

compromissione di account AWS o Azure;
accesso a database o archivi cloud;
furto di segreti applicativi e token API;
esposizione di configurazioni infrastrutturali utili per attacchi successivi;
interruzioni operative dovute a bonifiche urgenti e rotazione credenziali.

Quando il problema tocca servizi cloud, l’impatto non resta confinato al reparto IT: può coinvolgere siti web, applicazioni gestionali, portali clienti, integrazioni con fornitori e adempimenti privacy.

Cosa significa per la tua azienda

La prima azione pratica è verificare se esistono server di sviluppo Vite esposti in rete, soprattutto su sistemi temporanei, container e ambienti di test. Non basta chiedere “abbiamo Vite?”: bisogna controllare dove gira, come è pubblicato e se contiene segreti reali.

In concreto, per una PMI italiana è sensato procedere così:

Censire gli ambienti di sviluppo e test
Chiedi al tuo fornitore software o al team interno quali strumenti sono pubblicati verso la rete e con quali porte. Gli ambienti dev non devono essere raggiungibili da Internet se non in casi eccezionali e controllati.
Verificare configurazioni e aggiornamenti
Se Vite è in uso, è opportuno controllare immediatamente la versione e applicare le correzioni disponibili, oltre a rivedere le impostazioni server.host, server.fs.allow e l’esposizione tramite proxy o Docker.
Rimuovere i segreti dagli ambienti non necessari
File .env, credenziali cloud, certificati e backup non dovrebbero stare in server di sviluppo accessibili. Dove possibile, usare credenziali dedicate, a privilegi minimi e separate dalla produzione.
Ruotare le credenziali sospette
Se un server era esposto, non conviene limitarsi a “chiuderlo”: è prudente sostituire chiavi API, password, token e credenziali cloud potenzialmente transitati nei file accessibili.
Analizzare i log con criterio
Cercate richieste all’endpoint /@fs/, accessi con query anomale come ?raw, user-agent che imitano bot famosi e header X-Forwarded-For sospetti. Un controllo centralizzato dei log aiuta a capire se il sistema è stato solo esposto o anche interrogato.
Separare sviluppo e produzione
La regola organizzativa più importante è evitare che dati reali e credenziali di produzione finiscano in ambienti usati per test rapidi o debug.
Preparare backup e risposta all’incidente
Se un account cloud viene compromesso, poter ripristinare configurazioni e dati diventa essenziale. Per questo sono utili procedure strutturate di remote backup e un presidio continuativo di sicurezza informatica.

Per molte imprese il vero problema non è la singola CVE, ma l’assenza di governo sugli ambienti “di contorno”. Un servizio di assistenza informatica continuativa può aiutare a mettere sotto controllo proprio queste aree spesso trascurate.

Un promemoria utile: sviluppo non significa “senza rischio”

C’è un errore molto comune nelle aziende: considerare gli strumenti di sviluppo come qualcosa di tecnico, interno e quindi poco rilevante per il business. La realtà è opposta. Oggi sviluppo, cloud e operatività sono strettamente collegati; ciò che è configurato male in un ambiente dev può aprire la strada verso dati, servizi e processi essenziali.

Questa campagna lo dimostra bene. Gli attaccanti non stanno cercando solo un bug da sfruttare: stanno cercando scorciatoie verso le credenziali. E le credenziali, nel cloud, valgono spesso più del server stesso.

Domande frequenti

Se usiamo Vite solo per sviluppo interno, siamo al sicuro?

Non automaticamente. Il rischio diminuisce se il server resta su localhost e non è esposto in rete, ma va comunque verificato che non ci siano pubblicazioni involontarie tramite Docker, proxy, VPN o configurazioni temporanee.

Dobbiamo preoccuparci anche se il sito pubblico non usa Vite?

Sì. Il problema riguarda i server di sviluppo Vite, non necessariamente il sito di produzione. Un ambiente dev compromesso può comunque esporre credenziali utili per altri sistemi aziendali.

Chi dovrebbe intervenire: sviluppatore, fornitore o IT interno?

Tutti e tre, ciascuno per la propria parte. Lo sviluppatore verifica la configurazione dell’applicazione, il fornitore aggiorna e corregge l’ambiente, l’IT controlla esposizione di rete, log, credenziali e misure di contenimento.

Vite esposto online: rischio furto credenziali cloud