Check Point sotto attacco, Adobe espone WhatsApp e Google cambia il recupero

🛡️ Executive Summary

• Check Point corregge una falla SmartConsole già sfruttata contro server di gestione esposti direttamente a internet senza restrizioni sugli indirizzi autorizzati.
• HermeticReader trasformava l’estensione Adobe Acrobat in un intermediario capace di leggere WhatsApp Web senza rubare password o cookie di sessione.
• Google aggiunge il video selfie al recupero degli account, mentre un errore Exchange Online mette per sbaglio in quarantena intere caselle.

Quattro vicende apparentemente distanti mostrano quanto la sicurezza digitale dipenda ormai dai meccanismi che circondano l’autenticazione, non soltanto da password e autenticazione multifattore. Check Point ha corretto una vulnerabilità già sfruttata che permetteva di ottenere privilegi amministrativi nei server SmartConsole esposti. Adobe ha aggiornato un’estensione Acrobat installata su centinaia di milioni di browser dopo la scoperta di una catena capace di raggiungere WhatsApp Web. Google introduce invece un video selfie preventivo per aiutare gli utenti a recuperare account bloccati. Nel frattempo, un cambiamento infrastrutturale di Microsoft ha causato l’errata quarantena di caselle Exchange Online, interrompendo posta e calendari senza che fosse in corso un attacco.

Check Point corregge una zero-day nel cuore della gestione

La vulnerabilità più urgente è CVE-2026-16232, un bypass dell’autenticazione con punteggio CVSS 9,3 che interessa il processo di accesso di SmartConsole ai prodotti Security Management e Multi-Domain Management. Un attaccante remoto non autenticato può ottenere un application token valido e utilizzarlo per accedere con privilegi amministrativi. Il problema non riguarda quindi una normale interfaccia accessoria, ma il piano di controllo attraverso il quale vengono amministrati firewall, oggetti di rete, policy, gateway e configurazioni di sicurezza. Chi conquista il management può teoricamente modificare regole, creare utenze, ridurre la visibilità dei log e predisporre ulteriori accessi verso l’infrastruttura protetta. Check Point ha confermato lo sfruttamento presso un numero limitato di clienti accomunati da una configurazione critica: i server di gestione risultavano esposti direttamente a internet senza restrizioni sugli indirizzi IP autorizzati. Le versioni R81.10, R81.20, R82 e R82.10 sono coinvolte, insieme a release precedenti ancora operative. La vicenda conferma una regola fondamentale già evidente negli attacchi contro gateway, appliance e sistemi di gestione esposti: il dispositivo che protegge il perimetro diventa spesso il punto di ingresso più prezioso quando la relativa console amministrativa viene pubblicata senza una separazione adeguata.

La patch deve essere accompagnata da un’indagine

Check Point ha distribuito il Jumbo Hotfix del 22 luglio 2026 e invita i clienti a limitare i Trusted Clients a indirizzi o subnet affidabili, proteggendo il management attraverso regole firewall esplicite. L’aggiornamento comprende anche CVE-2026-62144, un secondo bypass dell’autenticazione con escalation dei privilegi nei sistemi di gestione, e CVE-2026-62145, una privilege escalation locale nella WebUI Gaia. Non risultano prove di sfruttamento per queste due falle, ma il pacchetto deve essere applicato integralmente.

Gli amministratori che hanno mantenuto SmartConsole raggiungibile da internet devono andare oltre la semplice installazione della patch. Occorre verificare accessi provenienti da indirizzi inattesi, nuovi amministratori, modifiche alle policy, variazioni nelle regole implicite e attività anomale sui gateway collegati. Una vulnerabilità di autenticazione può infatti essere corretta senza eliminare gli account, i token o le configurazioni create prima dell’aggiornamento. Il server di management dovrebbe essere accessibile soltanto da reti amministrative, VPN dedicate, jump host e dispositivi gestiti. La presenza di una console pubblica riduce drasticamente il tempo necessario agli aggressori per trasformare una zero-day in una compromissione, neutralizzando una parte importante del valore offerto dal firewall stesso.

HermeticReader utilizzava Adobe come ponte verso WhatsApp

La seconda vulnerabilità, identificata come CVE-2026-48294 e denominata HermeticReader, interessava l’estensione Adobe Acrobat per Chrome, installata su circa 329 milioni di browser. Una pagina controllata dall’attaccante poteva attivare un motore interno chiamato Hermes e utilizzarlo per impartire comandi al content script caricato su WhatsApp Web. La catena non installava malware, non rubava password e non sottraeva il cookie della sessione WhatsApp. Non sfruttava neppure una vulnerabilità nel codice di Meta. Trasformava invece l’estensione Adobe in un confused deputy, cioè un componente fidato indotto a esercitare i propri privilegi per conto di una pagina che non avrebbe dovuto possederli. Il primo difetto derivava da risorse dell’estensione accessibili da qualunque sito e capaci di inoltrare messaggi controllati dall’esterno al service worker.

Il processo non verificava correttamente il mittente e permetteva di scrivere valori arbitrari nello storage locale dell’estensione. Modificando un flag sperimentale, la pagina attivava Hermes anche quando la funzione risultava dormiente. Il caso amplia il rischio già mostrato dalla rimozione di ModHeader dopo la raccolta nascosta dei dati di navigazione: un’estensione molto diffusa e appartenente a un editore noto può contenere percorsi privilegiati che un sito malevolo riesce a comporre in una catena di attacco.

L’attaccante poteva manipolare il DOM di WhatsApp Web

Dopo avere attivato Hermes, la pagina malevola doveva identificare la scheda di WhatsApp Web. La catena sfruttava controlli troppo permissivi sui domini, la prevedibilità degli identificativi delle tab e la possibilità di fornire al service worker un numero controllato dall’attaccante. Una volta raggiunta la scheda corretta, l’estensione accettava comandi capaci di inserire elementi HTML, modificare attributi e invocare metodi sui nodi del DOM. La Content Security Policy di WhatsApp impediva l’esecuzione diretta di script arbitrari, ma non bloccava tutte le manipolazioni strutturali.

I ricercatori hanno quindi costruito un percorso nel quale il contenuto reale della pagina veniva spostato dentro un modulo HTML e inviato verso un server esterno. L’attaccante non chiedeva all’estensione di “leggere” esplicitamente i messaggi: induceva WhatsApp Web a inviare il proprio contenuto renderizzato. Potevano essere esposti elenco delle chat, nomi dei contatti, anteprime, nome del profilo e testo della conversazione aperta, compresi eventuali codici temporanei ricevuti tramite WhatsApp. La catena consentiva inoltre di sostituire elementi dell’interfaccia, creare flussi di phishing o modificare il codice QR utilizzato per collegare nuovi dispositivi. Adobe ha riconosciuto il problema, distribuito la correzione durante lo stesso fine settimana e ottenuto l’assegnazione della CVE pochi giorni dopo.

Le estensioni devono essere trattate come software privilegiato

HermeticReader mostra perché le estensioni browser non possano essere valutate soltanto attraverso il nome dell’editore o il numero delle installazioni. Un’estensione può leggere e modificare pagine, interagire con schede differenti, utilizzare API riservate e mantenere un service worker attivo in background. La combinazione di web-accessible resources, messaggistica interna, feature flag e funzioni sperimentali può creare capacità non immediatamente visibili dal manifest.

Nelle organizzazioni, l’installazione dovrebbe essere limitata attraverso allowlist centralizzate, privilegi minimi e revisioni periodiche. Le estensioni non indispensabili devono essere rimosse, mentre quelle distribuite a tutti i dipendenti richiedono un controllo simile a quello applicato ai software endpoint. Nel caso Adobe, gli amministratori devono verificare che Chrome abbia ricevuto la versione corretta e valutare l’eventuale esposizione degli utenti che mantenevano contemporaneamente WhatsApp Web aperto e una release vulnerabile. La catena non dimostra automaticamente che le conversazioni siano state rubate nel mondo reale, ma la presenza di una proof-of-concept funzionante su una base installata così ampia impone di considerare il browser una superficie di accesso ai servizi autenticati, non un semplice visualizzatore di pagine.

Exchange Online mette in quarantena caselle legittime

Un problema completamente diverso ha interessato Exchange Online, dove Microsoft sta correggendo un incidente identificato come EX1436407. Dal 19 luglio alcune caselle sono state inserite erroneamente in quarantena, impedendo agli utenti di ricevere o inviare messaggi e, in alcuni casi, di accedere ai calendari. Chi tenta di scrivere agli account interessati può ricevere un rapporto di mancata consegna, mentre il proprietario della casella appare offline pur non avendo violato alcuna policy di sicurezza. Microsoft ha collegato l’errore a un recente cambiamento dell’infrastruttura che ha prodotto risultati inattesi durante l’indicizzazione, causando consumo eccessivo di memoria e una condizione out-of-memory. Il sistema ha reagito isolando le mailbox come se presentassero un comportamento anomalo. Non si tratta quindi di una quarantena antispam applicata ai singoli messaggi, ma di un blocco operativo dell’intera casella. L’incidente ripropone un tema già emerso nei problemi di Exchange Online e Microsoft 365 causati da modifiche del servizio cloud: un meccanismo progettato per proteggere stabilità e integrità può diventare esso stesso la causa dell’interruzione quando interpreta male la telemetria.

Microsoft deve ripulire i dati di indicizzazione

Microsoft ha avviato la rimozione dei dati di indicizzazione in eccesso e sta liberando progressivamente le caselle dalla quarantena dopo avere verificato il ritorno dei livelli di memoria entro valori accettabili. L’azienda ha classificato il problema come incidente e non ha indicato pubblicamente il numero di organizzazioni o le regioni coinvolte. La situazione costituisce inoltre una ricorrenza di un precedente problema identificato come EX1434354, segnale che la prima remediation non aveva eliminato completamente la causa. Per gli amministratori Microsoft 365, il caso richiede una comunicazione chiara agli utenti: rapporti NDR, impossibilità di aprire il calendario o mancata ricezione della posta non indicano necessariamente un account compromesso. Allo stesso tempo, non bisogna disattivare indiscriminatamente i controlli di quarantena o sicurezza per aggirare l’errore, perché si rischierebbe di creare un problema più grave. La gestione deve passare attraverso il Service Health Dashboard e le indicazioni Microsoft, verificando quali mailbox risultino effettivamente coinvolte e quali messaggi debbano essere reinviati dopo il ripristino.

Google aggiunge il volto ai metodi di recupero

Google sta distribuendo una funzione che permette di registrare preventivamente un video selfie come prova aggiuntiva per il recupero dell’account. L’utente deve configurarla quando possiede ancora pieno accesso al profilo, seguendo una sequenza di movimenti destinata a verificare la presenza di una persona reale. Se in futuro perde telefono, passkey, codici di backup o altri metodi registrati, può presentare un nuovo video che viene confrontato con il riferimento conservato. La funzione non garantisce automaticamente il ripristino e non sostituisce le altre informazioni utilizzate dal sistema. Google continua a valutare dispositivo, posizione, cronologia degli accessi, attività recente e segnali di rischio. Il video selfie diventa quindi un fattore di recupero supplementare, utile quando la maggiore sicurezza delle passkey produce un effetto collaterale: senza almeno un dispositivo fidato, il proprietario legittimo può incontrare difficoltà nel dimostrare la propria identità. La funzione tenta di ridurre questo rischio senza tornare a domande di sicurezza facilmente indovinabili o a semplici codici inviati su numeri telefonici potenzialmente oggetto di SIM swapping.

Biometria e deepfake rendono il recupero più delicato

Il riconoscimento attraverso video introduce tuttavia un dato che non può essere cambiato come una password. Il volto costituisce un identificatore permanente e richiede regole chiare su conservazione, cifratura, accesso e cancellazione. I controlli di vitalità devono distinguere una persona presente davanti alla fotocamera da fotografie, maschere, video preregistrati e contenuti sintetici generati attraverso l’intelligenza artificiale. Nessun singolo controllo biometrico può essere considerato infallibile, soprattutto quando l’attaccante dispone di fotografie pubbliche, registrazioni social e informazioni personali. Per questo Google mantiene una verifica multilivello e può negare il recupero quando il contesto appare incoerente. La nuova opzione deve essere valutata come un compromesso: aumenta le possibilità di recuperare un account dopo la perdita completa dei dispositivi, ma concentra un’informazione biometrica sensibile nell’ecosistema Google. Gli utenti devono poter distinguere il riferimento necessario al recupero da eventuali autorizzazioni aggiuntive per migliorare i sistemi di riconoscimento o stima dell’età. La sicurezza del processo dipende tanto dalla tecnologia anti-spoofing quanto dalla trasparenza con cui viene spiegato l’utilizzo del dato.

L’identità dipende dai componenti che operano intorno al login

Check Point, Adobe, Microsoft e Google mostrano quattro rischi differenti. Nel primo caso un token applicativo può aprire il piano di gestione di un firewall. Nel secondo, un’estensione fidata attraversa il confine tra una pagina ostile e WhatsApp Web. Nel terzo, un sistema automatico di protezione isola caselle legittime a causa di un errore infrastrutturale. Nel quarto, il volto diventa una chiave di recupero per account che contengono posta, file, fotografie e identità digitali. Nessuna delle quattro vicende nasce dalla debolezza di una normale password. La sicurezza moderna si sposta verso token, console amministrative, estensioni, procedure di recupero e sistemi automatici di classificazione, tutti elementi dotati di un’autorità sufficiente a produrre conseguenze anche quando l’autenticazione principale funziona correttamente. Proteggere l’identità significa quindi controllare non soltanto chi accede, ma quali componenti possono agire dopo l’accesso, recuperarlo, bloccarlo o trasferirne i privilegi verso un altro contesto.