QNAP sotto attacco con Plex2Shell, Veeam rischia il blocco dei backup su AMD EPYC

🛡️ Executive Summary

• QNAP segnala compromissioni sospette attraverso Plex2Shell. Quattro vulnerabilità concatenate permettono l’esecuzione remota di codice sui NAS con Plex Media Server vulnerabile ed esposto a Internet.
• Aggiornare Plex non elimina un’infezione già presente. QNAP raccomanda la versione 1.43.3.10861 o successiva, controlli sui dispositivi, reinstallazione pulita di Plex e rotazione delle credenziali nei casi a rischio.
• Veeam Software Appliance può bloccarsi su processori AMD EPYC. Un controllo crittografico jitterentropy in modalità FIPS provoca kernel panic intermittenti. Separatamente, Veeam distribuisce correzioni per CVE-2026-98432, vulnerabilità critica del kernel Linux.

QNAP e Veeam affrontano due problemi di sicurezza e affidabilità che interessano direttamente le infrastrutture di archiviazione e backup. Il 6 novembre 2026, QNAP conferma di aver ricevuto segnalazioni di possibili compromissioni dei propri NAS attraverso Plex2Shell, una catena di quattro vulnerabilità di Plex Media Server già sfruttata in attacchi reali. L’azienda invita gli utenti ad aggiornare immediatamente il software, ma avverte che la semplice installazione della patch non rimuove eventuali componenti malevoli già presenti. Parallelamente, Veeam segnala che alcune macchine virtuali Software Appliance possono interrompere l’avvio sui sistemi dotati di processori AMD EPYC, a causa di un errore nei controlli crittografici del kernel Linux. A complicare la gestione degli aggiornamenti arriva anche CVE-2026-98432, una vulnerabilità critica dello stack TCP del kernel per la quale Veeam ha avviato la distribuzione di correzioni. I due incidenti sono indipendenti, ma coinvolgono sistemi utilizzati per conservare dati e garantire la continuità operativa.

QNAP conferma attacchi Plex2Shell contro i NAS esposti a Internet

QNAP riferisce che alcuni clienti hanno segnalato possibili compromissioni dei propri dispositivi attraverso Plex2Shell, una catena di quattro vulnerabilità identificate come CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 e CVE-2026-96656. I difetti interessano Plex Media Server 1.43.2 e versioni precedenti e, se sfruttati congiuntamente, consentono a un aggressore remoto privo di autenticazione di eseguire codice con i privilegi del processo Plex. Le vulnerabilità sono state segnalate dal ricercatore Zach Main nel luglio 2026, mentre la pubblicazione dei dettagli tecnici e di un proof of concept, il 16 ottobre, ha preceduto una crescita delle attività offensive. Il 20 ottobre, CISA ha inserito tutte e quattro le CVE nel catalogo delle vulnerabilità sfruttate attivamente, imponendo alle agenzie federali statunitensi un aggiornamento prioritario. Le campagne documentate comprendono l’installazione di cryptominer e software proxy, trasformando server multimediali compromessi in infrastrutture controllate da terzi.

Leggi anche: Plex2Shell sotto attacco, Broadcom Wi-Fi senza patch: server e router esposti

La precisazione più importante riguarda il prodotto effettivamente vulnerabile. Secondo QNAP PSIRT, QTS e QuTS hero non sono direttamente affetti dalle quattro CVE, che risiedono nell’applicazione Plex installabile attraverso App Center. Questo non elimina però il rischio per il NAS: se Plex viene compromesso, l’attaccante può operare con i privilegi del servizio e tentare di raggiungere file e risorse accessibili. Il rischio maggiore interessa i dispositivi che utilizzavano una versione vulnerabile mentre Plex Remote Access era attivo, la porta TCP 32400 era inoltrata dal router oppure l’esposizione veniva configurata attraverso UPnP o myQNAPcloud. Non tutti i NAS QNAP sono quindi vulnerabili: l’esposizione dipende dalla presenza di Plex, dalla versione installata e dalla configurazione di accesso remoto.

Plex 1.43.3 corregge le falle, ma i NAS compromessi richiedono una bonifica

La versione correttiva indicata da QNAP è Plex Media Server 1.43.3.10861 o successiva, disponibile attraverso App Center. L’installazione chiude il percorso di sfruttamento di Plex2Shell, ma non elimina automaticamente miner, proxy o altri componenti già installati dagli aggressori. Nella guida ufficiale alla verifica e alla bonifica, QNAP raccomanda di considerare potenzialmente compromessi i NAS che hanno esposto su Internet Plex 1.43.2 o precedente. Prima delle operazioni di pulizia è opportuno preservare i log, soprattutto quando si intende richiedere un’analisi al supporto tecnico. La procedura documentata comprende la rimozione di Plex, la verifica degli eventuali file residui, una reinstallazione pulita e la precauzione di non riutilizzare il contenuto precedente della directory Codecs. In presenza di indizi di compromissione più estesa, deve essere valutata anche l’integrità dell’intero sistema NAS e l’eventuale necessità di ripristinarlo da uno stato attendibile.

Gli indicatori pubblicati comprendono processi sconosciuti avviati da Plex, nomi quali myawesomeproxy, mylovelyminer e x12345, librerie .so o .dll inattese nella directory dei codec, connessioni verso proxystream.st e consumo elevato di CPU senza riproduzioni multimediali. Gli amministratori devono inoltre disconnettere le sessioni Plex, modificare le password e ruotare i token o le credenziali potenzialmente accessibili attraverso il NAS, comprese quelle associate a servizi cloud e procedure di backup. Se l’accesso remoto non è indispensabile, QNAP raccomanda di disabilitarlo e rimuovere l’inoltro della porta 32400; quando necessario, è preferibile utilizzare una VPN. La società sottolinea così che aggiornamento e risposta all’incidente sono due operazioni differenti: la patch impedisce nuovi sfruttamenti della vulnerabilità, mentre la bonifica deve affrontare le conseguenze di un accesso già avvenuto.

Veeam Software Appliance non si avvia su alcuni AMD EPYC per un errore jitterentropy

Il secondo problema riguarda Veeam Software Appliance 13.1 e versioni successive, distribuito come ambiente Linux preconfigurato per eseguire Veeam Backup & Replication. Nel bollettino KB4960, pubblicato il 4 novembre 2026, Veeam segnala che alcune macchine virtuali ospitate su processori AMD EPYC 7262, 7302 e 7F72 possono fallire l’avvio dopo un riavvio ordinario o un aggiornamento che installa un nuovo kernel. Il problema deriva dal controllo di integrità jitterentropy, eseguito nelle prime fasi del boot quando il sistema opera in modalità FIPS. Su determinate configurazioni, il test crittografico fallisce in maniera intermittente e il kernel interrompe l’avvio con il messaggio «Kernel panic – not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9». L’errore nasce dal comportamento del kernel Linux utilizzato dall’appliance e, secondo la documentazione Veeam, non dispone ancora di una correzione per quella specifica versione.

La soluzione preferita consiste nel ridistribuire l’appliance su un host con processore differente, non interessato dal problema. Quando questa possibilità non esiste, Veeam consiglia di disattivare gli aggiornamenti automatici dell’appliance, installarli manualmente e monitorare ogni riavvio. Se si verifica il kernel panic, occorre spegnere completamente la macchina virtuale e riaccenderla: il semplice riavvio del sistema operativo guest non consente il recupero. Una volta completato correttamente il boot, Veeam indica che non sono attesi ulteriori errori durante il normale funzionamento di Backup & Replication. La limitazione sugli aggiornamenti automatici deve tuttavia essere gestita come misura temporanea e controllata, perché lasciare sistemi di backup senza aggiornamenti di sicurezza rappresenta un rischio aggiuntivo. Il problema è quindi particolarmente rilevante negli ambienti virtualizzati dove le appliance devono riavviarsi automaticamente dopo manutenzioni e aggiornamenti programmati.

Continua con:

CISA inserisce quattro falle Plex nel KEV e AWS corregge due problemi di accesso

Kernel Linux, falla TCP CVSS 9,8: AWS rilascia patch per EC2 ed EKS

Veeam distribuisce anche le patch per CVE-2026-98432, falla critica del kernel Linux

In parallelo ai problemi di avvio, Veeam pubblica il 6 novembre il bollettino KB4966 dedicato a CVE-2026-98432, una vulnerabilità use-after-free nel codice TCP/IPv4 del kernel Linux, classificata con punteggio CVSS 9,8. Il difetto può provocare denial of service o corruzione della memoria, con conseguenze che dipendono dalle condizioni di sfruttamento e dalla configurazione di rete. Sono interessati diversi componenti Veeam che incorporano un kernel Linux, comprese Software Appliance 13.1, Infrastructure Appliance 13.1, determinate appliance ausiliarie e componenti impiegati per ripristini e servizi cloud. Veeam specifica che dal 2 novembre è disponibile nei repository un kernel corretto per le appliance 13.1, identificato come 5.14.0-570.60.1+27.2.el9_6_ciq. Gli aggiornamenti vengono distribuiti tramite Veeam Updater oppure attraverso correzioni private, a seconda del prodotto e della versione. Per alcune appliance ausiliarie della serie Backup & Replication 12.3, il rilascio della correzione privata risulta ancora in preparazione.

La presenza simultanea dei due problemi richiede attenzione nella pianificazione delle manutenzioni: il kernel deve essere aggiornato per chiudere la vulnerabilità critica, ma un riavvio non presidiato può lasciare indisponibile l’appliance su determinati host AMD EPYC. Gli amministratori devono quindi verificare la versione del kernel, identificare i sistemi che utilizzano i processori segnalati e predisporre un percorso di recupero prima di applicare le correzioni. La documentazione ufficiale distingue chiaramente le due condizioni: KB4960 descrive il kernel panic su AMD EPYC, mentre KB4966 elenca i componenti interessati da CVE-2026-98432 e le relative patch. QNAP e Veeam mostrano due rischi differenti per la continuità dei dati: nel primo caso un’applicazione vulnerabile può trasformare un NAS in un sistema compromesso; nel secondo, una criticità del kernel può impedire l’avvio di una piattaforma destinata proprio al ripristino dei sistemi.