Ruotare, ridistribuire, revocare: la nostra risposta all'incidente Vercel

Il 19 aprile 2026, Vercel ha comunicato un incidente di sicurezza riconducibile a un'applicazione OAuth di terze parti compromessa all'interno del proprio Google Workspace. Abbiamo eseguito la risposta su ogni progetto Vercel gestito da webvise prima della fine del weekend, e i log di audit sia su Vercel sia sui Google Workspace che amministriamo sono risultati puliti. Non si è trattato di una vulnerabilità nel codice proprio di Vercel. È stata una compromissione della supply chain SaaS-to-SaaS attraverso un confine di fiducia OAuth, e la sua forma cambia l'aspetto di una risposta adeguata.

Ruotare i segreti nella dashboard di Vercel costituisce forse la metà della risposta. L'altra metà risiede in Google Workspace, e la maggior parte degli articoli pubblicati non la tratta.

Ha letto la comunicazione e ha aggiornato ogni chiave che riusciva a trovare. Questa è la prima mossa giusta. Questo articolo illustra ciò che abbiamo eseguito concretamente dall'inizio alla fine, il dettaglio tecnico che rende la rotazione efficace anche sulle funzioni in esecuzione, e perché la forma di questa compromissione cambia il modo in cui il piano di risposta dovrebbe essere strutturato la prossima volta.

• La rotazione delle env var di Vercel modifica la dashboard, non le funzioni in esecuzione. I valori entrano in vigore solo al deploy successivo.

• L'audit OAuth di Google Workspace è la metà della risposta di cui quasi nessuno parla. È il percorso di fiducia che l'attaccante ha utilizzato per raggiungere Vercel.

• Non si è trattato di una vulnerabilità di Vercel. È stata una compromissione SaaS-to-SaaS tramite un grant OAuth, e una risposta classica in stile CVE non chiude il cerchio.

• Nel lungo periodo, spostare i segreti fuori dalle env var e in un gestore di segreti a runtime. Richiedere MFA anti-phishing su chiunque possa installare applicazioni OAuth.

• Audit mensili dei grant OAuth di terze parti nel proprio identity provider sono ora parte della baseline, non un aggiornamento di maturità opzionale.

Cosa ha comunicato Vercel

In sintesi: un'applicazione SaaS di terze parti con accesso OAuth all'interno del Google Workspace di Vercel è stata compromessa, e l'attaccante ha sfruttato quel confine di fiducia per raggiungere i valori delle variabili d'ambiente su un sottoinsieme di progetti clienti. Vercel ha pubblicato un OAuth client ID come indicatore di compromissione e ha chiesto a ogni cliente di ruotare qualsiasi segreto memorizzato come variabile d'ambiente. Nulla di tutto ciò ha coinvolto una vulnerabilità nel codice proprio di Vercel. La superficie d'attacco era il grafo di fiducia dell'identità tra due strumenti SaaS.

Questo è rilevante per il modo in cui si risponde. Se la vulnerabilità è nel codice della piattaforma, si applica una patch, si ruota ciò che è trapelato e si va avanti. Se la vulnerabilità è nel percorso di fiducia tra piattaforme, la rotazione è necessaria ma non chiude il varco. Occorre anche revocare il grant su cui l'attaccante si è mosso, altrimenti la prossima compromissione dello stesso strumento replica lo stesso raggio d'impatto.

Se desidera un secondo sguardo sulla configurazione Vercel prima che il post-mortem del prossimo weekend venga scritto sulla Sua azienda, eseguiamo security review su team Vercel, Google Workspace e grant SaaS-to-SaaS.

Fase uno: ruotare i segreti che contano davvero

Abbiamo trattato ogni variabile d'ambiente in grado di concedere accesso a qualsiasi risorsa come compromessa per default. Questa è l'assunzione che la comunicazione richiede. Di seguito sono riportate le categorie di segreti che abbiamo riemesso sui progetti gestiti.

• Credenziali di database. Stringhe di connessione, password delle repliche di sola lettura e chiavi di ruolo admin su ogni progetto con un backend database.

• Chiavi API Resend per l'email transazionale su ogni progetto che invia messaggi di verifica, notifica o registrazione.

• Credenziali Google API per le integrazioni con Workspace, Calendar, Drive e Analytics che operano lato server.

• Chiavi AI Gateway inclusi token di accesso ai modelli, credenziali dei provider e token di rate-limit per tutto ciò che transita attraverso il gateway.

• Credenziali di integrazione per l'ingest per endpoint webhook, pipeline di eventi e qualsiasi sistema che inserisce dati nel progetto dall'esterno.

Due categorie che vale la pena verificare con attenzione: variabili che terminano con `_URL` e che incorporano credenziali nelle stringhe di connessione, e qualsiasi variabile etichettata `_TEST` o `_DEV` che punta a produzione. Ruotare anche queste insieme alle altre. Un attaccante che legge le env var non si cura del flag scelto né di ciò che il nome della variabile suggerisce.

Fase due: ridistribuire (il dettaglio tecnico che rende reale la rotazione)

Questo è l'aspetto più importante e quello che riceve meno attenzione. Vercel applica le modifiche alle variabili d'ambiente al momento del build e del deploy, non a runtime. Un progetto aggiornato e lasciato invariato sta ancora eseguendo il build distribuito il giorno prima, che contiene ancora il vecchio segreto incorporato nel suo runtime. Ha ruotato la dashboard, non il sistema.

Esempio concreto: si ruota la chiave API Resend alle 10:14 e si apre una nuova scheda per verificare qualcos'altro. Una funzione tenta di inviare un'email di verifica alle 10:17, chiama Resend con la vecchia chiave ancora incorporata nel deploy attivo, e Resend rifiuta la richiesta. L'utente non riceve la sua email. Si moltiplichi questo per ogni funzione, ogni cron job e ogni webhook handler in esecuzione sul build precedente.

Per verificare la risposta, si apra la scheda Deployments su ogni progetto e si individui un deploy con timestamp successivo alla rotazione. Se la riga in cima mostra un timestamp precedente alla rotazione, la rotazione non è entrata in alcun processo in esecuzione. Il secondo passaggio esplicito della nostra risposta è stato un redeploy forzato in produzione su ogni progetto gestito dopo la rotazione, prima di procedere.

Fase tre: revocare il grant OAuth di Google Workspace

Questa è la metà della risposta che è quasi assente nei thread del weekend. L'incidente ha avuto origine in Google Workspace. L'attaccante è entrato tramite un'applicazione OAuth di terze parti con uno scope concesso all'interno di Workspace, per poi spostarsi su Vercel attraverso un percorso di fiducia SaaS-to-SaaS. Se si è ruotato solo dal lato Vercel, la stessa applicazione OAuth è ancora lì con lo stesso scope, pronta a essere sfruttata la prossima volta che viene compromessa.

Il percorso nella console di amministrazione: admin.google.com, sicurezza, controlli API, controllo accesso app, app di terze parti. Cercare l'OAuth client ID pubblicato da Vercel come indicatore. Revocarlo se presente. Poi fare la cosa più difficile: esaminare ogni altro grant OAuth nell'elenco, confermare che ogni scope fosse intenzionale e revocare tutto ciò per cui non esiste una ragione attiva.

Abbiamo eseguito questo audit su ogni Workspace che amministriamo. L'indicatore non era presente, e la maggior parte dei grant aveva uno scopo aziendale legittimo. Una manciata no, e li abbiamo revocati. Da allora abbiamo adottato una cadenza mensile: audit dei grant OAuth all'inizio di ogni mese, revoca di tutto ciò che non è stato utilizzato nei 30 giorni precedenti.

Fase quattro: le azioni a lungo termine

La rotazione e la revoca hanno gestito l'esposizione immediata. Le azioni a lungo termine sono ciò che impedisce al prossimo incidente di diventare una corsa contro il tempo nel weekend. Stiamo implementando queste misure sui progetti gestiti nelle prossime settimane, e le raccomandiamo a qualsiasi team che operi con uno stack SaaS intensivo.

• Recuperare i segreti a runtime da un gestore di segreti invece di incorporarli nelle env var. La rotazione diventa un aggiornamento push, non un redeploy.

• Credenziali a breve durata per database e API ovunque il provider le supporti. Validità di minuti, non di mesi.

• Rotazione pianificata per le credenziali che non possono essere rese a breve durata. Guidata dal calendario, non dagli incidenti.

• MFA anti-phishing su ogni account admin che può installare applicazioni OAuth nel proprio identity provider. Passkeys o token hardware, nulla basato su SMS.

• Audit mensili dei grant OAuth in Workspace, Microsoft 365 o qualsiasi identity provider in uso. Il percorso dell'attaccante questa volta era un grant OAuth; lo sarà anche la prossima.

La maggior parte dei team non ha un singolo responsabile per nessuna di queste misure. Questa è la ragione silenziosa per cui gli incidenti continuano a concludersi con gli stessi punti nel post-mortem. Parli con noi su come webvise integra queste misure nel retainer di manutenzione per ogni progetto gestito.

Perché questa compromissione è diversa

Il modello di compromissione per cui la maggior parte dei programmi di sicurezza è costruita: un attaccante trova un CVE in un server che si gestisce, lo sfrutta e scarica i dati. Rotazione, patch e monitoraggio perimetrale coprono quel modello. L'incidente del 19 aprile 2026 ha una forma diversa.

Un attaccante compromette uno strumento SaaS autorizzato dal team, poi si muove sfruttando la relazione di fiducia tra quello strumento e gli altri strumenti SaaS per raggiungere dati che nessuno dei due avrebbe fornito a un estraneo. L'account Vercel non è stato violato, e nemmeno il Google Workspace. Uno strumento terzo connesso mesi fa è stato compromesso, e gli scope concessi a quello strumento hanno propagato la compromissione a valle.

Il modello difensivo deve corrispondere al modello d'attacco. Questo significa trattare i grant OAuth come dipendenze di produzione, verificarli con una cadenza pianificata e spostare i segreti fuori dalle variabili d'ambiente, dove un attaccante con quel grant può leggerli. I nostri log di audit sono risultati puliti questo weekend, ma questo è il risultato per questo specifico incidente, non la prova che il modello di risposta sia a prova di futuro.

Eseguiamo security review su team Vercel, Google Workspace e grafi di identità SaaS-to-SaaS come parte di ogni engagement gestito da webvise. Se desidera uno sguardo esterno sulla Sua configurazione prima che la prossima comunicazione arrivi nel weekend, avvii una conversazione.