Vite sotto scansione: CVE-2026-39364 espone chiavi AWS, Azure e segreti Terraform

🛡️ Executive Summary

• CVE-2026-39364 consente di aggirare server.fs.deny e leggere file riservati da server Vite di sviluppo esposti in rete senza autenticazione.
• F5 registra 807 attacchi e circa 32mila eventi diretti contro .env, credenziali AWS, token Azure, Terraform state e variabili di processo.
• Occorre aggiornare Vite, eliminare l’esposizione pubblica dei dev server e ruotare i segreti se un’istanza vulnerabile era raggiungibile da Internet.

I server di sviluppo Vite lasciati raggiungibili da Internet sono diventati bersagli di una campagna automatizzata costruita non per compromettere direttamente l’applicazione, ma per arrivare alle identità cloud che la circondano. La telemetria di F5 ha registrato 807 sessioni di attacco e circa 32.000 eventi durante agosto 2026, con scanner che sfruttano soprattutto CVE-2026-39364 per leggere file normalmente protetti da server.fs.deny. Gli obiettivi mostrano chiaramente la posta in gioco: file .env, credenziali AWS, token Microsoft Azure, stati Terraform, configurazioni Serverless e variabili dei processi Linux. Il server di sviluppo diventa così un ponte verso infrastrutture cloud potenzialmente molto più preziose dell’applicazione frontend esposta.

CVE-2026-39364 trasforma una query HTTP nella lettura dei file riservati

La vulnerabilità CVE-2026-39364, classificata High, interessa il development server di Vite e permette a un aggressore remoto non autenticato di aggirare le regole utilizzate per impedire la lettura di file sensibili. Secondo l’advisory ufficiale pubblicato nel repository Vite, il problema nasce nella gestione di query come ?raw, ?import&raw o ?import&url&inline: aggiungendo questi parametri alla richiesta, file che dovrebbero essere bloccati da server.fs.deny possono essere restituiti con risposta HTTP 200. L’exploitation richiede però una condizione precisa: il development server deve essere stato esposto alla rete, per esempio attraverso --host, l’opzione server.host o una configurazione Docker che pubblica verso l’esterno la porta del servizio.

Le versioni coinvolte comprendono Vite 7.1.0 fino alla 7.3.1 e Vite 8.0.0 fino alla 8.0.4; le release 7.3.2 e 8.0.5 correggono il problema. Questa precisazione è importante perché alcune riprese giornalistiche includono erroneamente la 7.3.2 tra le versioni vulnerabili, mentre l’advisory ufficiale la identifica come versione corretta. Il rischio non dipende quindi da Vite in quanto tale, che di default resta legato a localhost, ma dalla combinazione tra versione vulnerabile e sviluppo reso raggiungibile da reti non fidate.

Gli scanner cercano direttamente AWS, Azure e Terraform

La parte più significativa emerge dalla telemetria pubblicata da F5 Labs. Gli attaccanti non si limitano a verificare l’esistenza di un .env, ma utilizzano wordlist costruite intorno ai percorsi tipici degli ambienti cloud e DevOps. Le richieste cercano file come .env.production, .env.local e .env.staging, ma anche ~/.aws/credentials, backup delle configurazioni AWS, cache SSO, rootkey.csv, aws-exports.js, profili Azure e accessTokens.json. Il secondo blocco di obiettivi riguarda direttamente l’Infrastructure as Code: terraform.tfstate, terraform.tfvars, .terraform/terraform.tfstate, serverless.yml e lo stato interno di Serverless Framework.

In un ambiente reale questi file possono contenere endpoint, identificativi di risorse, password, token o valori utilizzati per costruire l’intera infrastruttura. Gli scanner interrogano inoltre /proc/self/environ, /proc/1/environ e /proc/self/cwd/.env, dimostrando di conoscere la struttura tipica dei deployment containerizzati. Quest’ultimo percorso è particolarmente efficace perché consente di raggiungere il .env relativo al processo Vite senza dover indovinare il percorso assoluto dell’applicazione. Il pattern ricorda quanto già osservato nella compromissione delle pipeline GitHub Actions utilizzate per sottrarre token Git, chiavi AWS e credenziali di servizi esterni: l’applicazione iniziale è soltanto il primo gradino verso identità tecniche riutilizzabili altrove.

Leggi anche: Megalodon mostrava già come token OIDC, credenziali AWS e metadati cloud possano trasformare una compromissione DevOps in accesso all’infrastruttura

Il vero bersaglio non è Vite ma il trust assegnato alla workstation dello sviluppatore

La campagna evidenzia un problema ricorrente nella sicurezza degli ambienti di sviluppo: la macchina o il container che esegue il dev server possiede spesso più privilegi di quelli richiesti dall’applicazione frontend. Uno sviluppatore può avere una sessione AWS aperta, credenziali Azure memorizzate, token GitHub, accessi ai registry container, file Terraform e chiavi API disponibili attraverso variabili d’ambiente. Se Vite viene esposto pubblicamente dalla stessa macchina, una vulnerabilità di sola lettura può assumere un valore molto superiore al proprio impatto apparente. L’attaccante non deve necessariamente ottenere remote code execution sul server: una chiave AWS valida può consentire accesso a bucket, funzioni Lambda, database o account IAM; un token Azure può aprire risorse cloud; uno state file Terraform può ricostruire l’architettura interna e contenere segreti in chiaro. È la stessa dinamica osservata nel caso Amazon Q Developer, dove la fiducia concessa a un workspace poteva esporre credenziali cloud ereditate dall’ambiente dello sviluppatore. La superficie di attacco moderna non coincide quindi più con il singolo servizio vulnerabile: comprende tutto ciò che quel processo può leggere dalla macchina e tutto ciò che quelle credenziali consentono successivamente di raggiungere.

Gli attaccanti provano più falle Vite e tecniche per superare proxy e WAF

F5 ha osservato che la campagna non utilizza esclusivamente CVE-2026-39364. Gli stessi cluster di scanning provano anche CVE-2025-30208, CVE-2025-31125 e CVE-2024-45811, tutte vulnerabilità legate a differenti modalità di bypass dei controlli sui file in Vite. CVE-2025-31125 compare inoltre nel catalogo Known Exploited Vulnerabilities di CISA, elemento che conferma una storia di sfruttamento reale dei meccanismi di file access del framework. Le richieste osservate utilizzano percorsi con traversal e sequenze codificate due volte, come %252f, probabilmente per superare normalizzazioni effettuate da reverse proxy o Web Application Firewall prima che la richiesta raggiunga Vite. Gli operatori falsificano inoltre header User-Agent facendosi passare per Googlebot, ClaudeBot, GPTBot, PerplexityBot, OAI-SearchBot e Amazonbot, insieme a valori X-Forwarded-For e X-Real-IP contraffatti. La tecnica non rende il traffico realmente proveniente dai crawler ufficiali, ma può sfruttare configurazioni ingenue nelle quali bot apparentemente legittimi ricevono eccezioni dai controlli perimetrali. Una parte consistente del traffico osservato proviene inoltre da indirizzi appartenenti a Google Cloud, un’ulteriore dimostrazione del fatto che l’origine geografica o l’ASN non rappresentano da soli indicatori affidabili di legittimità.

Da 1.732 a oltre 32mila eventi in un mese: l’exploit entra nell’automazione di massa

Il salto quantitativo registrato da F5 mostra quanto rapidamente una vulnerabilità semplice possa essere incorporata negli scanner automatici. Nei tre mesi precedenti agosto la telemetria aveva registrato 1.732 eventi Vite correlati, mentre nel solo agosto il volume è salito sopra quota 32.000. Non significa che siano state compromesse 32mila organizzazioni: F5 distingue infatti tra eventi grezzi e sessioni di attacco raggruppate, pari a 807. Il dato importante è la velocità con cui il credential harvesting si industrializza una volta disponibile una tecnica affidabile e facilmente automatizzabile. La richiesta non richiede autenticazione, exploit binari o interazione umana: basta individuare un dev server raggiungibile, provare una serie di percorsi e verificare se il contenuto viene restituito. Questa economia dell’attacco spiega perché gli ambienti degli sviluppatori siano diventati bersagli sempre più frequenti. Contagious Interview utilizza repository di lavoro apparentemente legittimi per raggiungere chiavi cloud e token sulle workstation; la campagna Vite percorre il cammino opposto, trovando direttamente su Internet gli strumenti di sviluppo che l’organizzazione ha involontariamente reso accessibili.

Aggiornare Vite non basta se il dev server continua a essere pubblicato su Internet

La correzione immediata consiste nell’aggiornare Vite alle release corrette, ma ridurre il problema a una patch lascerebbe intatta la causa architetturale. I development server non dovrebbero essere esposti direttamente a Internet. Vanno quindi controllati --host, server.host, mapping delle porte Docker, security group cloud, ingress Kubernetes e configurazioni dei reverse proxy. La documentazione Vite avverte inoltre che impostare server.allowedHosts su true consente a qualunque hostname di raggiungere il server e può aprire la strada ad attacchi di DNS rebinding; è preferibile definire esplicitamente gli host autorizzati. F5 raccomanda anche di bloccare accessi pubblici alla porta 5173, monitorare le richieste verso /@fs/ e non usare il semplice User-Agent per stabilire se un crawler sia attendibile. Ma l’intervento più importante riguarda le credenziali: se un server Vite vulnerabile è stato raggiungibile dall’esterno, patcharlo non invalida eventuali chiavi già sottratte. Devono essere ruotati i segreti accessibili dal processo, incluse credenziali AWS, token Azure, password presenti negli .env, token API e valori memorizzati nei file Terraform. La necessità è la stessa emersa dopo la compromissione di JetBrains Cadence, dove la correzione del server non eliminava il rischio rappresentato dalle credenziali cloud già esposte.

Continua con:

• Shai-Hulud mostra come il furto di token AWS, Azure, Kubernetes e GitHub possa propagare una compromissione lungo l’intera supply chain
• IronWorm cerca decine di credenziali cloud e AI direttamente nelle workstation degli sviluppatori

I server di sviluppo sono diventati depositi di identità cloud

La campagna contro Vite mostra perché un servizio apparentemente secondario può diventare un rischio cloud di primo livello. CVE-2026-39364 non concede direttamente controllo amministrativo su AWS o Azure: consente di leggere file. Ma negli ambienti moderni quei file spesso contengono esattamente ciò che serve per oltrepassare il server vulnerabile. Un .env può avere una password database, terraform.tfstate può contenere segreti e struttura dell’infrastruttura, .aws/credentials può fornire accesso API e /proc/self/environ può esporre token caricati al momento dell’avvio del processo. Il vero confine di sicurezza non è quindi la porta 5173, ma l’insieme delle identità che il processo Vite eredita dal proprio ambiente. La lezione per i team DevOps è più ampia della singola CVE: development, staging e preview non devono essere considerati sistemi sacrificabili perché non contengono dati di produzione. Possono custodire le chiavi che conducono direttamente alla produzione. In questo scenario un dev server dimenticato su Internet non è soltanto una configurazione sbagliata: può diventare un secret store involontario accessibile con una singola richiesta HTTP.