Google rafforza la sicurezza del browser più usato al mondo con Chrome 146, introducendo la disponibilità pubblica di Device Bound Session Credentials (DBSC) e una nuova protezione progettata per neutralizzare gli infostealer che rubano cookie di sessione. Il cambiamento più importante lega crittograficamente la sessione al dispositivo fisico tramite hardware root of trust, rendendo inutilizzabili i token rubati su un altro computer. In parallelo, aprile 2026 porta anche nuove criticità nel panorama software: una vulnerabilità RCE colpisce Marimo, il SDK EngageLab espone fino a 50 milioni di dispositivi Android, mentre un attacco supply-chain compromette i download ufficiali di CPU-Z e HWMonitor. Il risultato è un quadro in cui la sicurezza browser fa un salto avanti proprio mentre l’ecosistema software mostra nuovi punti di fragilità.
Cosa leggere
Chrome 146 lega i cookie di sessione al dispositivo con DBSC
La novità centrale di Chrome 146 è l’attivazione di DBSC, tecnologia che trasforma la protezione delle sessioni web. Invece di affidarsi solo al cookie come token riutilizzabile, il browser genera una coppia di chiavi crittografiche e conserva la privata nel TPM su Windows o in enclave hardware equivalenti. Quando il server rinnova una sessione, Chrome deve dimostrare il possesso della chiave privata locale. Questo significa che anche se un malware riesce a rubare il cookie, il token diventa inutile fuori dal dispositivo originario. Per siti enterprise, provider IAM, pannelli cloud e servizi finanziari è una svolta concreta contro l’account takeover, perché riduce drasticamente il valore economico dei cookie rubati dagli infostealer.
Per gli sviluppatori web l’adozione è relativamente semplice, perché la protezione viene abilitata lato server tramite intestazioni HTTP dedicate. Una volta attivata, la sessione viene continuamente riconvalidata dal browser con prove crittografiche brevi e trasparenti per l’utente. Questa architettura sposta il modello di sicurezza da “token posseduto” a “token + dispositivo verificato”, alzando notevolmente il costo operativo degli attaccanti.
Google blocca gli infostealer specializzati nel furto di sessioni
Oltre a DBSC, Google introduce in Chrome 146 una protezione nativa contro gli infostealer che puntano direttamente ai cookie di autenticazione. Negli ultimi mesi malware come LummaC2 e famiglie simili hanno costruito un’economia criminale basata proprio sul furto di sessioni già autenticate, spesso rivendute in bundle per accessi a email, servizi cloud, pannelli aziendali e social media. La nuova difesa interviene riducendo la possibilità che i token rubati mantengano valore operativo. In pratica, il malware può ancora tentare l’estrazione locale, ma non riesce più a riutilizzare efficacemente la sessione su macchine esterne. Questo ribalta il vantaggio degli attaccanti: il furto massivo di cookie non garantisce più takeover immediato e obbliga a compromissioni locali più rumorose, più facili da rilevare con EDR e controlli endpoint. Per le aziende è un cambiamento importante perché riduce uno dei vettori preferiti per bypassare MFA e password reset.
Marimo espone notebook Python a remote code execution
Nel panorama delle vulnerabilità applicative emerge anche Marimo, ambiente open source per notebook Python sempre più usato in data science e sviluppo rapido. La falla RCE descritta nella tua traccia è particolarmente critica perché colpisce contesti dove i notebook vengono esposti in rete interna o, peggio, su server pubblici per team distribuiti. Il problema nasce da una gestione non sicura degli input nelle API di esecuzione, consentendo a un attaccante di inviare una richiesta HTTP malevola e ottenere esecuzione di codice arbitrario sul server che ospita il notebook. In ambienti DevOps o AI workflow questo rischio è amplificato dalla presenza di token cloud, credenziali database, chiavi API e modelli proprietari caricati in memoria. Per chi usa notebook persistenti in ambienti condivisi, il rischio reale non è solo la compromissione del servizio ma il pivot verso pipeline ML, storage object e infrastrutture CI/CD.
EngageLab SDK espone milioni di app Android a rischio supply-chain
Un altro fronte critico riguarda il SDK EngageLab, integrato in un numero enorme di applicazioni Android per analytics, push e monetizzazione. La vulnerabilità descritta impatta circa 50 milioni di dispositivi, mostrando ancora una volta quanto il rischio mobile moderno sia spesso legato alle librerie di terze parti.
Quando un SDK vulnerabile entra in migliaia di app, la superficie d’attacco cresce in modo esponenziale. Giochi, utility, tool di produttività e app consumer possono diventare vettori indiretti di esecuzione remota o accesso a dati sensibili senza che lo sviluppatore finale abbia introdotto direttamente il bug. Per gli utenti, la remediation dipende quasi interamente dalla velocità con cui gli sviluppatori aggiornano il pacchetto e rilasciano nuove build sul Google Play Store. Per i team mobile, questo caso ribadisce la necessità di inventario SBOM, monitoraggio continuo delle dipendenze e alerting automatico su CVE relative agli SDK embedded.
CPUID colpita da attacco supply-chain su CPU-Z e HWMonitor
La compromissione dei download ufficiali di CPUID rappresenta il caso più delicato dal punto di vista della fiducia utente. CPU-Z e HWMonitor sono strumenti storicamente percepiti come affidabili, spesso scaricati anche da utenti esperti, overclocker, tecnici hardware e professionisti IT. Un attacco supply-chain in questo contesto dimostra quanto sia efficace colpire software legittimo ad alta reputazione. Le versioni compromesse distribuiscono backdoor e infostealer, trasformando un tool di diagnostica in vettore per furto credenziali, cookie, fingerprint hardware e informazioni di sistema. Il rischio è particolarmente elevato nei laboratori IT e nei PC amministrativi dove questi strumenti vengono spesso usati con privilegi elevati. La lezione qui è netta: anche il software più conosciuto deve essere verificato con hash, firme digitali e telemetria EDR, soprattutto quando scaricato in finestre temporali vicine a incidenti pubblici.
Chrome 146 segna il nuovo standard contro il session hijacking
Il vero messaggio strategico di aprile 2026 è che Google Chrome 146 alza finalmente il livello di difesa contro il session hijacking, uno dei vettori più redditizi dell’economia infostealer. DBSC cambia il paradigma della sicurezza web perché rende i cookie rubati quasi privi di valore fuori dal dispositivo, mentre la nuova protezione nativa contro gli stealer rafforza la difesa lato browser. Allo stesso tempo, i casi Marimo, EngageLab e CPUID ricordano che il rischio si sta spostando sempre di più sulla supply chain del software e sulle dipendenze integrate. Browser più sicuri, SDK verificati, notebook non esposti e download firmati diventano quindi parti della stessa strategia difensiva. Per utenti e aziende, il 2026 conferma una verità ormai centrale: la protezione dell’identità digitale non passa più solo dalle password, ma dalla sicurezza del dispositivo, del browser e dell’intera catena software.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU. In qualità di Affiliato Amazon, ricevo un guadagno dagli acquisti idonei. Questo non influenza i prezzi per te.
