Vercel ha conservato i Suoi segreti in chiaro e l'ha definita una funzionalità

Vercel ha subito una violazione. L'attaccante è rimasto all'interno per circa due mesi prima del rilevamento. Ha enumerato e decrittato le variabili d'ambiente dei clienti — chiavi API, password dei database, chiavi di firma, token — per ogni progetto che non utilizzava il flag facoltativo "sensitive" di Vercel.

La catena d'attacco: uno strumento AI di terze parti chiamato Context.ai è stato compromesso. L'attaccante ha usato quel punto d'appoggio per rilevare l'account Google Workspace di un dipendente Vercel. Da lì è passato ai sistemi interni di Vercel. Poi ha iniziato a leggere i segreti.

I dati risulterebbero ora in vendita su BreachForums per 2 milioni di dollari.

La casella "sensitive" che non era il valore predefinito

Ecco la parte che conta.

Vercel ha due tipi di variabili d'ambiente. Quelle ordinarie, che sono "encrypted at rest" ma che possono essere decrittate e lette dai sistemi di Vercel. E quelle "sensitive", che utilizzano una cifratura aggiuntiva che, secondo Vercel, impedisce persino l'accesso interno.

L'attaccante poteva leggere tutte quelle ordinarie. Solo le "sensitive" erano protette.

Il problema: "sensitive" era una scelta attiva. Non il valore predefinito. Ogni sviluppatore che ha impostato DATABASE_URL o STRIPE_SECRET_KEY o JWT_SIGNING_KEY senza spuntare una casella — e sono la maggior parte — aveva quei valori in un formato che un attaccante con accesso interno poteva decrittare.

Le indicazioni post-violazione di Vercel: "Abilitare la funzionalità delle variabili d'ambiente sensitive per la conservazione cifrata." Traduzione: la cifratura che Lei dava per scontata proteggesse i Suoi segreti in realtà non li proteggeva da noi, né da chiunque sia entrato nei nostri sistemi.

Due mesi di permanenza

Il compromissione iniziale è avvenuta a febbraio 2026. Vercel ha pubblicato il primo bollettino di sicurezza il 19 aprile. Sono circa due mesi in cui un attaccante ha avuto accesso ai sistemi interni.

Lo stesso team di sicurezza di Vercel ha descritto l'attaccante come "highly sophisticated based on their operational velocity and in-depth understanding of Vercel's product API surface". Quando l'azienda che ospita la Sua infrastruttura afferma che l'attaccante conosceva i suoi sistemi meglio del previsto, è il caso di fermarsi a riflettere.

In quei due mesi, l'attaccante ha avuto il tempo di enumerare ogni variabile d'ambiente accessibile nei progetti dei clienti coinvolti. Il tempo di esfiltrare. Il tempo di vendere.

La supply chain OAuth

Il punto d'ingresso non era nemmeno il codice di Vercel. Un dipendente Vercel aveva autorizzato Context.ai — uno strumento di produttività AI — tramite Google OAuth. Quando Context.ai è stato compromesso, l'attaccante ha ereditato ogni permesso concesso da quell'autorizzazione OAuth.

È uno schema che continua a ripetersi. Le organizzazioni mettono con cura in sicurezza l'autenticazione primaria, poi distribuiscono token OAuth a strumenti di terze parti che hanno una postura di sicurezza propria, spesso più debole. Una sola app compromessa nella catena e l'attaccante eredita l'accesso del Suo dipendente.

L'ID dell'OAuth App compromessa è pubblico: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Se la Sua organizzazione ha autorizzato questa app, la revochi immediatamente.

Cosa fare

Se distribuisce su Vercel:

• Ruoti immediatamente ogni variabile d'ambiente — non attenda di stabilire se fosse "interessato"
• Attivi il flag sensitive su tutte le variabili d'ambiente d'ora in poi
• Verifichi i permessi delle app OAuth su Google Workspace e revochi tutto ciò che non usa attivamente
• Esamini i log di deployment di Vercel alla ricerca di modifiche inattese nel periodo febbraio-aprile 2026
• Controlli i servizi a valle (database, processori di pagamento, API) per eventuali accessi non autorizzati con le credenziali conservate in Vercel

La vera lezione

L'architettura di Vercel conservava i segreti dei clienti in un formato che l'accesso interno poteva decrittare. Offriva un'opzione più forte, ma non l'ha resa il valore predefinito. Per due mesi nessuno ha notato un attaccante che leggeva quei segreti.

Questo è il problema della sicurezza del tipo "si fidino di noi". Vercel cifrava le Sue variabili d'ambiente a riposo — è tecnicamente vero. Ma deteneva le chiavi di decrittazione. Quando i suoi sistemi sono stati compromessi, lo sono stati anche i Suoi segreti.

L'alternativa è l'architettura a conoscenza zero, in cui il fornitore del servizio matematicamente non può decrittare i Suoi dati. Non "sceglie di non farlo" — non può. Nessuna compromissione interna, nessun dipendente disonesto, nessun attaccante sofisticato che permane nella Sua infrastruttura per due mesi può leggere ciò per cui il server non ha mai posseduto le chiavi di decrittazione.

Vercel chiede ai clienti di spuntare una casella per accedere alla cifratura reale. La domanda che vale la porsi: perché non è stata fin dall'inizio l'unica opzione?