Grave falla sandbox in vm2 e hijack su migliaia di server SmarterMail: perché queste due CVE cambiano le regole del gioco

0

CVE-2026-23760 è la vulnerabilità che ha trasformato migliaia di server SmarterMail in bersagli da hijack “a ciclo continuo”, perché rompe un punto che di solito resta intoccabile: il reset password dell’account amministrativo. Nel frattempo, CVE-2026-22709 colpisce vm2, una delle librerie più usate per eseguire JavaScript non fidato su Node.js, con un sandbox escape che nasce da un dettaglio apparentemente innocuo: la gestione degli oggetti globali di Promise. Se le due storie sembrano lontane, nella pratica descrivono la stessa dinamica: superfici “di servizio” che diventano superfici “di compromissione”, con exploit triviali e automazione che fa il resto. Qui trovi cosa è stato scoperto, perché sta funzionando così bene per gli attaccanti e cosa conviene controllare subito in produzione per ridurre la probabilità di takeover e post-exploitation.

SmarterMail sotto assedio: come funziona CVE-2026-23760 e perché consente hijack admin

L’elemento che rende CVE-2026-23760 così pericolosa non è solo l’impatto, ma il percorso. La vulnerabilità risiede in un endpoint API legato al force-reset-password, un flusso che, per definizione, tocca credenziali e privilegi. Secondo la ricostruzione dei ricercatori, l’endpoint accetta richieste anonime senza richiedere una prova di possesso, senza validare un token di reset e senza imporre un controllo robusto sull’identità del chiamante. In condizioni di esposizione Internet, un attaccante può fornire lo username amministrativo e una nuova password, e ottenere di fatto il cambio credenziali senza autenticazione.

Questa è la forma più pericolosa di bypass: non è un “salto” laterale dentro l’applicazione, ma un cambio diretto delle chiavi. Una volta ottenuto l’accesso admin, il server di posta non è più soltanto un servizio e-mail. Diventa un punto di controllo su caselle, messaggi, allegati, rubriche, credenziali, integrazioni, e, nel caso peggiore, un trampolino verso esecuzione di codice e persistenza a livello host. È qui che la vulnerabilità passa da hijack a rischio infrastrutturale: un mail server compromesso è un asset perfetto per muoversi nel dominio, raccogliere dati sensibili, distribuire payload e condurre campagne di phishing credibili dall’interno.

I numeri citati dagli osservatori amplificano il quadro. Shadowserver ha identificato oltre 6000 istanze esposte online, con una concentrazione di circa 4200 in Nord America e quasi 1000 in Asia. Altri ricercatori hanno parlato di una superficie ancora più ampia, perché tra esposizione, patch non applicate e build non allineate basta poco per restare in fascia vulnerabile. L’aspetto più rilevante, però, non è la cifra precisa: è la combinazione di endpoint sfruttabile, esposizione Internet e automazione. Quando l’exploit è semplice, l’attacco non resta “mirato”. Diventa industriale.

Cronologia operativa: disclosure, patch, exploit in the wild e intervento CISA

La timeline è un dettaglio che conta perché spiega perché, in poche settimane, si è passati da ricerca a sfruttamento massivo. Il difetto viene riportato a SmarterTools da watchTowr l’8 gennaio 2026. Il vendor rilascia una correzione nella build 9511 il 15 gennaio 2026. A quel punto, però, si innesta la dinamica tipica delle vulnerabilità su software infrastrutturali: molte istanze restano esposte per inerzia operativa, change management lento, finestre di manutenzione, dipendenze interne.

Secondo Huntress, gli exploit automatizzati “in massa” risultano in corso dal 22 gennaio 2026, segnale che il tempo tra patch e weaponization si è ristretto ulteriormente. La svolta istituzionale arriva il 26 gennaio 2026, quando CISA inserisce CVE-2026-23760 nel catalogo Known Exploited Vulnerabilities, formalizzando che non si tratta di un rischio teorico ma di una vulnerabilità sfruttata attivamente. L’ordine alle agenzie federali USA di mettere in sicurezza i sistemi entro il 16 febbraio 2026 non è un dettaglio burocratico: è un indicatore di severità e di pressione operativa. Quando una CVE entra nel KEV, il messaggio implicito è che l’attacco è già “routine” per qualcuno.

Il punto più delicato è che, in questo scenario, patchare non equivale automaticamente a “tornare sani”. Se un attore ha già eseguito il reset e ottenuto accesso admin, l’upgrade ferma l’exploit ma non annulla l’accesso già acquisito. Per questo l’azione corretta è sempre doppia: aggiornamento immediato e verifica dei segni di compromissione, con rotazione credenziali e revisione dei privilegi.

Cosa cambia davvero per chi gestisce SmarterMail in produzione

Nel mondo reale, SmarterMail è spesso esposto perché deve ricevere e servire posta, e per esigenze di amministrazione remota. Questo significa che l’hardening non può basarsi su un solo controllo. L’upgrade alla build 9511 è la condizione minima, ma non è l’unica misura ragionevole quando l’exploit è automatizzato e il flusso colpito è quello di reset password.

Dopo l’aggiornamento, la prima cosa da verificare è la postura degli account privilegiati. Se l’attacco passa dallo username admin, allora conta moltissimo la disciplina sugli account: riduzione del numero di utenti con privilegi massimi, controllo su alias e account “storici”, introduzione di MFA dove possibile e revisione delle policy di autenticazione. In parallelo, ha senso interrogare i log cercando pattern coerenti con reset sospetti, soprattutto nei giorni in cui sono stati segnalati exploit massivi. Anche senza indicatori perfetti, il semplice fatto che l’endpoint sia stato sfruttato in the wild rende prudente forzare una rotazione delle credenziali admin e dei token applicativi associati.

Infine, c’è una misura che molte organizzazioni sottovalutano: la riduzione dell’esposizione amministrativa. Se l’admin panel o endpoint sensibili sono raggiungibili da Internet senza restrizioni, il mail server diventa bersaglio continuo. Quando non è possibile chiudere, la segmentazione e la limitazione per IP o VPN diventano elementi concreti di riduzione rischio. La logica è sempre la stessa: se l’exploit è semplice, l’unica barriera reale è ridurre il numero di attori che possono “provare”.

Vm2 e CVE-2026-22709: perché una sanitizzazione “quasi corretta” basta per evadere la sandbox

Se SmarterMail racconta la compromissione via API, CVE-2026-22709 racconta un rischio complementare: l’esecuzione di codice non fidato in contesti apparentemente isolati. vm2 è una libreria usata per creare contesti “sicuri” in cui far girare JavaScript senza accesso diretto al filesystem. Proprio per questo è finita nel cuore di prodotti e servizi che accettano input dagli utenti, come runner di codice online, chatbot, estensioni interne, automation e tool che permettono script personalizzati.

La vulnerabilità descritta come sandbox escape nasce dalla gestione di Promise. Vm2 sanitizza callback nella sua implementazione interna di Promise, ma trascura quelli collegati al Promise globale attraverso metodi come .then() e .catch(). Questo dettaglio è la crepa che consente l’evasione: l’attaccante sfrutta callback non correttamente sanificate per ottenere esecuzione fuori dal perimetro atteso, fino a raggiungere la possibilità di eseguire codice arbitrario sull’host. Il fatto che venga descritta come sfruttabile con exploit “triviali” è un segnale pesante: quando il payload è semplice, la probabilità di weaponization e abuso su larga scala sale immediatamente.

Sul piano di versione, il racconto è coerente con ciò che spesso accade nelle sandbox JavaScript. Un primo fix “parziale” non è sufficiente, perché gli attaccanti cercano varianti e bypass fino a trovare il sentiero rimasto aperto. Nel caso di vm2, il fix parziale viene associato a 3.10.1, poi arriva 3.10.2 per stringere la sanitizzazione, e infine 3.10.3 viene indicata come release che incorpora le correzioni note e mette in sicurezza rispetto a CVE-2026-22709 e a bypass correlati. In un ecosistema dove vm2 registra circa un milione di download settimanali su npm e risulta integrata in oltre 200.000 repository GitHub, l’inerzia della dipendenza è parte del rischio: il problema non è solo chi usa vm2 intenzionalmente, ma chi la eredita da una catena di dipendenze e non la controlla.

La storia di vm2 è inoltre appesantita da un passato di evasioni. La libreria era stata considerata “a rischio” già per precedenti come CVE-2022-36067, e il 2023 ha visto altre disclosure con exploit pubblici. Il fatto che il progetto sia stato discontinuato e poi “resuscitato” aumenta la necessità di governance interna: se stai eseguendo codice non fidato, una sandbox applicativa da sola raramente è sufficiente. Servono livelli aggiuntivi di isolamento.

Perché queste due vulnerabilità si parlano: automazione, banalità dell’exploit e superficie sistemica

Il filo comune tra CVE-2026-23760 e CVE-2026-22709 è la trasformazione di una funzionalità legittima in un vettore di compromissione. In SmarterMail l’oggetto “legittimo” è il reset password. In vm2 l’oggetto “legittimo” è la Promise globale, un costrutto fondamentale e quindi difficile da “disinnescare” senza rompere compatibilità. In entrambi i casi, l’exploit viene descritto come semplice, e questo cambia completamente lo scenario: non serve un attore altamente specializzato per fare danni. Serve un bot e una lista di target.

Questa dinamica si aggancia a un altro problema moderno: la velocità con cui le vulnerabilità vengono integrate in tool automatici. Quando un ricercatore pubblica PoC o quando un vendor rilascia una patch, gli attori malevoli spesso usano proprio quel delta per derivare l’exploit. È uno dei motivi per cui il tempo tra disclosure e attacco si è ridotto a giorni, a volte ore, e per cui l’approccio corretto non è più “patchiamo quando possiamo” ma “patchiamo prima che diventi routine”.

Se gestisci piattaforme SaaS, ambienti con esecuzione di codice utente, servizi di posta o portali amministrativi, la combinazione di questi due casi suggerisce una priorità: ridurre la fiducia implicita nei componenti “di servizio”. Il reset password deve essere progettato come percorso ad alta sicurezza. Una sandbox JS deve essere trattata come un livello, non come una garanzia.

Domande frequenti su CVE-2026-23760