Rilascio di Chrome 145 con fix per vulnerabilità critiche (V8, PDFium, CSS) e analisi Brave sulle falle dei sistemi di autenticazione zkLogin (Sui)

Chrome 145 introduce una serie di patch di sicurezza critiche che coinvolgono PDFium, V8 e il motore CSS, mentre in parallelo Brave pubblica un’analisi tecnica su zkLogin nell’ecosistema Sui, evidenziando vulnerabilità strutturali legate a JWT, OpenID Connect e parsing ambiguo. Per gli utenti significa una cosa semplice ma urgente: aggiornare immediatamente. Per gli sviluppatori, invece, emergono segnali più profondi su come sicurezza del browser e modelli di autenticazione decentralizzata stiano convergendo in un unico fronte critico.

Chrome 145 e 144: le vulnerabilità corrette su desktop

Le versioni stabili 145.0.7632.109 e 145.0.7632.110 per Windows e Mac, insieme alla 144.0.7559.109 per Linux, includono tre fix di sicurezza che intervengono su componenti centrali del browser. Il primo riguarda un heap buffer overflow in PDFium, segnalato il 19 gennaio 2026 dal ricercatore Soiax. Il secondo corregge un integer overflow in V8, riportato il 3 febbraio 2026 da JunYoung Park. Il terzo, identificato internamente da Google il 18 gennaio 2026, risolve un ulteriore overflow nel modulo Media. Queste vulnerabilità non sono semplici bug marginali. PDFium gestisce l’engine PDF integrato nel browser, un vettore storicamente sensibile perché spesso attivato automaticamente durante la navigazione. V8, invece, è il cuore dell’esecuzione JavaScript. Un overflow qui può trasformarsi in esecuzione arbitraria di codice in contesti complessi. Parallelamente, un altro aggiornamento stabile ha portato le versioni desktop a 145.0.7632.75 e 145.0.7632.76, mentre Linux ha ricevuto la 144.0.7559.75. In questo caso il fix riguarda una vulnerabilità classificata high severity nel motore CSS, identificata come use-after-free e già oggetto di exploit in circolazione. La segnalazione, datata 11 febbraio 2026, è attribuita a Shaheen Fazim. Google ha esteso le patch anche al canale Extended Stable, con versioni 144.0.7559.177 e successivamente 144.0.7559.220, garantendo continuità agli ambienti enterprise che mantengono cicli di aggiornamento più lenti ma necessitano comunque di protezione selettiva.

Android, iOS e ChromeOS: allineamento dei fix

Sul fronte mobile, Chrome per Android raggiunge la versione stabile 145.0.7632.109, allineando i fix di sicurezza con quelli desktop e introducendo miglioramenti in stabilità e performance. Il canale Beta sale a 146.0.7680.14, mentre il Dev arriva a 147.0.7693.3, disponibili tramite Google Play. Per iOS, la versione stabile tocca 145.0.7632.108, con rollout progressivo sull’App Store, mentre la Beta raggiunge 146.0.7680.13. Anche qui l’enfasi è su stabilità, riduzione dei crash e sincronizzazione delle patch di sicurezza. Nel mondo ChromeOS, il canale Dev aggiorna a 16581.6.0, con browser 146.0.7680.5, includendo modifiche visibili nei log Git e compatibilità estesa ai dispositivi ChromeOS Flex. Questo allineamento multi-piattaforma dimostra un approccio coordinato, in cui i fix non rimangono confinati al desktop ma vengono distribuiti in modo omogeneo.

Strumenti interni e ricerca esterna: il modello di sicurezza Google

Google continua a riconoscere pubblicamente i ricercatori che segnalano vulnerabilità, confermando un modello basato su disclosure responsabile. L’uso di strumenti come AddressSanitizer e MemorySanitizer rimane centrale nell’individuazione preventiva di bug di memoria, soprattutto in componenti complessi come V8. La dinamica è chiara: gran parte delle vulnerabilità moderne nei browser deriva da errori di gestione della memoria. Gli overflow e gli use-after-free non sono anomalie isolate ma sintomi di una complessità crescente del codice. In questo contesto, l’automazione dei test e il fuzzing diventano strumenti essenziali per ridurre la superficie di attacco prima che un exploit entri in circolazione.

zkLogin, JWT e zero knowledge: l’analisi critica di Brave

Mentre Google interviene sulla sicurezza del browser, Brave pubblica un’analisi approfondita su zkLogin, un sistema di autorizzazione basato su JSON Web Token e Zero-Knowledge Proof integrato nell’ecosistema Sui. Il protocollo consente agli utenti di autenticarsi tramite provider esistenti come Google o Facebook, eliminando la necessità di gestire chiavi wallet indipendenti.

Nel sistema zkLogin, il JWT funge da root of trust. Include header, payload e signature con claim come issuer, audience, subject, expiration e issuance time. Il flusso utilizza OpenID Connect, mentre servizi esterni di proving e salt generano prove crittografiche che dimostrano il possesso dei claim senza rivelare l’intero token. Secondo i dati pubblici, nell’ecosistema Sui si sono registrate oltre 7,6 milioni di transazioni zkLogin e più di 500.000 indirizzi zkLogin attivi. Numeri rilevanti che trasformano un’analisi teorica in questione sistemica.

Brave individua tre classi principali di vulnerabilità. La prima riguarda il parsing ambiguo dei JWT in assenza di enforcement canonico. Encoding non canonici o shadowing di claim possono consentire manipolazioni sottili ma efficaci. La seconda classe concerne la mancanza di binding tra autenticazione e autorizzazione, aprendo la strada a impersonation tramite issuer maliziosi. La terza riguarda la ricentralizzazione della fiducia nei provider e nei servizi di proving, con implicazioni su privacy e linkability. Il punto cruciale non è l’esistenza della zero-knowledge proof, ma la semantica attorno ai token. Le ZKP non garantiscono automaticamente sicurezza se il layer applicativo rimane ambiguo o mal vincolato. Brave raccomanda enforcement canonico rigoroso, binding end-to-end e storage sicuro lato browser, oltre a governance chiara sugli issuer.

Sicurezza browser e autenticazione decentralizzata: un fronte unico

La convergenza tra le patch di Chrome 145 e l’analisi di zkLogin mostra un elemento comune: la gestione della fiducia. Nel browser, la fiducia riguarda la memoria, il parsing e l’esecuzione sicura del codice. Nella blockchain, riguarda l’identità, il binding e l’interpretazione dei claim. Un overflow in V8 e un parsing ambiguo di JWT nascono in contesti diversi ma condividono una radice: la complessità semantica dei sistemi moderni. Ogni layer aggiuntivo, che sia un motore JavaScript o un circuito ZKP, amplia la superficie di errore se non viene accompagnato da regole di validazione rigide e verificabili. Per milioni di utenti, la priorità resta l’aggiornamento immediato del browser. Per sviluppatori e architetti di sistemi, invece, il messaggio è più strutturale: la sicurezza non è un attributo isolato del singolo componente, ma una proprietà emergente dell’intero stack, dal parsing della memoria al binding crittografico delle identità.

Perché aggiornare Chrome ora è una priorità reale

Aggiornare Chrome 145 non è una semplice operazione di routine. La presenza di un exploit CSS già in circolazione, combinata con overflow in componenti centrali come PDFium e V8, trasforma l’update in una misura di mitigazione immediata. In un contesto in cui browser, autenticazione federata e sistemi blockchain si intrecciano, ogni vulnerabilità non patchata diventa un punto di amplificazione. La sicurezza, oggi, non è più un dettaglio tecnico ma un requisito operativo continuo.