Vercel Breach 2026: OAuth, Lumma Stealer e il problema dei segreti
Come la compromissione di uno strumento AI di terze parti è arrivata fino a Vercel, perché i token OAuth sono ormai parte della supply chain software, e cosa rivela l'incidente di aprile 2026 sulla gestione dei segreti nelle infrastrutture developer.
C'è un dettaglio nell'incidente Vercel che spiega perché questa storia conta oltre il singolo vendor: il percorso ufficiale del breach non è iniziato con un attacco diretto a Vercel. Vercel afferma che l'incidente è nato dalla compromissione di Context.ai, uno strumento AI di terze parti usato da un dipendente Vercel, e che l'attaccante ha usato quell'accesso per prendere controllo dell'account Google Workspace del dipendente prima di muoversi nei sistemi Vercel.
Reporting esterno e ricerca sugli infostealer collegano la compromissione di Context.ai ad attività Lumma Stealer e al download di un exploit Roblox. È un dettaglio importante, ma va trattato con disciplina sulle fonti: Vercel ha confermato il pivot Context.ai e Google Workspace; l'origine game-cheat/Lumma arriva da reporting esterno e threat intelligence.
Il blast radius confermato è più stretto e più preciso rispetto ad alcuni titoli iniziali. Vercel dice che gli attaccanti hanno raggiunto alcuni sistemi interni e sono riusciti a enumerare e decrittare variabili d'ambiente non-sensitive. Vercel dice anche che l'indagine con GitHub, Microsoft, npm e Socket non ha trovato nessuna compromissione dei pacchetti npm pubblicati da Vercel.
Vercel ha pubblicato il bollettino di sicurezza il 19 aprile 2026 e lo ha aggiornato fino al 24 aprile 2026. L'azienda ha identificato un sottoinsieme limitato di clienti impattati, li ha notificati, e poi ha trovato un piccolo numero di account aggiuntivi ampliando la revisione degli IOC.
Questo articolo spiega l'incidente tecnicamente, ma tiene pulita l'attribuzione: prima le conferme ufficiali di Vercel, poi il reporting esterno chiaramente etichettato, poi la lezione pratica per gli sviluppatori.
Stato confermato più recente
Secondo il bollettino Vercel aggiornato al 24 aprile 2026:
- L'incidente è nato dalla compromissione di Context.ai, uno strumento AI di terze parti usato da un dipendente Vercel.
- L'attaccante ha usato quell'accesso per prendere controllo dell'account Google Workspace individuale del dipendente, poi ha fatto pivot in un ambiente Vercel.
- Vercel dice che l'attaccante ha enumerato e decrittato variabili d'ambiente non-sensitive.
- Vercel ha identificato un sottoinsieme limitato di clienti impattati, poi un piccolo numero di account aggiuntivi durante la revisione estesa degli IOC.
- Vercel dice che compromissioni separate di clienti trovate durante la revisione non sembrano originate dai sistemi Vercel.
- Vercel dice che nessun pacchetto npm pubblicato da Vercel è stato compromesso.
- Vercel ha spedito miglioramenti di prodotto su gestione delle variabili d'ambiente, visibilità security a livello team e activity log.
Questa combinazione è il motivo per cui l'incidente conta. Non è la classica storia "hosting provider hackerato". È una storia su come strumenti AI di produttività, grant OAuth, identità Google Workspace e segreti di deployment ormai formino un'unica superficie d'attacco.
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, spesso salvi nel suo sistema di environment variable credenziali del database, chiavi API, segreti di firma, token webhook e configurazione di deployment. Anche i pacchetti npm mantenuti da Vercel sono distribuiti ampiamente nell'ecosistema JavaScript. 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. Vercel dice che non ci sono prove di manomissione dei pacchetti che pubblica.
La lezione più dura: tutto il resto di questa storia riguarda il funzionamento della fiducia in un ecosistema software costruito su 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 disruption 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.
Vercel conferma che l'attaccante ha acceduto alle variabili d'ambiente non-sensitive. Alcuni report esterni hanno indicato categorie di dati aggiuntive, ma la guida operativa dell'articolo va ancorata all'esposizione confermata: i segreti leggibili vanno trattati come potenzialmente compromessi e ruotati alla fonte.
Dopo l'incidente, Vercel ha evidenziato lavoro di prodotto su default più forti per le variabili d'ambiente, gestione a livello team, safeguard migliori, educazione in-product e activity log più densi. La direzione è corretta: i segreti che non devono essere riletti non dovrebbero essere leggibili dalle superfici ordinarie del prodotto.
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
└── Enumerazione/decrittazione di variabili d'ambiente non-sensitive
19 aprile 2026: Vercel divulga l'incidente
20-24 aprile 2026: Vercel amplia la guidance, conferma che i pacchetti npm non sono compromessi e spedisce miglioramenti di prodotto
27 aprile 2026: Questo articolo viene aggiornato
Quattro salti nella versione più pulita della storia: compromissione di uno strumento AI di terze parti, takeover Google Workspace, accesso a un ambiente interno, segreti leggibili. Il punto chiave non è che ogni dettaglio esterno sia provato. Il punto chiave è che i token OAuth possono trasformare la compromissione di un piccolo vendor in accesso dentro il perimetro identity di un cliente molto più grande.
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. 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: Account GitHub compromesso → Ambiente AWS di Drift → Token OAuth estratti → Script Python custom → Esfiltrazione di contatti, opportunità, chiavi AWS, token Snowflake.
Un'integrazione. Settecento organizzazioni violate. 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.
Azioni Immediate (Da Fare Oggi)
L'IOC da Controllare Subito
Se sei un amministratore Google Workspace, controlla questa app OAuth nelle app autorizzate:
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Se la vedi, revocala immediatamente.
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.
Status al 27 aprile 2026
Vercel ha spostato il bollettino su una cadenza di aggiornamento ad hoc dopo il 24 aprile. L'indagine e la remediation hanno coinvolto Google Mandiant, ulteriori aziende di cybersicurezza, peer del settore, forze dell'ordine e un confronto diretto con Context.ai.
Il punto confermato più importante per gli sviluppatori è che Vercel dice che la sua supply chain npm non è stata compromessa. Il punto operativo più importante resta la rotazione delle credenziali: i valori non marcati come sensitive vanno trattati come potenzialmente esposti se il tuo account è stato notificato o se i tuoi log mostrano accessi sospetti.
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", stai guardando il rischio dalla parte sbagliata. Anche strumenti AI piccoli possono conservare refresh token, grant workspace, credenziali di supporto e accessi di integrazione da cui dipendono clienti molto più grandi. L'attaccante non deve scegliere te per primo. Può seguire qualunque catena di credenziali utile trovi.
Il threat model non è mirato. È opportunistico e sistematico.
Aggiornato il 27 aprile 2026. Fonte primaria: bollettino di sicurezza Vercel. Contesto di supporto: analisi Microsoft su Lumma, TechCrunch, Hudson Rock, CyberArk C4 Attack, analisi ITECS e Obsidian Security. Il reporting esterno è trattato come contesto salvo conferma Vercel.