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 ormai fanno parte della supply chain del software, e cosa ci dice l'incidente di aprile 2026 su come gestiamo i segreti nelle infrastrutture per sviluppatori.
C'è un dettaglio, nell'incidente Vercel, che spiega perché questa storia vale più del singolo vendor: il percorso ufficiale del breach non è cominciato con un attacco diretto a Vercel. Secondo Vercel tutto è partito dalla compromissione di Context.ai, uno strumento AI di terze parti usato da un dipendente; da lì l'attaccante ha preso il controllo dell'account Google Workspace del dipendente, e solo dopo si è mosso dentro i sistemi Vercel.
Reporting esterno e ricerca sugli infostealer collegano la compromissione di Context.ai ad attività Lumma Stealer e al download di un exploit per Roblox. È un tassello importante, ma va maneggiato con disciplina sulle fonti: Vercel ha confermato il pivot via Context.ai e Google Workspace; l'origine game-cheat/Lumma arriva invece da reporting esterno e threat intelligence.
Il blast radius confermato è più stretto e più preciso di quanto lasciassero intendere certi titoli della prima ora. Vercel dice che gli attaccanti hanno raggiunto alcuni sistemi interni e sono riusciti a enumerare e decrittare variabili d'ambiente non-sensitive. E dice anche che l'indagine condotta con GitHub, Microsoft, npm e Socket non ha trovato alcuna compromissione dei pacchetti npm pubblicati da Vercel.
Il bollettino di sicurezza è uscito il 19 aprile 2026 ed è stato aggiornato fino al 24. Vercel ha individuato un sottoinsieme limitato di clienti colpiti, li ha avvisati, e allargando la revisione degli IOC ha poi trovato un piccolo numero di account aggiuntivi.
Questo articolo racconta l'incidente sul piano tecnico, ma tiene pulita l'attribuzione: prima le conferme ufficiali di Vercel, poi il reporting esterno etichettato come tale, infine la lezione pratica per chi sviluppa.
Stato confermato più recente
Ecco cosa dice il bollettino Vercel aggiornato al 24 aprile 2026:
- L'incidente è partito dalla compromissione di Context.ai, strumento AI di terze parti usato da un dipendente Vercel.
- L'attaccante ha sfruttato quell'accesso per impossessarsi dell'account Google Workspace individuale del dipendente, poi ha fatto pivot in un ambiente Vercel.
- L'attaccante ha enumerato e decrittato variabili d'ambiente non-sensitive.
- Vercel ha identificato un sottoinsieme limitato di clienti colpiti, e un piccolo numero di account aggiuntivi durante la revisione estesa degli IOC.
- Alcune compromissioni di clienti emerse durante la revisione non sembrano avere origine nei sistemi Vercel.
- Nessun pacchetto npm pubblicato da Vercel è stato compromesso.
- Vercel ha rilasciato migliorie di prodotto su gestione delle variabili d'ambiente, visibilità security a livello team e activity log.
È questa combinazione a rendere l'incidente interessante. Non è la solita storia dell'hosting provider bucato. È una storia su come strumenti AI di produttività, grant OAuth, identità Google Workspace e segreti di deployment siano ormai diventati un'unica, continua superficie d'attacco.
Perché vale la pena capire proprio Vercel
Un po' di contesto, prima di scendere in profondità.
Vercel non è solo un hosting provider. È infrastruttura per una fetta consistente del web moderno: piattaforma di deployment per applicazioni costruite da milioni di sviluppatori, manutentore principale di Next.js (uno dei framework JavaScript più scaricati del pianeta) e custode fidato dei segreti di produzione di un gran numero di aziende — tra cui, notoriamente, OpenAI, Cursor, Pinterest e Bose.
Quando usi Vercel, dentro il suo sistema di environment variable finiscono spesso credenziali del database, chiavi API, signing secret, token dei webhook, configurazione di deployment. E i pacchetti npm che Vercel mantiene circolano in tutto l'ecosistema JavaScript. Se quei pacchetti fossero stati compromessi, il danno a cascata sarebbe stato enorme.
La buona notizia è che la supply chain npm è pulita: Vercel l'ha verificato insieme a GitHub, Microsoft, npm e Socket, e non ci sono prove di manomissione dei pacchetti che pubblica.
La lezione più dura è tutto il resto: questa storia parla di come funziona la fiducia in un ecosistema software costruito sopra integrazioni di terze parti.
Anatomia di un attacco alla supply chain
Prima di ripercorrere i fatti, conviene inquadrare la categoria.
Un attacco alla supply chain non colpisce la vittima in modo diretto. Colpisce qualcosa di cui la vittima si fida. La logica è elementare: le grandi aziende spendono cifre importanti per difendere il proprio perimetro. Hanno team di sicurezza, intrusion detection, monitoraggio, infrastrutture blindate. Attaccarle di petto costa caro e spesso non porta a nulla.
Ma ogni azienda si fida anche di vendor, strumenti, servizi e integrazioni di terze parti. E quelle terze parti hanno perimetri propri, spesso molto meno protetti. Compromettine una fidata, ed erediti tutti gli accessi che i suoi clienti le hanno concesso. Non serve sfondare il muro, se hai la chiave di una porta di servizio.
È così che gli attacchi alla supply chain sono diventati una delle categorie di breach dominanti degli ultimi anni. L'esempio più celebre resta SolarWinds (2020), dove gli attaccanti hanno compromesso un sistema di aggiornamento software per raggiungere migliaia di organizzazioni in un colpo solo. Da allora il ritmo è solo accelerato.
Il breach di Vercel è un caso da manuale — con una torsione tutta contemporanea. Qui la supply chain non è un sistema di build. È un'integrazione OAuth tra strumenti AI di produttività. E la chiave della porta di servizio non era una password. Era un token.
Atto I — Lumma Stealer, spiegato
Per capire come uno script per Roblox abbia messo in moto tutto questo, bisogna capire cos'è davvero Lumma Stealer.
Il malware come modello di business
Lumma Stealer (noto anche come LummaC2) non è opera di un hacker solitario in cantina. È un prodotto commerciale. Un'operazione Malware-as-a-Service (MaaS), sviluppata e mantenuta da un threat actor di lingua russa che si firma "Shamel" e che Microsoft Threat Intelligence traccia con la sigla Storm-2477.
Lumma veniva venduto in abbonamento, da 250 a 1.000 dollari al mese, con l'accesso al codice sorgente a quota 20.000. I livelli base offrono filtri sui log e opzioni di download; quelli alti aggiungono configurazioni di raccolta dati su misura, tecniche di evasione più sofisticate e accesso anticipato alle nuove funzionalità. Il piano più costoso — il codice sorgente — permette al cliente di sfornarsi un derivato tutto suo e rivenderlo.
In un'intervista al ricercatore "g0njxa" nel novembre 2023, Shamel raccontava di avere "circa 400 clienti attivi". Aveva costruito un brand attorno a Lumma, logo con un uccello incluso, presentato come simbolo di "pace, leggerezza e tranquillità", accompagnato dallo slogan "fare soldi con noi è altrettanto facile".
Questo è un business a tutti gli effetti. Con clienti, livelli di supporto, marketing e changelog. La barriera d'ingresso è tenuta bassa di proposito: l'obiettivo è il volume, non la raffinatezza.
Cosa fa Lumma sulla tua macchina
Appena Lumma parte su una macchina Windows, la prima mossa è il fingerprinting dell'ambiente: versione dell'OS, hardware ID, CPU, RAM, risoluzione dello schermo, lingua di sistema. Non è curiosità, è filtraggio. Il malware verifica di non trovarsi in una sandbox o in un ambiente d'analisi. Se ne rileva una, esce senza fare nulla. L'evasione è cablata nel cuore del programma.
Convinto che la macchina sia reale, fa partire le routine di raccolta. Ed ecco cosa si porta via davvero:
Dai browser (Chrome, Edge, Firefox, Brave, Opera e altri):
I dati che contano vivono in poche posizioni chiave. Chrome tiene le password in un database SQLite chiamato Login Data e i cookie in un altro, Cookies. I valori sono cifrati — ma qui sta il trucco.
Storicamente Chrome cifrava questi dati con Windows DPAPI (Data Protection API). DPAPI usa una chiave derivata dalle credenziali di login Windows dell'utente, e la protezione che offre è tra utenti, non tra processi. Qualsiasi processo che gira come l'utente attualmente loggato può chiamare CryptUnprotectData() e decifrare tutto. Tradotto: Lumma, che gira come l'utente corrente (perché è l'utente corrente ad averlo scaricato ed eseguito), decifra l'intero archivio di password e cookie di Chrome senza sforzo.
Proprio per chiudere questa falla, con Chrome 127 (luglio 2024) Google ha introdotto la App-Bound Encryption: la decifratura passa ora per un servizio Windows privilegiato che gira come SYSTEM e che, prima di restituire la chiave, verifica che a chiederla sia davvero Chrome. In teoria, un malware a livello utente resta fuori.
App-Bound Encryption è stata rilasciata il 30 luglio 2024. I ricercatori hanno documentato le prime capacità di bypass già il 12 settembre 2024: meno di 45 giorni dopo.
Oltre ai browser:
Lumma dà la caccia anche a wallet di criptovalute ed estensioni — file dei wallet, estensioni del browser, chiavi locali di portafogli come MetaMask, Electrum ed Exodus. La configurazione arriva dal server C2 attivo e definisce i bersagli: crypto, browser, configurazioni VPN, client email, client FTP, dati di sessione Telegram, chiavi SSH, file .env, dati dei password manager, documenti dell'utente.
L'output di un'infezione Lumma è un archivio strutturato — nel gergo degli infostealer, un "log" — caricato in tempo reale sull'infrastruttura C2 dell'attaccante. Un singolo log può contenere centinaia di credenziali, decine di session cookie e i token OAuth di ogni servizio web a cui l'utente infetto era collegato.
Come si diffonde Lumma
Lumma incarna alla perfezione lo spostamento verso strategie di consegna multi-vettore. I suoi operatori sono maestri di impersonificazione: ruotano di continuo i domini malevoli, sfruttano i circuiti pubblicitari e si appoggiano a servizi cloud legittimi per sfuggire ai controlli.
Nel caso del dipendente di Context AI, il vettore era un tool di exploit per Roblox — un cheat per videogiochi. È uno dei metodi di consegna più vecchi del mondo, e tra i più efficaci. Chi scarica un cheat ha già deciso di ignorare gli avvisi di sicurezza, disattivare gli strumenti di protezione ed entrare mentalmente in modalità "me la rischio". La giustificazione per abbassare ogni difesa se la fornisce da solo.
Lo smantellamento e il ritorno
Tra il 16 marzo e il 16 maggio 2025 Microsoft ha censito oltre 394.000 computer Windows infettati da Lumma in tutto il mondo. In collaborazione con forze dell'ordine e partner del settore — Europol, FBI, ESET, BitSight, Cloudflare e altri — la Digital Crimes Unit di Microsoft ha avviato un'azione civile e sequestrato circa 2.300 domini malevoli, la spina dorsale dell'infrastruttura di Lumma.
Un colpo pesante. Ma non fatale.
L'attività ha ripreso quota nel giro di poche settimane e, tra fine 2025 e inizio 2026, le campagne erano di nuovo in crescita a livello globale. La macchina del dipendente di Context AI è stata infettata a febbraio 2026 — circa nove mesi dopo il grande takedown. Lumma si era già ricostruita.
È la natura stessa del MaaS: l'infrastruttura la puoi sequestrare, ma lo sviluppatore, il codice e la rete di affiliati restano lì.
Atto II — Il ponte OAuth
L'infezione Lumma ha consegnato all'attaccante un dump di credenziali dalla macchina del dipendente di Context AI. Nel bottino: le credenziali Google Workspace del suo account di lavoro, quelle di support@context.ai — che l'analisi di Hudson Rock indica come account del team core — e le chiavi API di Supabase, Datadog e Authkit.
OAuth: il protocollo che ha rimpiazzato le password (creando nuovi problemi)
OAuth nasce per risolvere un problema concreto: come permettere all'Applicazione B di accedere ai tuoi dati custoditi nel Servizio A senza consegnarle la tua password del Servizio A?
Al termine dell'autorizzazione iniziale, il flusso OAuth 2.0 emette due token:
- Un access token: a vita breve (di solito 60 minuti), usato direttamente nelle chiamate API.
- Un refresh token: a vita lunga, usato per ottenere nuovi access token senza dover interpellare di nuovo l'utente.
Perché i refresh token sono la vera superficie d'attacco
I refresh token sono credenziali bearer: chi possiede il token può usarlo senza ulteriori verifiche d'identità. Una volta che il flusso di consenso OAuth iniziale si è chiuso con l'MFA, il refresh token risultante apre la porta a un accesso continuo, senza mai riautenticarsi.
"Credenziale bearer" vuol dire esattamente ciò che sembra: possederla equivale a essere autorizzati. Niente secondo fattore, niente binding al dispositivo, niente verifica dell'IP. Se hai il token, per il resource server tu sei la parte autorizzata.
Da qui un'implicazione decisiva: l'MFA non protegge dal furto del refresh token. L'MFA è avvenuta quando l'utente ha autorizzato l'app la prima volta. Il token che ne è nato rappresenta quell'autorizzazione passata. Chi ruba il token non deve riautenticarsi, perché l'autenticazione c'è già stata — e la prova è il token stesso.
E c'è di peggio: la maggior parte delle app SaaS non invalida in automatico i refresh token esistenti quando resetti la password o modifichi l'MFA. Chi ha rubato un refresh token mantiene l'accesso finché quel token specifico non viene revocato in modo esplicito — anche dopo le classiche procedure di incident response.
La posizione OAuth di Context AI
Context AI è una AI Office Suite: si connette al tuo Google Workspace, legge documenti, email e calendario, e ti offre assistenza basata su AI. Per farlo, conserva un refresh token per ogni utente che la autorizza. Quei token vivono sui server di Context AI.
L'attaccante, ormai in possesso delle credenziali dell'account support@context.ai, è entrato nei sistemi di Context AI. E lì dentro c'erano i refresh token di ogni account Google Workspace collegato.
Vercel non è cliente di Context, ma pare che almeno un suo dipendente si fosse iscritto alla AI Office Suite con l'account enterprise Vercel, concedendo i permessi "Allow All". La frase chiave è proprio questa: "Allow All". È lo scope massimo — un token OAuth a questo livello dà a chi lo detiene accesso praticamente totale all'account Google collegato.
L'attaccante ha trovato quel token nel database di Context AI. E lo ha usato. I sistemi di Google hanno visto un refresh token valido, emesso legittimamente. Non è scattato alcun allarme.
Atto III — Dentro Vercel
Dall'account Google Workspace del dipendente Vercel, l'attaccante aveva ormai un piede nell'infrastruttura Google aziendale. E, a seconda di come era configurato il single sign-on, quel piede poteva allungarsi su qualsiasi strumento interno che si autenticasse via Google.
Vercel ha classificato l'attaccante come altamente sofisticato, per la velocità operativa e per la conoscenza minuziosa dei suoi sistemi. Si è mosso in fretta e con precisione chirurgica. Sapeva cosa cercare.
Ha trovato le variabili d'ambiente.
Il problema sensitive vs. non-sensitive
Vercel offre due modalità di storage per le variabili d'ambiente:
Le variabili sensitive sono cifrate at rest con un meccanismo che impedisce di rileggerne il valore dopo il salvataggio — né dai sistemi di Vercel, né dagli utenti con accesso alla dashboard, né da un attaccante con accesso interno.
Le variabili non-sensitive restano invece in forma leggibile. I sistemi con i giusti permessi interni possono recuperarne il valore in chiaro. È questo che permette funzioni come mostrarti il valore di una variabile nella dashboard — ed è sempre questo che consente a un attaccante con accesso interno di leggerle.
Vercel conferma che l'attaccante ha raggiunto le variabili d'ambiente non-sensitive. Qualche report esterno ha parlato di ulteriori categorie di dati, ma la guida operativa dell'articolo resta ancorata all'esposizione confermata: i segreti leggibili vanno considerati potenzialmente compromessi e ruotati alla fonte.
Dopo l'incidente, Vercel ha messo mano al prodotto: default più robusti per le variabili d'ambiente, gestione a livello team, safeguard migliori, educazione in-product e activity log più ricchi. La direzione è quella giusta: un segreto che non deve essere riletto non dovrebbe essere leggibile dalle superfici ordinarie del prodotto.
La kill chain completa, montata pezzo per pezzo
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 del Google Workspace, accesso a un ambiente interno, segreti leggibili. Il punto non è se ogni singolo dettaglio esterno sia provato oltre ogni dubbio. Il punto è che i token OAuth possono trasformare la compromissione di un piccolo vendor in un accesso dentro il perimetro d'identità di un cliente molto più grande.
La questione degli strumenti AI, nello specifico
Ed ecco la scomoda verità strutturale che questo breach porta a galla.
Ogni strumento di produttività AI che colleghi 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 ha bisogno del calendario. Un tool per i documenti ha bisogno del Drive. Non puoi costruire il prodotto con scope stretti. Gli scope sono il prodotto.
Il che genera un problema strutturale. Più uno strumento AI è utile — più si integra a fondo nel tuo contesto di lavoro — più ampio è l'accesso che pretende. E più l'accesso è ampio, più catastrofico è il blast radius quando i suoi token OAuth finiscono compromessi.
Una soluzione pulita, qui, non c'è. Quello che puoi fare è guardare in faccia la relazione di fiducia. Quando clicchi "Consenti" sulla schermata dei permessi Google di uno strumento AI, non stai concedendo accesso solo ai tuoi documenti. Lo stai concedendo a chiunque prenderà il controllo del server di quello strumento. Questa è l'inquadratura corretta.
Il precedente Salesloft-Drift di cui nessuno ha parlato
Il breach di Vercel non è nato nel vuoto. C'è un precedente diretto, del 2025, che la comunità degli sviluppatori si è largamente lasciata sfuggire.
Ad agosto 2025 il threat actor UNC6395 ha usato token OAuth rubati all'integrazione Salesforce di Drift per entrare negli ambienti dei clienti di oltre 700 organizzazioni. Nessun exploit, nessun phishing. Sono entrati nel GitHub di Salesloft a marzo 2025, poi hanno sfruttato i token OAuth dell'integrazione Drift per raggiungere le istanze Salesforce di centinaia di organizzazioni. La catena per intero: account GitHub compromesso → ambiente AWS di Drift → token OAuth estratti → script Python su misura → esfiltrazione di contatti, opportunità, chiavi AWS, token Snowflake.
Un'integrazione. Settecento organizzazioni violate. Il breach di Vercel è lo stesso identico pattern applicato al livello degli strumenti per sviluppatori. Context AI sta a Vercel come Drift stava a quelle 700 organizzazioni Salesforce.
Cosa dovresti fare, concretamente
Basta analisi. Ecco la parte operativa.
Azioni immediate (da fare oggi)
L'IOC da controllare subito
Se amministri un Google Workspace, cerca questa app OAuth tra quelle autorizzate:
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Se la trovi, revocala all'istante.
Il principio di minimizzazione degli scope
Quando valuti un nuovo strumento AI, prima di cliccare "Consenti" leggi gli scope richiesti. Ha davvero bisogno di tutto quello che chiede? Scope ampi significano blast radius ampio.
Dove puoi, collega gli strumenti di produttività AI ad account Google dedicati, non alla tua identità aziendale principale. Sì, aggiunge attrito. Ma vuol dire anche che un token compromesso per quell'account non apre la porta alla tua email aziendale, ai documenti sensibili e ai sistemi admin.
Gestione del ciclo di vita dei token
I token OAuth non dovrebbero essere eterni. Le best practice dell'RFC 9700 (gennaio 2025):
- Rotazione del refresh token: ogni volta che un refresh token viene usato per ottenere un nuovo access token, andrebbe invalidato e sostituito con uno nuovo.
- Durate adeguate: per le API sensibili, i refresh token dovrebbero scadere entro 7-30 giorni.
- Inventario dei token: tieni un registro delle app OAuth che la tua organizzazione ha autorizzato. E mettilo nella checklist di offboarding.
La lezione più profonda
Ecco il punto su cui continuo a tornare, mentre rileggo i dettagli tecnici.
Ogni anello della catena d'attacco — l'infezione Lumma, l'handshake OAuth, la conservazione del token, il pivot nel Google Workspace — ha funzionato tecnicamente come previsto. 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 le variabili d'ambiente come aveva sempre fatto.
Ogni anello di quella catena ha funzionato esattamente come da progetto. Ed è proprio per questo che l'attacco ha funzionato.
Non c'era alcun bug da patchare che l'avrebbe fermato. L'attacco ha sfruttato lo scarto tra ciò che la tecnologia fa e ciò che gli utenti danno per scontato che faccia. Quasi tutti pensano che OAuth sia sicuro perché hanno usato l'MFA in fase di setup. Quasi tutti pensano che le proprie credenziali siano al sicuro perché usano un password manager. Quasi tutti pensano che, se qualcuno non conosce la loro password, non possa entrare nel loro account.
Nessuna di queste convinzioni regge davanti a un token che è già nel database di qualcun altro.
Situazione al 27 aprile 2026
Dopo il 24 aprile, Vercel ha spostato il bollettino su una cadenza di aggiornamento ad hoc. Indagine e remediation hanno coinvolto Google Mandiant, altre aziende di cybersicurezza, peer del settore, forze dell'ordine e un confronto diretto con Context.ai.
Per chi sviluppa, la conferma più importante è che la supply chain npm di Vercel 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 log mostrano accessi sospetti.
Se usi Vercel, le voci della checklist qui sopra non sono facoltative. Falle oggi.
E se stai pensando "alla mia azienda non capiterà, siamo troppo piccoli", stai guardando il rischio dal verso sbagliato. Anche uno strumento AI minuscolo può custodire refresh token, grant di workspace, credenziali di supporto e accessi d'integrazione da cui dipendono clienti molto più grandi. All'attaccante non serve scegliere proprio te per primo. Gli basta seguire una qualunque catena di credenziali utile che gli capiti sotto mano.
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.