Ivanti EPMM zero-day: RCE e scadenza CISA 3 giorni

Due zero-day in Ivanti EPMM permettono RCE non autenticato. CISA imposta tre giorni di scadenza KEV: i server esposti sono potenzialmente compromessi.

Contenuto

Ivanti EPMM zero-day: RCE e scadenza CISA 3 giorni
Ivanti EPMM zero-day: RCE e scadenza CISA 3 giorni

Ivanti ha confermato il 29 gennaio 2026 due vulnerabilità zero-day in Endpoint Manager Mobile, CVE-2026-1281 e CVE-2026-1340, che consentono esecuzione remota di codice senza autenticazione sui server MDM esposti a Internet. CISA ha imposto per entrambe scadenze di remediation da record — circa tre giorni per le agenzie federali — con l’ultima ordinanza caduta l’11 aprile. Ora l’analisi di un honeypot Rapid7, il reverse engineering delle patch condotto da watchTowr e le advisory del vendor spiegano perché un server di gestione dispositivi mobili è diventato un ponte ideale per lateral movement e esfiltrazione di dati aziendali.

Punti chiave
  • Entrambe le vulnerabilità raggiungono un punteggio CVSS di 9.8 e sfruttano richieste HTTP GET malformate agli endpoint /mifs/c/appstore/fob/ e /mifs/c/aftstore/fob/ per iniettare comandi in script Bash lato server.
  • CISA ha inserito CVE-2026-1281 nel catalogo KEV con due date al 1° febbraio 2026 e CVE-2026-1340 con due date all’11 aprile 2026, entrambe con un intervallo di circa tre giorni per le agenzie federali.
  • Ivanti ha distribuito patch RPM temporanee che non sopravvivono agli upgrade di versione; la correzione permanente è prevista in EPMM 12.8.0.0 nel corso del primo trimestre 2026.
  • Un honeypot Rapid7 ha registrato oltre 130 indirizzi IP unici in 24 ore, con il 58% del traffico diretto a exploitation attiva tramite reverse shell, webshell e droppers automatici.

Il meccanismo: da una GET HTTP alla shell del server MDM

Il nucleo dell’attacco risiede in due endpoint di Ivanti Endpoint Manager Mobile accessibili senza autenticazione. Invocando /mifs/c/appstore/fob/ e /mifs/c/aftstore/fob/ con parametri GET malformati, l’attaccante inietta input all’interno degli script Bash lato server map-appstore-url e map-aft-store-url. L’analisi tecnica condotta da watchTowr Labs sulle patch RPM rilasciate da Ivanti ha evidenziato che parametri come st possono veicolare payload arbitrari, ottenendo l’esecuzione di comandi sul sistema sottostante con punteggio CVSS di 9.8.

Il server MDM gestisce policy, certificati e credenziali di dispositivi mobili aziendali. Una volta compromesso, diventa un nodo privilegiato per muoversi lateralmente all’interno della rete e per accedere a dati sensibili archiviati sui terminali gestiti.

Il catalogo KEV e le scadenze da tre giorni di CISA

CISA ha inserito CVE-2026-1281 nel catalogo Known Exploited Vulnerabilities a inizio febbraio, fissando la due date al 1° febbraio 2026 per le agenzie federali. Il successivo inserimento di CVE-2026-1340, ordinato l’8 aprile 2026 con scadenza all’11 aprile, ha replicato lo stesso ritmo: circa tre giorni per la remediation. Tale cadenza è eccezionale persino per gli standard del KEV e segnala una valutazione di rischio massima.

Ivanti ha confermato nel proprio advisory: «We are aware of a very limited number of customers whose solution has been exploited at the time of disclosure». Sebbene la exploitation pre-patch di CVE-2026-1340 non disponga al momento di conferme indipendenti aggiuntive oltre all’inserimento nel KEV, la sequenza delle ordinanze CISA ha imposto alle agenzie federali un’urgenza senza precedenti. Le scadenze, pur vincolanti solo per le agenzie FCEB, rappresentano un benchmark che le aziende private non possono ignorare se gestiscono dati critici.

La gravità del punteggio CVSS di 9.8, combinata con l’assenza di requisiti di autenticazione, spiega perché CISA abbia compresso i tempi oltre ogni prassi standard.

Honeypot e exploitation attiva: cosa registrano i sensori Rapid7

La disclosure tecnica ha generato un’ondata di traffico malevolo misurabile. Secondo quanto rilevato da Christiaan Beek, Senior Director Threat Intelligence di Rapid7, un honeypot dedicato ha raccolto oltre 130 indirizzi IP unici in sole 24 ore, con il 58% delle connessioni finalizzato a exploitation attiva piuttosto che a semplice ricognizione.

"In just 24 hours, our Ivanti EPMM honeypot recorded hundreds of inbound traffic connections from more than 130 unique IP addresses, with 58% directly attempting exploitation of the latest Ivanti EPMM vulnerabilities" - Christiaan Beek, Senior Director Threat Intelligence, Rapid7

I payload dominanti non erano scansioni da ricerca: includevano reverse shell sulla porta 443, tentativi di deployment di webshell e droppers automatici. L’obiettivo, come ha spiegato lo stesso Beek, era «built to gain control fast through reverse shells over port 443, webshell deployment attempts, and automated droppers». I server EPMM esposti si sono trasformati in bersagli ad alta priorità nel giro di un giorno: la finestra di esposizione si è misurata in ore, non in giorni.

La persistenza e il limite delle patch temporanee

Ivanti ha evidenziato che gli attaccanti, una volta ottenuto l’accesso, mantengono la persistenza attraverso web shell e reverse shell. Le patch rilasciate sotto forma di RPM sono interime: non sopravvivono agli upgrade di versione, e la correzione strutturale è attesa nel rilascio di EPMM 12.8.0.0, previsto per il primo trimestre 2026 senza che una data esatta sia stata comunicata.

A complicare il lavoro degli incident responder, il vendor ha dichiarato esplicitamente di non possedere indicatori di compromesso atomici sufficientemente affidabili. Questo vincolo obbliga le aziende a un threat hunting ampio, supportato dai pattern sintetizzati da Rapid7 per l’analisi dei log, senza poter contare su firme precise per escludere o confermare un’infiltrazione. La ricerca manuale di anomalie nei log di accesso agli endpoint /mifs/c/appstore/fob/ e /mifs/c/aftstore/fob/ diventa un passaggio obbligatorio, dato che non esiste un hash o un file noto su cui basare una scansione automatica.

Benjamin Harris, CEO di watchTowr, ha sottolineato: «While patches are available from Ivanti, applying patches will not be enough – threat actors have been exploiting these vulnerabilities as zero-days, and organizations that are as of disclosure exposing vulnerable instances to the internet must consider them compromised, tear down infrastructure and instigate incident response processes». La raccomandazione trasforma la semplice applicazione della patch in un’operazione di ricostruzione dell’infrastruttura e rotazione delle credenziali.

Questo scenario rende l’EPMM un caso limite: non basta il patching, ma serve una verifica forense dello stato di compromissione prima di rimettere in produzione il server.

Cosa fare adesso

In assenza di indicatori atomici e di una patch definitiva, la risposta deve essere strutturale e rapida.

  • Incident response su ogni nodo esposto. Ivanti e i ricercatori concordano: se il server EPMM era raggiungibile da Internet al momento della disclosure, va considerato potenzialmente compromesso e isolato per analisi forense.
  • Patch RPM immediate, ma consapevoli dei limiti. Le patch distribuite da Ivanti vanno applicate fuori ciclo, tenendo presente che non resistono agli upgrade di versione e che la fix permanente arriverà solo con EPMM 12.8.0.0.
  • Hunting della persistenza. Senza indicatori di compromesso atomici affidabili, è necessario cercare attivamente web shell, reverse shell e anomalie nei log degli endpoint /mifs/c/appstore/fob/ e /mifs/c/aftstore/fob/, avvalendosi dei pattern messi a disposizione da Rapid7.
  • Rotazione completa dei trust. Certificati, credenziali di servizio e policy MDM gestite dal server vanno ruotate per prevenire movimento laterale in caso di exfiltrazione pregressa di dati o chiavi.

La vicenda non è solo un caso di vulnerabilità critiche: è la dimostrazione che un server MDM, per sua natura centralizzato e ricco di trust relationship, è diventato un obiettivo strategico per l’accesso alla rete aziendale. La compressione dei tempi di remediation imposta da CISA — circa tre giorni — riflette una percezione del rischio che le aziende private farebbero bene ad adottare come standard interno, indipendentemente dalle scadenze federali. La domanda per i team di sicurezza non è più se applicare la patch, ma se qualche istanza esposta abbia già generato una backdoor silenziosa.

Quali prodotti Ivanti sono effettivamente a rischio?

La società ha esplicitato che le due vulnerabilità interessano esclusivamente Endpoint Manager Mobile (EPMM). Altri prodotti come Neurons for MDM, Endpoint Manager (EPM) o Sentry non sono toccati.

Perché le patch attuali non sono definitive?

Ivanti ha distribuito aggiornamenti in formato RPM che risolvono la falla ma non sopravvivono agli upgrade di versione. La fix strutturale è attesa in EPMM 12.8.0.0 nel corso del primo trimestre 2026, senza che una data esatta sia stata comunicata.

Cosa cambia l’assenza di IoC atomici affidabili?

Ivanti ha dichiarato di non disporre di indicatori di compromesso precisi e verificabili. Di conseguenza, le aziende non possono escludere un’intrusione tramite semplice scansione con firme note: devono condurre threat hunting ampio, supportato dai pattern sintetizzati da Rapid7, per rilevare webshell e reverse shell.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews