Iscriviti per una mail al mese con le mie note dal campo.
Uso la tua email solo per la newsletter. Vedi Privacy e Cookie.
Lo Strumento AI Che Ha Bucato Vercel
Come uno script cheat per Roblox ha innescato una reazione a catena terminata dentro una delle infrastrutture developer più critiche del web. E cosa rivela sull'architettura nascosta di fiducia che regge l'ecosistema software moderno.
C'è un dettaglio sepolto nel breach di Vercel che la maggior parte dei commenti ha mancato: l'attacco che ha compromesso l'infrastruttura di cui si fidano milioni di sviluppatori non è iniziato con un hacker. È iniziato con un cheat per un videogioco.
Da qualche parte nel febbraio 2026, un dipendente di una piccola azienda AI chiamata Context AI ha scaricato uno script "auto-farm" per Roblox su quello che era probabilmente il suo laptop di lavoro. Lo script è partito. Un malware chiamato Lumma Stealer ha eseguito silenziosamente in background, ha raccolto tutto quello che poteva trovare sulla macchina, e ha caricato i risultati su un server command-and-control. Il dipendente probabilmente non ha notato nulla.
Dieci settimane dopo, quella singola infezione aveva attraversato un confine OAuth, impersonato l'account Google Workspace di un dipendente Vercel, ed era atterrata nei sistemi interni di Vercel — esponendo variabili d'ambiente, token npm, token GitHub, e secondo BreachForums, codice sorgente parziale e 580 record di dipendenti.
Vercel ha confermato il breach il 19 aprile 2026. Il bollettino è ancora in aggiornamento mentre scrivo. La portata completa è ancora in corso di determinazione.
Questo articolo è il mio tentativo di spiegare esattamente cosa è successo — tecnicamente, strato per strato — e cosa rivela sul modo in cui l'ecosistema developer pensa (o non pensa) alla fiducia.
Perché Vercel Vale la Pena di Capire
Contesto rapido prima di andare in profondità.
Vercel non è solo un hosting provider. È infrastruttura per una frazione significativa del web moderno: piattaforma di deployment per applicazioni costruite da milioni di sviluppatori, manutentore principale di Next.js (uno dei framework JavaScript più scaricati al mondo), e custode fidata dei segreti di produzione per un gran numero di aziende tra cui, notoriamente, OpenAI, Cursor, Pinterest e Bose.
Quando usi Vercel, gli stai consegnando le credenziali del database, le chiavi API, i segreti di firma, i token webhook — tutto ciò che fa funzionare la tua applicazione in produzione. I pacchetti npm che Vercel mantiene vengono spediti a centinaia di milioni di installazioni a settimana. Se quei pacchetti fossero stati compromessi, il danno a cascata sarebbe stato enorme.
La buona notizia: Vercel ha confermato che la supply chain npm è pulita, validata in collaborazione con GitHub, Microsoft, npm e Socket. Nessuna manomissione a Next.js, Turbopack o qualsiasi altro pacchetto mantenuto da Vercel.
La cattiva notizia: tutto il resto di questa storia è una lezione su come funziona la fiducia — e su come può fallire catastroficamente — in un ecosistema software costruito su catene di integrazioni di terze parti.
Capire gli Attacchi alla Supply Chain
Prima di ripercorrere quello che è successo, è utile capire la categoria di attacco.
Un attacco alla supply chain non prende di mira la vittima direttamente. Prende di mira qualcosa di cui la vittima si fida. La logica è elementare: le grandi aziende investono molto nella difesa del proprio perimetro. Hanno team di sicurezza, rilevamento delle intrusioni, monitoraggio, infrastrutture blindate. Attaccarle frontalmente è costoso e spesso fallisce.
Ma ogni azienda si fida anche di vendor, strumenti, servizi e integrazioni di terze parti. Quelle terze parti hanno i propri perimetri — spesso molto meno difesi. Se riesci a compromettere una terza parte fidata, erediti qualsiasi accesso che quella terza parte è stata concessa dai suoi clienti. Non devi sfondare il muro se hai la chiave di una porta laterale.
Il breach di Vercel è un'illustrazione da manuale — ma con un twist moderno. La supply chain non è un sistema di build software. È un'integrazione OAuth tra strumenti di produttività AI. E la chiave della porta laterale era un token, non una password.
Atto I — Lumma Stealer, Spiegato
Per capire come uno script Roblox ha avviato tutto questo, devi capire cosa è realmente Lumma Stealer.
Il Modello di Business del Malware
Lumma Stealer (noto anche come LummaC2) non è scritto da un hacker solitario in uno scantinato. È un prodotto commerciale. Un'operazione Malware-as-a-Service (MaaS), sviluppata e mantenuta da un attore di minaccia di lingua russa che va sotto lo pseudonimo "Shamel" — tracciato dalla divisione Microsoft Threat Intelligence con la designazione Storm-2477.
Lumma era venduto attraverso livelli di abbonamento da $250 a $1.000 al mese, con accesso al codice sorgente offerto a $20.000. I livelli inferiori includono filtro base dei log e opzioni di download. I livelli superiori aggiungono configurazioni personalizzate di raccolta dati, tecniche di evasione avanzate e accesso anticipato alle nuove funzionalità. Il livello più alto — accesso al codice sorgente — permette ai clienti di costruire il proprio derivato e rivenderlo.
In un'intervista con il ricercatore di cybersicurezza "g0njxa" nel novembre 2023, Shamel ha condiviso di avere "circa 400 clienti attivi." Ha creato un brand Lumma, usando un logo distintivo di un uccello per commercializzare il suo prodotto, chiamandolo simbolo di "pace, leggerezza e tranquillità", e aggiungendo lo slogan "fare soldi con noi è altrettanto facile."
Questo è un business. Con clienti, livelli di supporto, marketing e un changelog. La barriera all'uso è deliberatamente minima — l'obiettivo è il volume, non la sofisticazione.
Cosa Fa Lumma sulla Tua Macchina
Quando Lumma esegue su una macchina Windows, la prima cosa che fa è fare il fingerprinting dell'ambiente: versione OS, hardware ID, CPU, RAM, risoluzione dello schermo, lingua del sistema. Non è curiosità — è filtraggio. Il malware controlla se sta girando dentro una sandbox o un ambiente di analisi. Se rileva una sandbox, esce senza fare nulla. Questa evasione è integrata nel core.
Assumendo che la macchina sia reale, esegue le sue routine di raccolta. Ecco cosa raccoglie effettivamente:
Dai browser (Chrome, Edge, Firefox, Brave, Opera e altri):
I dati core del browser vivono in poche posizioni chiave. Chrome memorizza le password in un database SQLite chiamato Login Data e i cookie in un altro database SQLite chiamato Cookies. I valori sono cifrati — ma ecco il problema.
Storicamente, Chrome usava Windows DPAPI (Data Protection API) per cifrare questi dati. DPAPI cifra i dati usando una chiave derivata dalle credenziali di login Windows dell'utente. La protezione che fornisce è tra utenti — non tra processi. Qualsiasi processo che gira come l'utente Windows attualmente loggato può chiamare CryptUnprotectData() e decifrare i dati. Questo significa che Lumma, girando come l'utente corrente, può decifrare banalmente l'intero store di password e cookie di Chrome.
Google ha introdotto App-Bound Encryption in Chrome 127 (luglio 2024) specificamente per affrontare questo. Il nuovo sistema instrada la decifratura attraverso un servizio Windows privilegiato che gira come SYSTEM, che verifica che il processo richiedente sia effettivamente Chrome prima di restituire la chiave.
App-Bound Encryption è stata rilasciata il 30 luglio 2024 e i ricercatori di sicurezza hanno osservato prove di capacità di bypass già il 12 settembre 2024, meno di 45 giorni dopo.
Oltre ai browser:
Lumma Stealer cerca anche wallet di criptovalute, file di configurazione VPN, client email, client FTP, dati di sessione Telegram, chiavi SSH, file .env e altri file di configurazione developer, dati dei password manager, e documenti utente inclusi PDF e file Word.
L'output di un'infezione Lumma è un archivio strutturato — chiamato "log" nell'ecosistema infostealer — caricato in tempo reale sull'infrastruttura C2 dell'attaccante.
La Disruzione e il Ritorno
Tra il 16 marzo e il 16 maggio 2025, Microsoft ha identificato oltre 394.000 computer Windows globalmente infetti da Lumma. Lavorando con le forze dell'ordine e partner del settore — tra cui Europol, FBI, ESET, BitSight, Cloudflare e altri — l'Unità Crimini Digitali di Microsoft ha presentato azione civile e sequestrato circa 2.300 domini dannosi che formavano la spina dorsale dell'infrastruttura di Lumma.
La disruzione fu significativa. Ma non ha ucciso l'operazione.
L'attività ha iniziato a recuperare entro settimane, e verso la fine del 2025 e l'inizio del 2026, le campagne stavano di nuovo aumentando globalmente. La macchina del dipendente di Context AI è stata infettata nel febbraio 2026 — circa nove mesi dopo la grande operazione di abbattimento. Lumma si era ricostruita.
Questa è la natura del MaaS: l'infrastruttura può essere sequestrata, ma lo sviluppatore, il codice e la base di affiliati rimangono.
Atto II — Il Ponte OAuth
L'infezione Lumma ha dato all'attaccante un dump di credenziali dalla macchina del dipendente di Context AI. Tra i dati raccolti c'erano le credenziali Google Workspace per l'account di lavoro del dipendente, le credenziali per support@context.ai — identificato dall'analisi di Hudson Rock come account del team core — e chiavi API per Supabase, Datadog e Authkit.
OAuth: Il Protocollo Che Ha Sostituito le Password (E Creato Nuovi Problemi)
OAuth è stato progettato per risolvere un problema reale: come permettere all'Applicazione B di accedere ai tuoi dati memorizzati nel Servizio A senza dare all'Applicazione B la tua password del Servizio A?
Il flusso OAuth 2.0 emette due token dopo l'autorizzazione iniziale:
Un access token: di breve durata (tipicamente 60 minuti), usato direttamente nelle chiamate API
Un refresh token: di lunga durata, usato per ottenere nuovi access token senza dover richiedere nuovamente all'utente
Perché i Refresh Token Sono la Vera Superficie di Attacco
I refresh token sono credenziali bearer — chiunque possieda il token può usarlo senza ulteriore verifica dell'identità. Dopo che il flusso iniziale di consenso OAuth si completa con MFA, il refresh token risultante abilita l'accesso continuo senza ri-autenticazione.
"Credenziale bearer" significa esattamente quello che sembra: il possesso equivale all'autorizzazione. Non c'è secondo fattore, nessun binding al dispositivo, nessuna verifica IP. Se hai il token, sei la parte autorizzata agli occhi del resource server.
Questo ha un'implicazione critica: MFA non protegge contro il furto di refresh token. L'MFA è avvenuta quando l'utente ha originalmente autorizzato l'app. Il token risultante rappresenta quella passata autorizzazione. Un attaccante che ruba il token non ha bisogno di ri-autenticarsi, perché l'autenticazione è già avvenuta — e la prova di essa è il token stesso.
La maggior parte delle app SaaS non invalida automaticamente i refresh token esistenti quando le password vengono resettate o le impostazioni MFA cambiano. Gli attaccanti che hanno rubato refresh token mantengono l'accesso finché quei token specifici non vengono esplicitamente revocati, anche dopo le azioni standard di incident response.
La Posizione OAuth di Context AI
Context AI è una AI Office Suite — si connette al tuo Google Workspace, legge i tuoi documenti, email e calendario, e fornisce assistenza basata su AI. Per fare questo, memorizza refresh token per ogni utente che la autorizza. Quei token vivono sui server di Context AI.
L'attaccante, ora in possesso delle credenziali per l'account support@context.ai, ha acceduto ai sistemi di Context AI. All'interno di quei sistemi c'erano refresh token per ogni account Google Workspace connesso.
Vercel non è un cliente Context, ma sembra che almeno un dipendente Vercel si sia iscritto all'AI Office Suite usando il proprio account enterprise Vercel e abbia concesso i permessi "Allow All". La frase critica: "Allow All." Questo è lo scope massimo — un token OAuth con questo livello di permessi dà al possessore accesso essenzialmente completo all'account Google connesso.
L'attaccante ha trovato questo token nel database di Context AI. Lo ha usato. I sistemi di Google hanno visto un refresh token valido, legittimamente emesso. Nessun allarme è scattato.
Atto III — Dentro Vercel
Dall'account Google Workspace del dipendente Vercel, l'attaccante aveva un punto d'appoggio nell'infrastruttura Google aziendale. A seconda di come era configurato il single sign-on, questo poteva estendersi a qualsiasi strumento interno che si autenticava via Google.
Vercel ha valutato l'attaccante come altamente sofisticato basandosi sulla sua velocità operativa e sulla dettagliata comprensione dei sistemi Vercel. Si sono mossi rapidamente e con precisione. Sapevano cosa cercare.
Quello che hanno trovato: variabili d'ambiente.
Il Problema Sensitive vs. Non-Sensitive
Vercel fornisce due modalità di storage per le variabili d'ambiente:
Le variabili sensitive sono cifrate a riposo usando un meccanismo che impedisce che il valore venga letto dopo la memorizzazione — né dai sistemi di Vercel, né dagli utenti con accesso alla dashboard, né da un attaccante con accesso interno.
Le variabili non-sensitive sono memorizzate in forma leggibile. I sistemi con accesso interno appropriato possono recuperare il valore in chiaro. Questo abilita funzionalità come mostrarti il valore di una variabile nella dashboard — e significa anche che un attaccante con accesso interno può leggerle.
L'attaccante ha acceduto alle variabili non-sensitive. Secondo l'analisi ITECS, i dati compromessi includevano variabili d'ambiente, token npm, token GitHub e 580 record di dipendenti.
Immediatamente dopo l'incidente, Vercel ha cambiato il default: le nuove variabili d'ambiente ora di default sono sensitive: on. È la scelta giusta, e avrebbe dovuto essere il default fin dall'inizio.
La Kill Chain Completa, Assemblata
Febbraio 2026
├── Dipendente Context AI scarica exploit Roblox su laptop di lavoro/personale
└── Lumma Stealer (MaaS, Storm-2477, ~$250-$1.000/mese) esegue
Lumma raccoglie:
├── Cookie browser e password salvate (bypass DPAPI/App-Bound Encryption)
├── Credenziali Google Workspace (email lavoro, account `support@context.ai`)
├── Chiavi API: Supabase, Datadog, Authkit
└── Token OAuth memorizzati da applicazioni desktop/browser
L'attaccante riceve il log credenziali. Pattern-matching rivela:
└── `support@context.ai` = accesso elevato dentro il team Vercel di Context AI
L'attaccante usa l'account support@context.ai:
├── Accede all'ambiente AWS di Context AI (marzo 2026)
└── Estrae OAuth refresh token per utenti Google Workspace connessi
Dentro la raccolta di token:
└── Refresh token per l'account Google del dipendente Vercel (scope "Allow All")
L'attaccante presenta il refresh token rubato all'API di Google:
├── Google emette un nuovo access token (MFA non richiesta — il token È la prova di autenticazione)
└── L'attaccante ha accesso completo al Google Workspace del dipendente Vercel
Dal Google Workspace del dipendente:
├── Pivot SSO negli strumenti interni di Vercel
├── Accesso agli ambienti e alle variabili d'ambiente non-sensitive
└── Esfiltrazione di credenziali, token npm, token GitHub, record dipendenti
19 aprile 2026: Vercel divulga l'incidente
20 aprile 2026: Appare il listing su BreachForums ($2M prezzo richiesto, persona ShinyHunters — gruppo ha negato coinvolgimento)
21 aprile 2026: Questo articolo
Quattro salti. Zero zero-day. Nessuna campagna di phishing mirata a Vercel. Nessuno strumento custom sofisticato. Solo malware commodity, integrazioni OAuth di uno strumento AI, e un token che ha aggirato ogni controllo di autenticazione perché rappresentava già un'autenticazione completata.
La Parte Sugli Strumenti AI Nello Specifico
Ecco la scomoda verità strutturale che questo breach espone.
Ogni strumento di produttività AI che connetti al tuo Google Workspace chiede scope OAuth ampi perché l'accesso ampio è il prodotto. Un assistente email AI deve leggere la tua email. Un riassuntore di meeting AI ha bisogno del tuo calendario. Un tool AI per documenti ha bisogno del tuo Drive. Non puoi costruire il prodotto con scope stretti. Gli scope sono il prodotto.
Questo crea un problema strutturale. Più uno strumento AI è utile — più si integra profondamente con il tuo contesto lavorativo — più ampio è l'accesso che richiede. E più ampio è l'accesso, più catastrofico è il blast radius quando i token OAuth dello strumento vengono compromessi.
Non c'è una soluzione pulita a questo. Puoi minimizzarlo (audit degli scope, revoca degli accessi, account dedicati per strumenti AI) ma non puoi eliminarlo senza sacrificare il valore di integrazione che rende lo strumento utile.
Quello che puoi fare è capire esplicitamente la relazione di fiducia. Quando clicchi "Consenti" su una schermata di permessi Google per uno strumento AI, non stai solo concedendo accesso ai tuoi documenti. Stai concedendo accesso a qualunque attaccante ottenga il controllo del server di quello strumento. Questo è il framing accurato.
Il Precedente Salesloft-Drift Di Cui Nessuno Ha Parlato
Il breach di Vercel non è emerso nel vuoto. C'è un precedente diretto dal 2025 che la comunità developer ha largamente mancato.
Nell'agosto 2025, l'attore di minaccia UNC6395 ha usato token OAuth rubati dall'integrazione Salesforce di Drift per accedere agli ambienti dei clienti attraverso più di 700 organizzazioni. L'attaccante non aveva bisogno di exploit né di phishing. Hanno acceduto al GitHub di Salesloft a marzo 2025, poi hanno sfruttato i token OAuth dell'integrazione Drift per accedere alle istanze Salesforce di centinaia di organizzazioni clienti. La catena completa di esfiltrazione: Account GitHub compromesso → Ambiente AWS di Drift → Token OAuth estratti → Script Python custom hanno interrogato le istanze Salesforce dei clienti → Esfiltrazione di contatti, opportunità, chiavi AWS, token Snowflake.
Un'integrazione. Settecento organizzazioni violate. Il pattern: comprometti uno strumento SaaS a cui molti clienti hanno concesso ampio accesso, estrai i token OAuth memorizzati, usa ognuno per accedere all'ambiente del cliente corrispondente.
Il breach di Vercel è questo pattern applicato al layer degli strumenti developer. Context AI è a Vercel quello che Drift era a quelle 700 organizzazioni Salesforce.
Cosa Dovresti Fare Concretamente
Basta analisi. Ecco la parte pratica, ordinata per priorità.
Se Hai Progetti su Vercel (Fallo Oggi)
1. Apri il riepilogo delle variabili d'ambiente
Vai su vercel.com/all-env-vars. Mostra tutte le variabili di tutti i progetti in un posto, incluso il loro stato di sensibilità.
2. Identifica tutto quello che non è marcato sensitive
URL database, chiavi API, segreti di autenticazione, token webhook, chiavi di firma — qualsiasi cosa che fornisce accesso a sistemi esterni. Se il valore causerebbe danni reali se trapelasse, dovrebbe essere marcato sensitive.
3. Ruota i valori esposti — non limitarti a re-salvarli
Ruotare significa generare una nuova credenziale alla sorgente, non solo cambiare dove memorizzi il valore esistente. Se il vecchio valore era potenzialmente esposto, è compromesso. Una nuova env var con il vecchio valore non fornisce zero protezione.
4. Marca tutto sensitive andando avanti
Il nuovo default di Vercel lo fa automaticamente per le nuove variabili. Per le variabili esistenti: clicca la variabile nella dashboard, abilita il flag sensitive, reinserisci il valore.
5. Abilita MFA sul tuo account Vercel
Vai su Settings → Authentication → configura un'app authenticator o una passkey.
6. Controlla l'IOC pubblicato da Vercel
Se sei un amministratore Google Workspace, controlla questa app OAuth nelle app autorizzate:
Audit delle Connessioni OAuth (Fallo Questa Settimana)
Audit account Google:
Vai su myaccount.google.com → Sicurezza → App di terze parti con accesso all'account
Per ogni app: la riconosci? la usi ancora? i permessi sono giustificati?
Revoca tutto quello che non riesci a spiegare
Audit admin Google Workspace:
Admin Console → Sicurezza → Controlli API → Gestisci l'accesso alle app di terze parti
Filtra per "Autorizzate" per vedere tutto ciò che ha accesso nella tua org
Cerca app con scope ampi sugli account del team core
Audit GitHub:
Settings → Applications → Authorized OAuth Apps
Revoca qualsiasi cosa inattiva o sconosciuta
Il Principio di Minimizzazione degli Scope
Quando valuti nuovi strumenti AI: prima di cliccare "Consenti," esamina gli scope richiesti. Lo strumento ha davvero bisogno di quello che sta chiedendo? Gli scope ampi creano blast radius ampio.
Dove possibile, connetti gli strumenti di produttività AI a account Google dedicati (non la tua identità aziendale principale). Sì, aggiunge attrito. Significa anche che un token compromesso per quell'account non dà accesso alla tua email aziendale, ai documenti sensibili e ai sistemi admin.
Gestione del Ciclo di Vita dei Token
I token OAuth non dovrebbero essere permanenti. Best practice da RFC 9700 (pubblicato gennaio 2025):
Rotazione del refresh token: ogni volta che un refresh token viene usato per ottenere un nuovo access token, dovrebbe essere invalidato e sostituito con uno nuovo.
Durate appropriate: per le API sensitive, i refresh token dovrebbero scadere entro 7-30 giorni.
Inventario dei token: mantieni un registro delle app OAuth che la tua organizzazione ha autorizzato. Includilo nella tua checklist di offboarding.
La Lezione Più Profonda
Ecco su cosa continuo a tornare mentre leggo i dettagli tecnici.
Ogni anello della catena di attacco — l'infezione Lumma, l'handshake OAuth, la memorizzazione del token, il pivot nel Google Workspace — funzionava tecnicamente come progettato. Lumma ha fatto quello che fanno gli infostealer. OAuth ha emesso token nel modo in cui OAuth emette token. Google ha onorato un refresh token valido. Vercel ha memorizzato variabili d'ambiente nel modo in cui lo aveva sempre fatto.
Ogni anello di quella catena funzionava tecnicamente come progettato. È esattamente per questo che ha funzionato.
Non c'era nessun bug da patchare che avrebbe fermato questo. L'attacco ha sfruttato il divario tra quello che la tecnologia fa e quello che gli utenti assumono che faccia. La maggior parte delle persone assume che OAuth sia sicuro perché hanno usato MFA quando lo hanno configurato. La maggior parte delle persone assume che le proprie credenziali siano protette perché usano un password manager. La maggior parte delle persone assume che se qualcuno non conosce la loro password, non può accedere al loro account.
Nessuna di queste assunzioni regge contro un token che è già nel database di qualcun altro.
La domanda non è "è affidabile questo strumento?" — è "qual è il blast radius se l'infrastruttura di questo strumento viene compromessa domani?"
Questa è la domanda che la maggior parte degli sviluppatori non si fa mai.
Status al 21 Aprile 2026
L'investigazione è attiva. Vercel sta lavorando con Mandiant, ulteriori aziende di cybersicurezza e le forze dell'ordine. Context AI sta cooperando. La portata di quello che è stato acceduto ed esfiltrato è ancora in corso di determinazione.
Il CEO di Vercel Guillermo Rauch ha postato su X confermando che la supply chain — Next.js, Turbopack e i pacchetti open source — è verificata sicura. Aggiornamenti del prodotto spediti: la creazione di variabili d'ambiente ora di default è sensitive, migliore gestione delle variabili a livello di team, migliore tooling per i log di attività, flussi di invito del team più chiari.
Se usi Vercel, le voci della checklist sopra non sono opzionali. Falle oggi.
Se stai pensando "questo non accadrà alla mia azienda, siamo troppo piccoli" — la società che è stata compromessa qui è Context AI, una piccola startup AI. L'attaccante non ha scelto Context AI a causa delle sue dimensioni o importanza strategica. Ha trovato un log Lumma con credenziali utili e ha seguito la catena.
Il threat model non è mirato. È opportunistico e sistematico.
