Il 19 aprile 2026, Vercel, la piattaforma che ospita e distribuisce le applicazioni web di migliaia di aziende nel mondo, pubblica un security bulletin. Il CEO Guillermo Rauch conferma su X quello che i forum underground avevano già annunciato: qualcuno aveva violato i sistemi interni. Il gruppo ShinyHunters stava vendendo dati rubati su BreachForums a 2 milioni di dollari.
Il punto di ingresso? Uno strumento AI di terze parti. Integrato via OAuth. Usato da un dipendente Vercel nel suo account Google Workspace aziendale.
La catena di eventi che ha portato fino a lì, però, era iniziata molto prima: a febbraio. E aveva preso avvio dal laptop di un dipendente di una piccola startup, mentre cercava script per automatizzare un gioco su Roblox.
Fase 1: Il paziente zero. Lumma Stealer e gli auto-farm di Roblox
Il punto di partenza di questo incidente non è un server mal configurato, non è una vulnerabilità zero-day, non è un attacco di stato. È una ricerca su Google per trovare un “executor”, uno strumento che permette di eseguire script Lua non autorizzati all’interno di Roblox per automatizzare azioni di gioco, i cosiddetti auto-farm.
Un dipendente di Context.ai, una startup che costruisce agenti AI enterprise addestrati sulla conoscenza istituzionale delle aziende, scarica uno di questi file da un sito di terze parti. Il file esegue quello che promette, e nel frattempo installa silenziosamente Lumma Stealer.
Lumma è una delle famiglie di infostealer più attive del 2025-2026. Funziona così: una volta sul dispositivo, si dedica a estrarre sistematicamente tutto quello che trova in memoria e nei file locali. Browser history. Cookie di sessione. Password salvate. Token OAuth memorizzati. Credenziali applicative. File di configurazione. Il tutto compresso e inviato a un server C2 (Command and Control) controllato dal threat actor.
Il database di cybercrime intelligence di Hudson Rock conteneva una sola infezione da infostealer associata a Context.ai. Esattamente questo dipendente. Esattamente questo mese. Una correlazione che rende altamente probabile che da qui sia partito tutto.
Dai log estratti dalla macchina compromessa emergono le credenziali esfiltrate: account Google Workspace aziendale, chiavi di accesso a Supabase, Datadog, Authkit. E, soprattutto, l’account support@context.ai, un account con accesso privilegiato ai sistemi interni della società.
Fase 2: Il pivot. Da Context.ai a Vercel via OAuth
Qui la storia diventa tecnicamente interessante. Context.ai non è solo una startup qualsiasi: è un vendor integrato nei flussi di lavoro di Vercel. Un dipendente Vercel aveva autorizzato l’applicazione Google Workspace di Context.ai a connettersi al proprio account aziendale, tramite OAuth.
Il meccanismo OAuth è, in sé, progettato per essere sicuro. Il problema è come viene operato nella pratica.
Quando un’applicazione di terze parti richiede accesso a un account Google Workspace via OAuth, viene emesso un token OAuth, una stringa crittografata che rappresenta l’autorizzazione delegata. Quel token:
non richiede password per essere usato
bypassa l’MFA perché l’autenticazione è già avvenuta al momento dell’emissione
non scade automaticamente se non viene revocato esplicitamente
non genera alert sui sistemi di monitoraggio tradizionali, perché da un punto di vista tecnico si tratta di accesso legittimo
ShinyHunters, una volta in possesso delle credenziali di Context.ai (ottenute attraverso il token rubato da Lumma), ha avuto accesso all’ambiente AWS di Context.ai. Lì erano conservati, non cifrati, i token OAuth rilasciati dagli utenti che avevano connesso il loro Google Workspace all’applicazione.
Tra questi token: quello di un dipendente Vercel.
Con quel token, l’attaccante ha potuto accedere al Google Workspace del dipendente Vercel senza toccare una password, senza attivare nessun meccanismo di verifica, senza lasciare tracce nei log di autenticazione standard.
Fase 3: Il bottino e il tempo perso
Dentro il Google Workspace del dipendente Vercel, ShinyHunters ha trovato accesso diretto alle environment variables dei progetti interni: API key, token di database, segreti crittografici. Vercel distingue le variabili in “sensitive” e “non-sensitive”, ma chi decide la classificazione è il developer che ha configurato il progetto, spesso sotto pressione, spesso senza una policy aziendale chiara. Il risultato è che molte chiavi con blast radius elevato finiscono nella categoria leggibile in chiaro. Stando alle dichiarazioni su BreachForums, ShinyHunters ha ottenuto accesso al database Vercel e porzioni di codice sorgente.
L’elemento forse più preoccupante, però, è temporale. L’infezione è avvenuta a febbraio 2026, la disclosure pubblica il 19 aprile. Due mesi di finestra aperta. Hudson Rock aveva i dati della compromissione oltre un mese prima che Vercel lo sapesse. Un’intrusione basata su token OAuth non genera alert nei sistemi di monitoraggio tradizionali, non richiede password, bypassa l’MFA: da un punto di vista tecnico sembra accesso legittimo. E spesso lo rimane, nel silenzio dei log, finché qualcuno non mette in vendita i dati su un forum underground.
Il pattern più grande: la supply chain non è più fatta di codice
Il caso Vercel non è isolato. È parte di un pattern documentabile.
Negli ultimi 18 mesi, attacchi con dinamiche simili, ovvero la compromissione di un vendor di terze parti usato come trampolino verso l’obiettivo reale, hanno colpito Okta, Twilio, Cloudflare, Snowflake. Il denominatore comune non è una vulnerabilità tecnica specifica. È il modello di fiducia delegata su cui si reggono le integrazioni SaaS moderne.
In un’architettura cloud enterprise tipica, ogni applicazione SaaS ha accesso OAuth ad altre applicazioni. Slack è connesso a Google Drive. Notion è connesso a GitHub. Gli strumenti AI — Copilot, Cursor, Context.ai, decine di altri — sono connessi a Workspace, a repository, a sistemi di deployment. Ogni connessione è un token. Ogni token è una superficie di attacco.
Il Security Magazine ha sintetizzato bene il problema: “Gli strumenti AI vengono adottati in azienda alla velocità delle macchine. I framework di governance pensati per valutare quelle integrazioni girano alla velocità degli esseri umani.”
Questa asimmetria è il vero problema strutturale.
Cosa significa per chi gestisce AI in azienda
Il caso Vercel introduce una categoria di rischio che molti IT manager e CIO non hanno ancora formalizzato nei propri modelli: il rischio di integrazione degli strumenti AI.
Ogni strumento AI che entra in azienda e si connette a un account aziendale via OAuth produce effetti collaterali di sicurezza che persistono nel tempo, indipendentemente dall’utilizzo attivo dello strumento. Un’integrazione autorizzata sei mesi fa, da un dipendente che nel frattempo ha cambiato ruolo, su uno strumento che nel frattempo ha modificato i propri scopi di accesso, rimane attiva: invisibile, silenziosa, potenzialmente sfruttabile.
Alcune domande concrete che vale la pena portare nelle proprie organizzazioni:
Quante applicazioni OAuth sono attualmente connesse agli account Google Workspace o Microsoft 365 della tua azienda? La maggior parte degli IT manager non conosce questa cifra.
Hai una policy che definisce chi può autorizzare integrazioni OAuth e con quale livello di scoping? L’integrazione che ha compromesso Vercel aveva ricevuto “deployment-level Google Workspace OAuth scopes” : permessi ampi, concessi probabilmente senza una revisione formale.
Quando hai revocato l’ultima volta un token OAuth che non veniva più usato attivamente? La rotazione regolare dei token è passata dall’essere una best practice a una misura di sopravvivenza.
Le tue environment variables sono classificate in modo coerente con la loro criticità reale? Non la criticità percepita da chi le ha create sotto pressione, ma quella valutata rispetto al blast radius di una loro eventuale esposizione.
Hai un sistema che ti avvisa se le credenziali dei tuoi dipendenti compaiono in database di credential compromise? Hudson Rock aveva i dati dell’infezione un mese prima della disclosure.
L’attacco a Vercel non è cominciato in un data center. È cominciato sul laptop di qualcuno che cercava un modo per farmare automaticamente un gioco. Da lì, attraverso un infostealer, un token OAuth rubato, un sistema di classificazione dei segreti imperfetto e 22 mesi di finestra aperta, è arrivato a produrre uno dei breach più discussi del 2026.
La supply chain moderna è fatta di fiducia delegata. E la fiducia, senza governance, è semplicemente una vulnerabilità con un nome diverso.
Nella tua azienda, quanti strumenti AI hanno accesso ai sistemi core, e quando è stata l’ultima volta che qualcuno ha verificato se quella fiducia è ancora giustificata?
