Vercel, Zyxel e Google: la cybersecurity cambia tra cookie rubati e falle cloud

🛡️ Executive Summary

• Vercel attiva DBSC per legare le sessioni al dispositivo e ostacolare il riutilizzo dei cookie sottratti dagli infostealer.
• Zyxel corregge CVE-2026-107441, una falla distinta dalla precedente vulnerabilità GS1900 e sfruttabile senza autenticazione dalla rete locale.
• Google Cloud introduce il premio Root-in-Cloud da 250.000 dollari per vulnerabilità che permettono il controllo amministrativo di progetti altrui senza credenziali rubate.

La sicurezza delle infrastrutture digitali si confronta con tre problemi diversi ma collegati: sessioni web che possono essere riutilizzate dopo un furto, apparati di rete ritenuti aggiornati ma ancora vulnerabili e difetti architetturali capaci di attraversare i confini del cloud. In pochi giorni Vercel avvia la distribuzione di Device Bound Session Credentials (DBSC), Zyxel pubblica una correzione per CVE-2026-107441 nei propri switch GS1900 e Google Cloud amplia fino a 250.000 dollari il premio per alcune compromissioni critiche. Non sono episodi della stessa campagna né iniziative coordinate: indicano però tre punti nei quali la sicurezza tradizionale non può più fondarsi sulla sola presenza di password, patch o controlli di accesso.

Vercel lega le sessioni al dispositivo per ridurre il valore dei cookie rubati

Il 3 novembre 2026 il CTO di Vercel Malte Ubl annuncia l’avvio graduale di DBSC per gli accessi a vercel.com, ossia la console con cui gli sviluppatori amministrano progetti e distribuzioni. La difesa nasce da un problema preciso: dopo un’infezione da infostealer, un aggressore può sottrarre cookie di sessione e riutilizzarli altrove, aggirando di fatto il controllo iniziale con password o autenticazione multifattore. DBSC aggiunge invece una prova crittografica legata al dispositivo, riducendo la possibilità di rinnovare da remoto una sessione rubata. Il cambiamento assume un significato particolare per una piattaforma già esposta a incidenti legati a token e integrazioni cloud, ma non dimostra che la nuova funzione sia stata introdotta esclusivamente come conseguenza di quegli episodi. Ubl precisa che il rilascio è progressivo: occorre gestire casi particolari, compresi i flussi OAuth, e il supporto effettivo riguarda attualmente Chrome su Windows e macOS. Inoltre, la novità protegge gli accessi al portale Vercel; non significa che ogni applicazione ospitata sulla piattaforma erediti automaticamente la stessa protezione.

Leggi anche: Google Device Bound Session Credentials (DBSC) contro il furto dei cookie

Come funziona DBSC e perché non rende innocuo un malware sul computer

La documentazione tecnica di Chrome descrive il meccanismo: durante l’autenticazione il browser genera una coppia di chiavi e conserva quella privata, quando possibile, in hardware protetto, come un Trusted Platform Module o un componente equivalente. La sessione utilizza cookie di breve durata; quando devono essere rinnovati, il browser dimostra al server di possedere la chiave privata firmando una richiesta di verifica. Il cookie può ancora essere copiato, ma non basta a prolungare indefinitamente la sessione da un altro dispositivo. È una distinzione importante rispetto all’affermazione assoluta secondo cui il furto dei cookie diventerebbe impossibile: l’obiettivo è soprattutto rendere inefficace il loro riutilizzo fuori dal dispositivo originario. Se un malware conserva accesso alla macchina, può continuare ad agire localmente; se manca un supporto adeguato, entrano in gioco comportamenti di fallback meno protettivi. Il passaggio dall’annuncio di Google alla disponibilità di DBSC in Chrome 146 prepara proprio questa applicazione concreta. Vercel lavora anche a DPoP per la propria CLI, così da collegare le credenziali delle applicazioni alla dimostrazione di possesso di una chiave, senza dipendere dal supporto del browser.

Zyxel scopre che gli switch già aggiornati restavano esposti a una seconda falla

Il caso Zyxel GS1900 riguarda invece la fiducia nella patch. Il 22 ottobre il produttore distribuisce firmware aggiornati per dieci modelli e il 3 novembre pubblica l’advisory su CVE-2026-107441: si tratta di una scrittura fuori dai limiti di memoria nel programma CGI dell’interfaccia web di gestione. Un attaccante che raggiunga lo switch dalla LAN può inviare richieste HTTP appositamente costruite e potenzialmente eseguire comandi del sistema operativo senza autenticarsi. Non è quindi corretto descriverla come una falla sfruttabile indistintamente da Internet: la condizione documentata è l’accesso alla rete locale o a un segmento dal quale l’interfaccia risulti raggiungibile. La gravità emerge dalla cronologia. A giugno Zyxel aveva già corretto CVE-2026-7273, poi inserita dalla CISA nel catalogo KEV a settembre, e aveva pubblicato firmware ritenuti protetti. L’analisi dell’exploit recuperato da Binarly, descritta nella ricostruzione dell’incidente, evidenzia però una debolezza distinta che permette di colpire anche quelle versioni. La nuova revisione 2.90 Patch 3, con identificativi diversi per ciascun modello, sostituisce pertanto la precedente Patch 2: aver installato l’aggiornamento di giugno non è una garanzia sufficiente.

Quasi mille switch nella campagna e Google alza il premio per le falle cloud

La campagna associata all’attore Kapibala, già descritta nell’analisi delle compromissioni Zyxel in 48 Paesi, ha coinvolto 996 switch, di cui 133 segnalati in Italia, con raccolta di configurazioni e credenziali. Quel numero riguarda il monitoraggio della campagna e non certifica che tutti i dispositivi siano stati violati attraverso CVE-2026-107441: l’attribuzione iniziale degli attacchi alla precedente CVE è proprio uno degli aspetti rivisti durante l’indagine. Su un fronte diverso, Google Cloud sceglie di incentivare la scoperta di problemi che superano le difese più profonde delle infrastrutture condivise. Nel nuovo livello Root-in-Cloud del programma VRP la ricompensa massima annunciata raggiunge 250.000 dollari, riservati a dimostrazioni di controllo amministrativo completo su organizzazioni o progetti cloud arbitrari. La prova non può basarsi su credenziali rubate, accessi già ottenuti, interazione della vittima o configurazioni speciali preparate per il test. Anche l’eventuale esecuzione di codice nell’infrastruttura Google Borg viene sottoposta a valutazione, ma i ricercatori devono interrompere immediatamente qualsiasi ulteriore attività invasiva. L’obiettivo è premiare la ricerca su isolamento tra tenant e vulnerabilità logiche tra servizi, non il semplice recupero di password.

Continua con:

Vercel breach da Context.ai mentre AWS patcha EFS e NIST cambia gestione CVE

Dalle patch alla prova crittografica: cambia il criterio per misurare la sicurezza

L’elemento comune è la verifica della fiducia, non una relazione tecnica diretta fra le tre iniziative. Vercel non considera più sufficiente possedere un cookie; richiede una prova associata al dispositivo. Il caso Zyxel dimostra che un firmware dichiarato aggiornato può nascondere una vulnerabilità separata, perciò inventario degli switch, controllo della versione installata, isolamento delle interfacce di gestione e ricerca di accessi anomali restano indispensabili. Google, infine, vuole prove riproducibili di compromissioni architetturali, mentre osserva che l’automazione aumenta il volume delle segnalazioni senza aumentare necessariamente quello dei bug validi: è la stessa criticità emersa nella sospensione delle nuove segnalazioni di prodotto nel bug bounty open source. Per imprese italiane, provider e amministrazioni, questi sviluppi indicano priorità concrete: proteggere le sessioni, aggiornare gli apparati alla revisione realmente correttiva e verificare i confini di accesso nel cloud. Nessuna misura è una protezione universale: chi usa browser non supportati da DBSC deve ancora contare su difese tradizionali, chi ha già subito un’intrusione su Zyxel deve affiancare alla patch un’analisi dell’incidente e chi gestisce workload cloud non può confondere un premio elevato con l’assenza di vulnerabilità nei servizi operativi.