Guida alla risposta all'incidente Vercel aprile 2026
Ultimo aggiornamento: 20 aprile 2026 @ 12:07 AEST/Brisbane - (v2 — include l'aggiornamento del CEO di Vercel del 20 aprile)
Cosa è successo?
Vercel ha comunicato il 19 aprile 2026 che un aggressore ha ottenuto accesso non autorizzato a sistemi interni. Ecco l'annuncio ufficiale:
Il 20 aprile, l'amministratore delegato di Vercel Guillermo Rauch ha pubblicato un aggiornamento dettagliato confermando il percorso di accesso iniziale: un dipendente Vercel ha utilizzato una piattaforma AI chiamata Context.ai, che a sua volta è stata violata; da lì l'aggressore si è spostato nell'account Google Workspace del dipendente e ha escalation negli ambienti Vercel. Le variabili d'ambiente sono crittografate a riposo, ma l'aggressore è stato in grado di enumerare le variabili non contrassegnate come "sensibili". Vercel caratterizza l'aggressore come altamente sofisticato e probabilmente accelerato dall'AI. Google Mandiant è coinvolto nella risposta. Vercel afferma che Next.js, Turbopack e i loro progetti open source rimangono sicuri.
Ecco la sezione importante sugli indicatori di compromesso di quell'avviso di sicurezza:
Piuttosto scarsi di dettagli. Non dicono nemmeno dove controllare per quell'unico IOC di Google. Come cliente Vercel, sono piuttosto deluso da questo livello di dettaglio. Aiutami a capire cosa cercare! Dimmi dove andare per scoprire se sono stato compromesso o no!
In assenza di dettagli da Vercel, abbiamo creato questo documento
Se esegui carichi di lavoro su Vercel, presupponi quanto segue fino a prova contraria:
- Le variabili d'ambiente non contrassegnate come "sensibili" su qualsiasi progetto Vercel nella finestra di esposizione potrebbero essere state leggibili.
- Qualsiasi credenziale inviata a Vercel tramite la dashboard o
vercel env CLI che non viene ruotata è una responsabilità permanente.
- I token all'interno dei percorsi di integrazione Vercel ↔ GitHub e Vercel ↔ Linear potrebbero essere stati accessibili.
- Non riceverai un segnale chiaro "sei colpito / non sei colpito" rapidamente. Prima ruota, poi indaga.
Noto vs. rivendicato: tieni separati questi aspetti nei tuoi briefing
Questa distinzione è importante per le comunicazioni esecutive e per non reagire in modo eccessivo (o insufficiente).
Confermato da Vercel (bollettino + aggiornamento del CEO del 20 aprile)
- Accesso non autorizzato a determinati sistemi interni di Vercel.
- Vettore di accesso iniziale: Context.ai, una piattaforma AI utilizzata da un dipendente Vercel, è stata violata. L'aggressore ha utilizzato quel punto d'appoggio per compromettere l'account Google Workspace Vercel del dipendente, poi ha escalation da lì negli ambienti Vercel.
- Le variabili d'ambiente dei clienti sono crittografate a riposo. Le variabili designate come "non sensibili" erano comunque enumerabili dall'aggressore una volta all'interno.
- L'impatto sui clienti è caratterizzato come "abbastanza limitato"; Vercel ha contattato direttamente i clienti per cui ha preoccupazioni.
- Next.js, Turbopack e i progetti open source di Vercel sono stati analizzati e si ritiene siano rimasti sicuri (cioè nessun artefatto malevolo nel percorso di rilascio di quei progetti al 20 aprile).
- L'aggressore è caratterizzato come altamente sofisticato e probabilmente significativamente accelerato dall'AI.
- Partner di risposta: Google Mandiant è attivamente coinvolto; società IR esterne, colleghi del settore e forze dell'ordine coinvolte.
- Vercel ha contattato Context.ai per aiutare a comprendere l'intero ambito.
- Vercel ha rilasciato miglioramenti dell'interfaccia utente: pagina di panoramica delle variabili d'ambiente, gestione migliorata delle variabili d'ambiente sensibili.
Riportato / attribuito da terze parti e dall'aggressore (non confermato da Vercel)
- Integrazioni Linear e GitHub colpite in modo sproporzionato (segnalazioni della community, in particolare Theo Browne su X).
- Dati elencati in vendita su BreachForums: DB interno, account dei dipendenti, token GitHub, token npm, frammenti di codice sorgente, timestamp delle attività — offerti a ~$2M.
- L'attore si identifica come ShinyHunters; altri attori storicamente collegati a quel soprannome hanno negato il coinvolgimento.
- Classi specifiche di dati dei clienti esfiltrati oltre quanto Vercel ha confermato direttamente con i clienti.
Tratta le segnalazioni non confermate come plausibili e utilizzabili per la tua triage, ma non citarle come fatti nelle comunicazioni con clienti o autorità di regolamentazione fino a quando Vercel non le corrobora o hai prove indipendenti. Il divario tra "variabili d'ambiente enumerabili" (confermato da Rauch) e "token npm + GitHub in vendita su BreachForums" (rivendicazione dell'aggressore) è il divario che conta di più per il rischio della supply chain — presupponi il peggio per la rotazione, attieniti alla versione confermata per le comunicazioni.
Scoping: chi deve eseguire questo playbook
Urgenza massima — hai ricevuto un contatto diretto da Vercel, oppure si applica una delle seguenti condizioni:
- Hai (o hai avuto) un'integrazione Vercel ↔ GitHub con ambito di scrittura sul repository.
- Hai (o hai avuto) un'integrazione Vercel ↔ Linear.
- Memorizzi segreti non crittografati (non contrassegnati come sensibili) come variabili d'ambiente Vercel.
- Pubbliche pacchetti npm da CI/CD che viene eseguito su o attraverso l'infrastruttura Vercel.
Urgenza standard — qualsiasi team con progetti Vercel attivi, anche siti di marketing. I siti di marketing spesso contengono chiavi API CMS, token di analytics e webhook di gestione dei moduli che portano a sistemi più sensibili.
Fallo comunque — anche se i tuoi progetti sono stati eliminati prima dell'incidente. La domanda è se i segreti siano mai stati residenti in Vercel in una forma leggibile, non se il progetto sia ancora lì.
Domanda parallela: la tua organizzazione è esposta direttamente a Context.ai?
L'aggiornamento del 20 aprile nomina Context.ai come il fornitore a monte violato. Se qualcuno nella tua organizzazione utilizza Context.ai indipendentemente da Vercel — per intelligence delle riunioni, gestione della conoscenza, arricchimento CRM o qualsiasi altro flusso di lavoro — potresti avere la tua finestra di esposizione diretta separata dall'incidente Vercel.
Esegui questi controlli in parallelo:
- Interroga il tuo SSO / IdP (Okta, Entra, Google Workspace) per qualsiasi utente che abbia autenticato a Context.ai o a un'app OAuth correlata a Context.
- Cerca nella console di amministrazione di Google Workspace → Sicurezza → Registri di accesso alle app OAuth per
context.ai o ID app associati.
- Controlla gli strumenti di gestione delle spese aziendali / SaaS spend per abbonamenti Context.ai.
- Rivedi quali ambiti OAuth sono stati concessi — lettura Gmail, Calendar, Drive e ambiti della directory Workspace sono ad alto impatto.
Se trovi l'uso di Context.ai nel tuo ambiente, revoca le concessioni OAuth, ruota tutte le credenziali che sono passate attraverso i flussi di lavoro Context.ai e monitora gli account Google Workspace degli utenti interessati per gli stessi indicatori di compromesso che Vercel descrive di aver visto sull'account del loro dipendente. Contatta direttamente Context.ai per i tuoi dettagli sull'incidente; Vercel ha dichiarato pubblicamente di essere in coordinamento con Context per aiutare altre organizzazioni colpite.
Fase 0: Fermare l'emorragia (primi 60 minuti)
Due obiettivi: prevenire nuovi danni, preservare le prove.
-
Blocca i deploy. Metti in pausa gli auto-deploy sui branch di produzione. Vuoi impedire che venga distribuito un build modificato dall'aggressore e vuoi fermare il turnover del registro di audit.
-
Disabilita l'app GitHub di Vercel. Se hai installato l'app GitHub di Vercel, cosa che avrai se stai facendo deploy automatici su Vercel quando invii nuovo codice su GitHub. Puoi trovare le tue app GitHub installate su https://github.com/organizations/<GitHub-Organization>/settings/installations
-
Identifica l'accesso che ha l'app GitHub. Clicca il pulsante di configurazione sopra e controlla a quali repository aveva accesso l'app Vercel. Questo ti dice su cosa concentrarti subito. Vai su GitHub → Organizzazione → Impostazioni → App GitHub → Vercel. Rivedi:
- Accesso ai repository (tutti i repo vs. selezionati)
- Permessi concessi
- Data di installazione e chi l'ha installata
- Fai uno snapshot del registro di audit Vercel per il tuo team. Esportalo o catturalo immediatamente. La finestra di conservazione è limitata e l'interfaccia utente non espone tutto. Ottienilo prima di iniziare a fare modifiche che inquinerebbero il registro. Puoi trovarlo su https://vercel.com/activity-log
- Attiva "Observability Plus". Questa è una funzionalità aggiuntiva a pagamento di Vercel, ed è un peccato doverti suggerire di attivarla e PAGARE per essa, ma in questo caso penso sia la cosa migliore da fare durante l'incident response. Non ne sono affatto felice, ma l'ho attivato semplicemente perché conserva i registri di audit più a lungo rispetto al default che è MOLTO breve.
- Inventaria l'ampiezza dell'esposizione. Per ogni team/account Vercel che controlli, elenca:
- Progetti e i loro repository Git collegati
- Integrazioni collegate (App GitHub, Linear, Slack, integrazioni marketplace)
- Membri del team e i loro ruoli
- Token di accesso personale / token API emessi sotto il team
- Deploy hooks
- Rivedi il registro di audit dell'organizzazione GitHub. Cerca ****la finestra di esposizione (in modo conservativo, 1–15 aprile 2026 fino ad oggi). Filtra per:
repo.add_member, repo.add_topicorg.invite_member, org.add_memberintegration_installation, integration_installation.repositories_addedprotected_branch.destroy,
Non fare ancora annunci o ruotare segreti. Prima vuoi lo snapshot.
Fase 1: Verifica degli indicatori di compromesso (IOC)
I dettagli dell'annuncio di Vercel sono piuttosto scarni:
Per quanto possiamo capire, suggeriscono di andare alla console di amministrazione di Google Workspace e cercare questa app googleusercontent.com. Ecco come trovarla nella console:
-
Nella console di amministrazione di Workspace vai su Sicurezza > Accesso e controllo dati > Controlli API e trova le app a cui è stato concesso o in attesa di accesso.
-
Poi cerca nei diversi elenchi lo IOC che a quanto pare è un'app OAuth: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
-
Se la trovi, rimuovila immediatamente e consulta un partner di incident response. Questo è al di sopra del mio livello retributivo.
Fase 2: Rotazione delle credenziali
La rotazione è l'azione singola di maggior valore. Eseguila in ordine di priorità in modo che, se vieni interrotto, le cose più pericolose siano state gestite.
Cosa devi ruotare dipende da cosa i tuoi ambienti GitHub e Vercel hanno esposto. Inizia con i PAT di GitHub, ecc. e procedi verso l'esterno usando questa guida.
Livelli di priorità
Livello 0 — Ruota oggi, prima di ogni altra cosa:
- Ruota immediatamente tutti i PAT di GitHub e termina tutte le sessioni esistenti. Personal Access Tokens, o PAT. Esistono due tipi di PAT:
- Ruota immediatamente tutte le variabili d'ambiente Vercel che sono sensibili: http://vercel.com/all-env-vars
Livello 1 — Ruota oggi, a seconda di cosa hai esposto nelle tue app:
- Chiavi segrete del processore di pagamento (Stripe, Adyen, Braintree, ecc.)
- Segreti di firma dell'autenticazione (NextAuth
AUTH_SECRET / NEXTAUTH_SECRET, chiavi di firma JWT, chiavi dei cookie di sessione, token CSRF)
- Stringhe di connessione al database con accesso in scrittura (
DATABASE_URL, URL diretti Postgres/MySQL, URI Mongo, Redis con autenticazione)
- Chiavi del provider cloud con ambito ampio o root (chiavi di accesso IAM AWS, JSON dell'account di servizio GCP, segreti client Azure)
- Segreti di firma del webhook (Stripe, GitHub, Slack — ruota e aggiorna la configurazione del mittente)
Livello 2 — Ruota questa settimana:
- Chiavi API SaaS di terze parti (analytics, provider email, SMS, CRM)
- Segreti client OAuth per app di tua proprietà
- Credenziali SMTP
- Chiavi di crittografia per la crittografia a livello applicativo (ruota con incremento della versione della chiave, non con sostituzione diretta)
- Chiavi di pulizia CDN, chiavi del servizio immagini
- Chiavi del provider di feature flag
Livello 3 — Ruota quando è comodo, ma ruota comunque:
- Token di analytics di sola lettura
- DSN Sentry / logging (nota: la rotazione del DSN non è critica se ti va bene una piccola finestra di eventi persi)
- Chiavi pubbliche e chiavi anonime (ruota comunque — possono rivelare l'esistenza del progetto e talvolta consentire l'enumerazione)
Insidie nell'ordine delle operazioni
- Le chiavi di firma delle sessioni invalidano tutte le sessioni attive al momento della rotazione. Pianifica un evento di logout forzato. Comunicalo.
- I segreti del webhook devono essere ruotati da entrambe le parti. Prima aggiorna il mittente (Stripe, GitHub) per inviare con il nuovo segreto, poi il tuo ricevitore per verificarlo. Oppure supporta entrambi temporaneamente.
- Credenziali del database — prima crea il nuovo utente, distribuisci, poi revoca il vecchio. Non sostituire direttamente o causerai un'interruzione del servizio.
- Chiavi AWS — se stai ruotando le chiavi di accesso di un utente IAM, crea la seconda chiave, esegui il roll delle distribuzioni, poi elimina la prima. Non
disattivare e sperare.
- Ridistribuisci dopo le modifiche alle variabili d'ambiente. Le variabili d'ambiente Vercel sono incorporate al momento del build per molte configurazioni del framework. Una modifica alle variabili d'ambiente senza un nuovo deploy non viene applicata completamente.
- Controlla anche i segreti CI. Se un segreto è stato rispecchiato in GitHub Actions, CircleCI o simili, ruota il mirror.
Non dimenticare queste omissioni comuni
.env.local committato in un repository privato (è comunque un problema — il codice sorgente potrebbe essere stato esfiltrato)- Segreti negli ambienti di anteprima/sviluppo di Vercel, non solo produzione
- Segreti memorizzati come variabili d'ambiente condivise "a livello di team" di Vercel
- Deploy hooks (ruotali; sono trigger di deploy completi)
- Token di accesso personale Vercel emessi sotto il tuo account
- Token di accesso personale GitHub che hanno autorizzato l'installazione dell'app GitHub Vercel (separati dall'app stessa)
Fase 3: Caccia a livello di repository
Per i repository che erano collegati a Vercel:
- Confronta
main/master HEAD con il tag/commit che sai essere pulito prima della finestra dell'incidente.
- Cerca modifiche a:
package.json → scripts (soprattutto postinstall, prepare, preinstall)package-lock.json / pnpm-lock.yaml / yarn.lock — aggiunte di dipendenze inaspettate o aggiornamenti di versione.github/workflows/*.yml — nuovi workflow, nuovi passaggi run:, nuovi uses: con SHA non fissativercel.json — modifiche al comando di build, nuovi rewrites/redirect che potrebbero esfiltrare traffico
Se pubblichi pacchetti npm da questi repository
Qui è dove una compromissione iniziale di Vercel potrebbe diventare un evento della supply chain. Anche se non usi Vercel per pubblicare, se un aggressore ha ottenuto il tuo token GitHub e il tuo workflow di pubblicazione usa quel token:
- Controlla la cronologia di pubblicazione
npm: npm view <pkg> time --json per versioni inaspettate.
- Confronta il tarball di ogni versione recente con il tag git da cui afferma di provenire. Gli aggressori pubblicano da un tag che non corrisponde a ciò che è nel registro.
- Controlla l'uso di
NPM_TOKEN nei workflow — ruota il token, rivedi chi aveva accesso.
- Verifica l'aggiunta di nuovi manutentori ai tuoi pacchetti:
npm owner ls <pkg>.
- Se mantieni qualcosa di significativo, controlla l'esecuzione degli script post-install nel tarball — decomprimilo e ispezionalo.
Se trovi prove di una pubblicazione non autorizzata, segnalalo a npm security ([email protected]) e considera di archiviarlo su OSV.dev. Depreca la versione dannosa; non rimuoverla (la rimozione è limitata nel tempo e rompe i consumatori a valle).
Nota sui pacchetti di proprietà Vercel in particolare: L'aggiornamento del 20 aprile di Vercel afferma che Next.js, Turbopack e i loro progetti open source sono stati analizzati e si ritiene siano sicuri. Questa è l'affermazione di Vercel sul loro percorso di rilascio — dovresti comunque controllare i tuoi pacchetti come sopra. Se consumi Next.js o Turbopack, non hai bisogno di fissarti a una versione pre-incidente come precauzione basata sulle informazioni attuali, ma monitora il bollettino Vercel per eventuali cambiamenti in questa posizione.
Fase 4: Revisione dell'integrazione Linear
Se il tuo team utilizza l'integrazione Vercel ↔ Linear:
- Rivedi il registro di audit di Linear (Impostazioni workspace → Sicurezza → Registro di audit) per la finestra di esposizione.
- Cerca:
- Nuove chiavi API emesse
- Nuove integrazioni aggiunte
- Commenti pubblicati da account di servizio
- Modifiche alle destinazioni dei webhook
- Inviti di membri
- Visualizzazioni/esportazioni di dati sugli issue (l'integrazione ha accesso in lettura agli issue, che spesso contengono nomi di clienti, dettagli di bug e talvolta credenziali incollate nei ticket)
- Preoccupazione specifica: Gli issue di Linear contengono frequentemente segreti incollati dal debug degli sviluppatori. Cerca nel tuo workspace Linear i pattern di perdita comuni (
AKIA, sk_live_, ghp_, ghs_, npm_, eyJ, ----BEGIN). Tutto ciò che viene trovato deve essere ruotato.
Fase 5: Revisione dei log dei sistemi downstream
La rotazione delle credenziali invalida la persistenza dell'aggressore nella maggior parte dei casi, ma potrebbero già aver utilizzato l'accesso. Controlla i consumatori dei tuoi segreti ruotati per segni di utilizzo durante la finestra di esposizione.
Finestre da controllare
Utilizza 1 aprile 2026 fino ad oggi come limite inferiore conservativo. L'incidente è stato divulgato il 19 aprile ma l'accesso iniziale precede la divulgazione. Se Vercel pubblica una data più specifica, restringeremo questo intervallo di conseguenza.
Cosa interrogare
- AWS CloudTrail — chiamate API insolite da chiavi IAM compromesse, specialmente raffiche di
GetObject contro bucket S3, CreateUser, AttachUserPolicy, accessi alla console da nuovi ASN/paesi.
- Log di audit del database —
SELECT * insolito su tabelle sensibili, grandi esportazioni, connessioni da indirizzi IP di origine inaspettati.
- Log di pagamento Stripe — creazione di clienti insolita, creazione di trasferimenti, creazione di chiavi API.
- Log del provider di autenticazione (Auth0, Clerk, Cognito, Firebase) — accessi impossibili dal punto di vista dei viaggi, reimpostazioni di password attivate per utenti amministratori, nuove registrazioni di applicazioni.
- Provider email (SendGrid, Postmark, ecc.) — campagne in uscita inaspettate, nuove chiavi API, modifiche all'identità del mittente.
- GitHub — cloni, creazioni di fork, nuove chiavi SSH su account utente con accesso al repository.
Primitivi utili per la caccia agli IOC
Incolla eventuali hostname o IP controllati dall'aggressore pubblicati da Vercel o dai partner IR in:
- Log di accesso HTTP per il tuo frontend (gli aggressori a volte pre-eseguono sonde per confermare l'accesso prima di agire).
- Log DNS — risoluzione in uscita di domini insoliti dai tuoi server.
- Log del proxy in uscita / flussi VPC.
Al momento della pubblicazione, nessun IOC è stato rilasciato da Vercel. Monitora il bollettino Vercel e gli articoli di società IR ben note per aggiornamenti.
Fase 6: Rilevamento per compromissione persistente
La persistenza dell'aggressore dopo una violazione a livello di piattaforma assume comunemente queste forme. Cerca attivamente ciascuna:1. Nuovi membri del team o collaboratori nel tuo team Vercel, GitHub Org, workspace Linear o account cloud. Datati entro la finestra di esposizione.
2. Nuove autorizzazioni OAuth sui provider SSO collegati (Google Workspace, Okta, Entra ID) per gli account dei tuoi sviluppatori.
3. Configurazione CI/CD modificata — workflow che ora fanno telefonare a casa, nuovi runner self-hosted, nuovi segreti con nomi innocui.
4. Deploy imprevisti in Vercel — controlla la cronologia dei deploy per deploy che non puoi ricondurre a un commit noto di un autore noto.
5. Indicatori di reverse shell nei log delle funzioni serverless — blob base64 scritti/eseguiti, connessioni in uscita inusuali dalle Edge/Serverless Functions.
6. DNS drift — nuovi sottodomini, modifiche CNAME, redirect aggiunti tramite vercel.json o configurazione del framework.
7. Modifiche all'autenticazione — MFA disattivato, codici di recupero rigenerati, password modificata senza azione dell'utente.
Comunicazioni
Interne
Designa un incident commander. Standup giornaliero minimo finché la rotazione è in corso. Un unico documento fonte di verità per "cosa abbiamo ruotato, cosa è in sospeso, cosa abbiamo trovato". Tienilo fuori da Linear se Linear è nell'ambito dell'incidente — usa un canale laterale.
Verso i clienti
Consulta il legale. Le soglie di notifica variano, ma:
- GDPR: 72 ore per violazioni notificabili che interessano i residenti UE.
- Australia (Notifiable Data Breaches scheme, OAIC): notifica appena possibile quando è probabile un danno grave.
- USA: stato per stato; alcuni stati hanno finestre di 30-60 giorni, altri richiedono notifica immediata per classi di dati specifici.
- California (CCPA): obblighi specifici se i dati personali dei residenti in California sono coinvolti.
- Clienti SOC 2 / ISO 27001: le clausole contrattuali di notifica spesso richiedono una comunicazione anticipata rispetto ai minimi regolamentari. Leggi i tuoi MSA.
Se non hai prove di esfiltrazione di dati dai tuoi sistemi, potresti non avere ancora un obbligo di notifica — ma "usiamo Vercel e Vercel ha avuto un incidente" da solo di solito non è sufficiente per attivare la notifica, a meno che dati sensibili non siano stati materialmente a rischio. Documenta il tuo ragionamento.
Dichiarazioni preparate
Prepara queste prima di averne bisogno:
- Riunione interna generale
- Avviso per i clienti
- Template di notifica all'autorità di regolamentazione
- Aggiornamento della pagina di stato (se pubblica)
Igiene dell'attribuzione pubblica
Non ripetere pubblicamente le affermazioni degli aggressori come fatti. Collega al bollettino Vercel come fonte primaria. Lascia che Vercel caratterizzi il proprio incidente — tu stai nel tuo ambito caratterizzando la tua esposizione.
Rafforzamento a medio termine (post-incidente)
Questo incidente mette in luce problemi strutturali che vale la pena risolvere anche se ti scopri non esposto.
- Migra tutti i segreti alla funzionalità delle variabili d'ambiente sensibili di Vercel. Rendila l'impostazione predefinita del team. Forma gli sviluppatori a contrassegnare al momento della creazione.
- Adotta credenziali di breve durata dove possibile. Usa la federazione OIDC di GitHub per AWS/GCP/Azure invece di chiavi di accesso long-lived copiate nelle variabili d'ambiente di Vercel. Usa gestori di segreti nativi del cloud (AWS Secrets Manager, GCP Secret Manager) accessibili a runtime invece di variabili d'ambiente hard-coded.
- Inventario delle app OAuth di terze parti collegate al tuo Google Workspace, Microsoft 365, GitHub Org e team Vercel. L'IAV di Vercel era Context.ai — una piattaforma AI integrata tramite OAuth nell'account Google Workspace di un dipendente. La stessa classe di rischio esiste in ogni organizzazione che ha approvato liberalmente integrazioni SaaS e AI-tool, e la soglia per "cosa viene approvato" è scesa notevolmente nella corsa all'oro degli AI-tool degli ultimi 18 mesi. Azioni concrete:
- Scarica il report delle app OAuth del tuo Google Workspace (Console Admin → Sicurezza → Controlli API → Controllo accesso app). Controlla ogni app con ambiti sensibili (
gmail.readonly, calendar, drive, admin.directory).
- Fai lo stesso per Microsoft 365 (Entra ID → Applicazioni aziendali).
- Istituisci una revisione trimestrale. Richiedi l'approvazione della sicurezza per nuove concessioni OAuth che comportano ambiti sensibili.
- Considera di limitare l'installazione delle app OAuth a una lista consentita anziché all'approvazione guidata dall'utente.
- Principio del minimo privilegio sull'ambito dell'App GitHub. Se Vercel non ha bisogno dell'accesso ai repo dell'intera organizzazione, limitalo ai repo che effettivamente deploya.
- Rotazione dei deploy hook come routine. Trimestrale.
- Costruisci una scansione dei segreti nel tuo pre-commit e CI. Trufflehog, gitleaks, o equivalente. Scansiona retroattivamente la cronologia del repo per qualsiasi cosa possa essere stata committata e poi ruotata — supponi che ciò che è stato committato sia ancora in qualche clone.
Riferimenti
Changelog
- 2026-04-20 (v2) — Aggiornato a seguito della dichiarazione del 20 aprile del CEO di Vercel Guillermo Rauch. Diverse voci promosse da "riportato" a "confermato": Context.ai nominato come vendor a monte violato, l'account Google Workspace di un dipendente Vercel come punto di pivot, l'enumerazione di variabili d'ambiente non sensibili come movimento laterale all'interno della piattaforma. Aggiunto scoping parallelo per l'esposizione diretta a Context.ai. Aggiunta la dichiarazione di Vercel che Next.js, Turbopack e i progetti OSS rimangono sicuri. Aggiunto l'impegno di Mandiant. Rafforzata la raccomandazione sull'inventario delle app OAuth.
- 2026-04-20 (v1) — Versione iniziale. Basata sul bollettino Vercel del 2026-04-19 e sulle segnalazioni pubbliche contemporanee. Aggiorna man mano che Vercel pubblica ulteriori dettagli, IOCs o una finestra di esposizione più ristretta.
opensourcemalware/vercel-april2026-incident-response
