La violazione di Vercel di aprile 2026 è un attacco alla supply chain in cui la compromissione di uno strumento AI di terze parti (Context.ai) ha fornito all'attaccante un token OAuth valido per accedere al Google Workspace di un dipendente di Vercel, il quale a sua volta ha permesso l'accesso ad ambienti interni e variabili d'ambiente non contrassegnate come sensibili.

Il perimetro di Vercel non è stato violato direttamente. Non c'è stata alcuna CVE sfruttata nelle loro API, nessun RCE, nessun bruteforce. Il punto di ingresso è stata un'estensione di Chrome installata da un dipendente, autorizzata tramite OAuth, con ampi permessi. Questo è il meccanismo che merita di essere compreso.

Indice

Cronologia degli eventi

Data Evento
Febbraio 2026 un dipendente di Context.ai viene infettato da Lumma Stealer. Vengono esfiltrate le credenziali di Google Workspace, Supabase, Datadog e Authkit.
Marzo 2026 Context.ai identifica e blocca l'accesso non autorizzato al proprio AWS. L'estensione Chrome di Context.ai viene rimossa silenziosamente dal Chrome Web Store da Google il 27 marzo.
Aprile 2026 (seconda settimana) l'attaccante utilizza i token OAuth di Context.ai compromessi per accedere al Google Workspace dell'account Vercel interessato.
19 aprile 2026 Vercel pubblica il suo primo bollettino di sicurezza, inclusi gli IOC dell'app OAuth.
20 aprile 2026 Vercel conferma che i pacchetti npm non sono stati compromessi. ShinyHunters rivendica la responsabilità e mette i dati in vendita per 2 milioni di dollari.
21 aprile 2026 Indagine in corso con Mandiant, GitHub, Microsoft, npm e Socket.

La catena di attacco

Tutto inizia con un dipendente di Context.ai che scarica uno script malevolo distribuito come un exploit per Roblox. Il file installa Lumma Stealer, che raccoglie silenziosamente credenziali del browser, token OAuth e file di configurazione dalla macchina infetta. Tra i dati esfiltrati figura l'account [email protected], con privilegi di accesso ai sistemi interni dell'azienda.

Con quelle credenziali, l'attaccante entra nell'ambiente AWS di Context.ai nel marzo 2026. Lì trova il database dei token OAuth raccolti dall'estensione Chrome: ogni utente che aveva installato lo strumento e effettuato l'accesso con Google aveva lasciato un refresh token valido nei propri sistemi. Uno di quei token appartiene a un dipendente di Vercel che aveva utilizzato il proprio account enterprise per registrarsi.

Il refresh token è sufficiente per ottenere un nuovo access token di Google senza conoscere la password e senza interagire con l'MFA. L'attaccante accede al Google Workspace di Vercel, identifica gli ambienti interni collegati all'account e legge le variabili d'ambiente non contrassegnate come sensibili. A quel punto, entrano in possesso di API key, token di database e chiavi di firma per un sottoinsieme di clienti Vercel.

Context.ai: dove è tutto iniziato

Context.ai è uno strumento di IA installato come estensione Chrome che si connette all'account Google dell'utente tramite OAuth. L'estensione (Chrome Extension ID: omddlmnhcofjbnbflmjginpjjblphbgk) aveva due concessioni OAuth attive: una per accedere al Google Workspace dell'utente (Gmail, Calendar, Docs) e una incorporata nell'estensione stessa per leggere i file di Google Drive, tramite l'app 110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com.

Jaime Blasco (CTO di Nudge Security) ha identificato che Google ha rimosso l'estensione dal Chrome Web Store il 27 marzo 2026, ben prima che la violazione di Vercel diventasse pubblica.

Context.ai ha confermato nel proprio bollettino di sicurezza che l'attaccante ha utilizzato un token OAuth compromesso per accedere al Google Workspace di Vercel. Vercel non è un cliente diretto di Context.ai, ma almeno un dipendente di Vercel aveva installato l'estensione utilizzando il proprio account enterprise e aveva concesso i permessi "Allow All". La configurazione OAuth interna di Vercel ha permesso a tale concessione di propagarsi all'interno del loro Google Workspace enterprise, rendendo un singolo dipendente il punto di ingresso per l'intera organizzazione.

Il ruolo di Lumma Stealer

Lumma Stealer è un infostealer malware-as-a-service (MaaS), venduto su forum underground dal 2022. Raccoglie credenziali salvate nel browser, cookie di sessione attivi, token OAuth e refresh token, crypto wallet e file corrispondenti a pattern specifici come .env, config.json e id_rsa. La distribuzione tramite script di gioco malevoli è una tecnica documentata: gli script vengono pubblicati come strumenti "auto-farm" o "executor" su Discord, GitHub e siti di gaming, e gli utenti li eseguiscono credendo di installare un cheat.

In questo caso specifico, Hudson Rock ha rilevato che la macchina del dipendente di Context.ai compromesso conteneva credenziali aziendali di Google Workspace, token di Supabase e Datadog, credenziali Authkit e l'account [email protected], che è stato probabilmente il vettore di escalation verso l'AWS di Context.ai, dove erano memorizzati i token OAuth dei loro utenti.

Come funziona l'escalation OAuth

Quando il dipendente di Vercel installa l'estensione di Context.ai e clicca su "Sign in with Google", Google mostra una schermata di consenso con i permessi richiesti. L'utente accetta, Google rilascia un access_token e un refresh_token, e Context.ai li salva nei propri sistemi AWS. Da quel momento in poi, Context.ai utilizza tali token per leggere la posta e il Drive dell'utente ogni volta che necessario.

Fin qui, questo è il comportamento normale di OAuth. Il problema sorge quando quei token finiscono nelle mani sbagliate.

Una volta all'interno dell'AWS di Context.ai, l'attaccante recupera il database dei token OAuth. Utilizzando il refresh_token del dipendente di Vercel, chiama il Google Token Endpoint e ottiene un nuovo access_token valido, senza conoscere la password e senza alcuna richiesta MFA. A quel punto, accede al Google Workspace di Vercel come se fosse l'utente legittimo, identifica gli ambienti interni collegati all'account e legge le variabili d'ambiente non contrassegnate come sensibili.

Il refresh token è permanente fino a quando non viene esplicitamente revocato. La disinstallazione dell'estensione non revoca l'autorizzazione: finché l'utente non rimuove l'accesso da myaccount.google.com/permissions, il token rimane valido ed esecutabile.

Perché i permessi "Allow All" sono pericolosi

Quando un'app OAuth richiede lo scope https://www.googleapis.com/auth/gmail.readonly, Google mostra chiaramente "Read your email messages". Quando invece utilizza scope aggregati come https://www.googleapis.com/auth/cloud-platform o combinazioni ampie, l'interfaccia di consenso può essere meno esplicita su ciò che viene concesso.

La policy di Google Workspace di un'azienda può limitare quali app OAuth di terze parti i dipendenti possono autorizzare. Se tale policy era assente o permissiva in Vercel, un singolo dipendente è stato in grado di concedere un accesso che normalmente richiederebbe l'approvazione di un amministratore di Google Workspace.

Cosa è stato compromesso in Vercel

Confermato

Variabili d'ambiente non contrassegnate come "sensibili" per un sottoinsieme limitato di clienti (API key, token di database, chiavi di firma, segreti webhook) sono state esposte. Vercel ha contattato direttamente i clienti interessati. È stata confermata anche la compromissione dell'accesso agli ambienti interni di Vercel, sebbene la sua natura esatta non sia stata divulgata.

Confermato non compromesso

Le variabili d'ambiente contrassegnate come "sensitive" sono memorizzate in un modo che le rende illeggibili, anche per gli ingegneri di Vercel, e non vi è alcuna prova di accesso. I pacchetti npm di Vercel, inclusi Next.js e Turbopack, sono stati verificati come integri in collaborazione con GitHub, Microsoft, npm e Socket.

Sotto indagine

L'intero perimetro dei dati esfiltrati, il numero esatto di clienti interessati e i sistemi interni raggiunti sono ancora oggetto di indagine. Vercel ha descritto l'attore della minaccia come "altamente sofisticato" sulla base della sua velocità operativa e della conoscenza dettagliata dei loro sistemi.

Una nota sulla dichiarazione di ShinyHunters: il gruppo ha affermato di aver rubato i dati e di venderli per 2 milioni di dollari. Tuttavia, Austin Larsen del Google Threat Intelligence Group (GTIG) ha osservato che si tratta probabilmente di un impersonatore che utilizza il nome di ShinyHunters per aumentare la propria notorietà.

Indicatori di compromissione (IOC)

App OAuth da controllare immediatamente

Vercel ha pubblicato due IOC relativi alle app OAuth di Context.ai. Gli amministratori di Google Workspace dovrebbero verificare se queste app sono autorizzate nel proprio tenant.

App OAuth principale di Context.ai:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

App OAuth incorporata nell'estensione Chrome (accesso in lettura a Google Drive):

110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq.apps.googleusercontent.com

Estensione Chrome rimossa dal Web Store:

Extension ID: omddlmnhcofjbnbflmjginpjjblphbgk

Come controllare nel proprio Google Workspace

Dalla Console di amministrazione: Security > API controls > App access control, cercando i Client ID elencati sopra.

Tramite il Google Admin SDK, è possibile automatizzare un audit degli eventi di autorizzazione OAuth:

from googleapiclient.discovery import build
from google.oauth2 import service_account

# requires a Service Account with domain-wide delegation
SCOPES = ['https://www.googleapis.com/auth/admin.reports.audit.readonly']

def check_oauth_app_usage(credentials_file, target_client_id, domain):
    creds = service_account.Credentials.from_service_account_file(
        credentials_file, scopes=SCOPES
    )
    service = build('admin', 'reports_v1', credentials=creds)

    results = service.activities().list(
        userKey='all',
        applicationName='token',
        eventName='authorize',
        filters=f'client_id=={target_client_id}'
    ).execute()

    activities = results.get('items', [])
    if activities:
        print(f"[!] App {target_client_id} authorized by:")
        for activity in activities:
            actor = activity.get('actor', {}).get('email', 'unknown')
            time = activity.get('id', {}).get('time', 'unknown')
            print(f"    - {actor} at {time}")
    else:
        print(f"[+] No authorization found for {target_client_id}")

IOC_MAIN = "110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj"
IOC_DRIVE = "110671459871-f3cq3okebd3jcg1lllmroqejdbka8cqq"

check_oauth_app_usage("service-account.json", IOC_MAIN, "yourdomain.com")
check_oauth_app_usage("service-account.json", IOC_DRIVE, "yourdomain.com")

Per un singolo account Google personale, è sufficiente andare su myaccount.google.com/permissions e controllare tutte le app con scope ampi, in particolare quelle con accesso a Gmail o Drive.

Raccomandazioni operative

Per gli utenti Vercel

Tutte le variabili d'ambiente non contrassegnate come "sensitive" devono essere considerate compromesse e ruotate immediatamente: chiavi API di servizi di terze parti, token di database, segreti JWT, segreti webhook. Eliminare il progetto o l'account Vercel non è sufficiente, poiché le credenziali esfiltrate rimangono valide sui sistemi di destinazione.

# check which env vars are not sensitive via Vercel CLI
vercel env ls --environment production

Dopo la rotazione, contrassegnare tutto come sensitive dalla dashboard (Settings > Environment Variables > edit > enable "Sensitive") o tramite CLI:

vercel env add MY_SECRET_KEY production
# the CLI asks whether to mark it as sensitive

Controllare il log delle attività per il periodo 15-21 aprile 2026 (dashboard > Team Settings > Activity Log) e verificare che non vi siano deployment insoliti. Assicurarsi che la Deployment Protection sia impostata almeno su "Standard" e ruotare i token correlati se configurati.

Per gli amministratori di Google Workspace

La misura strutturale consiste nel limitare quali app OAuth di terze parti i dipendenti possono autorizzare autonomamente. Dalla Console di amministrazione: Sicurezza > Controlli API > Controllo accessi alle app, imposta "Limita l'accesso ai servizi Google" su "Solo app attendibili" e crea una lista di app approvate.

Oltre ai due IOC pubblicati da Vercel, vale la pena auditare le app OAuth esistenti nel workspace, cercando quelle con scope per mail o Drive non giustificati dal loro caso d'uso, con un editore non verificato da Google, o installate da un numero molto esiguo di account (spesso solo un dipendente).

Per tutti gli sviluppatori

Utilizzate chiavi diverse per gli ambienti di sviluppo e di produzione. Se una chiave di sviluppo viene esfiltrata, la produzione rimane intatta. Sul vostro account personale Google o GitHub, revocate periodicamente le app OAuth che non utilizzate più, specialmente le estensioni del browser: esse mantengono l'accesso finché non vengono esplicitamente rimosse dal pannello dei permessi, anche dopo la disinstallazione.

Il pattern più ampio: OAuth come vettore laterale

Questa violazione non è un caso isolato. Jaime Blasco di Nudge Security ha documentato una serie di attacchi con la stessa struttura nell'ultimo anno: Salesloft Drift, Gainsight e ora Context.ai/Vercel. I nomi dei vendor cambiano, la dinamica rimane identica.

Gli strumenti SaaS e di IA di nuova generazione richiedono ampi permessi OAuth per funzionare (leggono mail, Drive, calendario), centralizzano questi token nei propri sistemi cloud e sono spesso startup giovani senza programmi di sicurezza maturi. Il risultato è che diventano un hub di accesso per decine o centinaia di organizzazioni aziendali. Dal punto di vista dell'attaccante, compromettere un vendor di questo tipo è molto più efficiente che attaccare ogni bersaglio individualmente: è la stessa logica che ha reso profittevoli gli attacchi alla supply chain del software (SolarWinds, 3CX, XZ Utils), applicata allo strato dell'identità.

Ciò che rende OAuth particolarmente insidioso come vettore è che i refresh token non scadono a meno che non vengano esplicitamente revocati, l'accesso basato su OAuth bypassa l'MFA senza richiedere la password dell'utente e i log mostrano accessi legittimi perché il consenso è stato concesso volontariamente. Non c'è nulla di anomalo da rilevare fino a quando è troppo tardi.

Come ha scritto Blasco: "OAuth è il nuovo movimento laterale. Finché il settore non tratterà i token OAuth come credenziali ad alto valore, continueremo a leggere lo stesso report di violazione con i nomi dei vendor cambiati."

Riferimenti

  1. Vercel security bulletin - April 2026
  2. The Hacker News - Vercel breach analysis
  3. Google - revoke OAuth app access
  4. Vercel docs - sensitive environment variables
  5. Vercel docs - activity log

Aggiornato al 21 aprile 2026. La situazione è in continua evoluzione: Vercel sta continuando a indagare sull'entità completa dell'esfiltrazione insieme a Mandiant.