Acronis sotto exploit e WordPress backdoor: plugin fidati diventano il punto d’ingresso

🛡️ Executive Summary

• CVE-2026-87886 consente a un utente Linux con privilegi ridotti di elevarli sui server che usano i plugin Acronis per cPanel, WHM e Plesk.
• Admin Menu Editor Pro 2.35 e alcune copie della 2.36 sono state distribuite dal server ufficiale con una web shell dopo la compromissione del vendor.
• Il primo caso richiede patch immediata; nel secondo aggiornare non basta: i siti interessati devono essere trattati come già compromessi e bonificati.

Due incidenti diversi mostrano lo stesso problema strutturale nelle infrastrutture web: un componente considerato affidabile può diventare il punto dal quale un attaccante raggiunge privilegi molto più elevati. Acronis ha corretto CVE-2026-87886, vulnerabilità locale di privilege escalation nei propri plugin di backup per cPanel & WHM e Plesk, dichiarando di avere rilevato un possibile sfruttamento in attacchi mirati. Nello stesso momento, il canale ufficiale di distribuzione di Admin Menu Editor Pro è stato compromesso e ha consegnato versioni WordPress contenenti una web shell. Nel primo caso l’attaccante deve possedere già un accesso limitato al server; nel secondo è stato invece lo stesso meccanismo di aggiornamento fidato a portare la backdoor dentro i siti.

CVE-2026-87886 trasforma un accesso limitato al server in un problema per l’intero hosting

Acronis assegna a CVE-2026-87886 un punteggio CVSS 7.8 e la classifica come vulnerabilità di escalation locale dei privilegi. Sono interessati Acronis Backup plugin for cPanel & WHM nelle build precedenti alla 1.9.3.1021, corretta con 1.9.3 HF3, e Acronis Backup extension for Plesk prima della build 1.8.11.638, corretta nella versione 1.8.11. L’advisory ufficiale Acronis SEC-10986 precisa che un soggetto con privilegi ridotti sul sistema Linux può aumentare il proprio livello di accesso senza richiedere interazione dell’utente. Acronis non ha ancora pubblicato la causa tecnica della falla né indicatori specifici di compromissione, ma ha dichiarato di avere rilevato exploitation in the wild in attacchi limitati e mirati contro installazioni cPanel & WHM. La distinzione è importante: non si tratta di una RCE pre-authentication che consente a chiunque su Internet di conquistare automaticamente un server. Serve un punto d’appoggio locale precedente. In un ambiente di shared hosting, però, questa condizione non riduce necessariamente il rischio quanto potrebbe sembrare, perché account hosting compromessi, credenziali rubate o applicazioni già violate possono fornire proprio il livello iniziale necessario. Soltanto una settimana prima, cPanel aveva corretto CVE-2026-67401, capace di trasformare un account hosting autenticato in esecuzione di codice come root, mostrando quanto il confine tra tenant e sistema operativo sia critico nelle infrastrutture multiutente.

Il plugin di backup è sensibile perché opera dove risiedono tutti i dati del server

L’asimmetria di CVE-2026-87886 deriva soprattutto dal ruolo del componente vulnerabile. Un plugin di backup integrato con un pannello hosting non gestisce una funzione marginale: deve poter leggere, archiviare e ripristinare file, database, mailbox e interi account. Per svolgere queste operazioni lavora necessariamente vicino al confine dei privilegi amministrativi. Una falla locale in questo livello diventa quindi più importante del semplice punteggio CVSS, soprattutto sui server che ospitano siti appartenenti a clienti differenti. Acronis afferma che l’evidenza di sfruttamento deriva da un singolo report relativo a un cliente “potenzialmente interessato”, per cui non esistono al momento elementi sufficienti per parlare di una campagna estesa o automatizzata. La priorità operativa resta comunque l’aggiornamento alle build corrette o successive. Le release note ufficiali del plugin cPanel mostrano inoltre che Acronis ha già portato il ramo alla versione 1.9.4 build 1022; chi sceglie la release più recente deve però verificare anche i relativi prerequisiti dell’ambiente Acronis Cyber Cloud. Patchare chiude la vulnerabilità nota, ma sui sistemi che presentano accessi locali sospetti l’assenza di IoC pubblicati non può essere interpretata come prova che il server non sia stato compromesso.

Leggi anche: WordPress blocca gli aggiornamenti plugin ad alto rischio prima che raggiungano gli utenti

Admin Menu Editor Pro dimostra il rischio opposto: l’aggiornamento stesso era malevolo

Il secondo incidente elimina persino il presupposto del plugin vulnerabile. Il 14 settembre 2026 un attaccante ha ottenuto accesso all’infrastruttura che ospitava adminmenueditor.com e ha caricato una versione modificata di Admin Menu Editor Pro 2.35, presentata agli utenti come normale aggiornamento. Il developer Janis Elsts conferma direttamente che il pacchetto conteneva il nuovo file includes/wp-user-consent.php, capace di installare una web shell sul sito WordPress. Dopo la scoperta, Elsts ha rimosso la release compromessa e pubblicato una versione 2.36 pulita; poche ore dopo anche quella distribuzione è stata nuovamente alterata. L’indagine ha fatto emergere la possibilità che l’aggressore disponesse di accesso root al server del vendor, tanto da convincere lo sviluppatore a portare offline l’intera infrastruttura e ricostruirla. È precisamente ciò che distingue un attacco supply chain da una normale vulnerabilità WordPress: l’amministratore non ha installato software proveniente da una fonte pirata né ignorato necessariamente una patch. Ha ricevuto codice malevolo dal canale dal quale normalmente si aspetta gli aggiornamenti legittimi. Il precedente di BdThemes aveva già mostrato come la compromissione dell’infrastruttura upstream possa creare amministratori nascosti e web shell sui siti WordPress; Admin Menu Editor Pro porta lo stesso problema direttamente dentro il pacchetto distribuito dal produttore.

Circa 1.500 siti hanno ricevuto la versione compromessa ma il perimetro resta incerto

Secondo le informazioni fornite dal developer, circa 230 clienti hanno installato la prima versione malevola sui propri ambienti, corrispondenti ad almeno 1.500 siti WordPress, perché molti clienti gestiscono più installazioni. La cifra non va però interpretata come conteggio definitivo delle vittime. Elsts indica nella propria comunicazione ufficiale altri circa 300 clienti potenzialmente interessati sulla base dei download effettuati intorno alla finestra dell’incidente, mentre per la seconda compromissione della 2.36 non dispone ancora di una lista affidabile. Chi ha installato la 2.35 deve trattare il sito come compromesso; per la 2.36 il developer parla invece di possibile compromissione, soprattutto per i pacchetti scaricati dopo le 19:00 UTC del 14 settembre. La versione 2.34 viene considerata pulita sulla base delle informazioni attualmente disponibili. Il caso è particolarmente rilevante perché la versione gratuita di Admin Menu Editor distribuita attraverso WordPress.org non risulta coinvolta: l’incidente interessa la versione Pro, distribuita attraverso l’infrastruttura privata del vendor. È proprio la differenza che rende significativo il recente tentativo di WordPress.org di inserire controlli automatici nel proprio canale di aggiornamento.

La web shell rende insufficiente reinstallare semplicemente una versione pulita

Il developer elenca indicatori estremamente concreti. Oltre a includes/wp-user-consent.php, gli amministratori devono cercare una nuova directory /wp-content/object-cache, eventuali opzioni wp_ocache... o _wp_ocache_... nella tabella wp_options, utenti con login formato da wp_ seguito da caratteri esadecimali, file anomali dentro /wp-content/mu-plugins e l’evento WP-Cron _wp_cconsent_tick. L’utente malevolo può inoltre non apparire nella normale dashboard, rendendo necessaria la verifica diretta della tabella wp_users. Il punto operativo è ancora più importante: la presenza della web shell implica che l’aggressore possa avere ottenuto controllo completo del sito, quindi sostituire il plugin con una copia pulita non equivale a una bonifica. Elsts raccomanda, quando possibile, di ripristinare il sito da un backup precedente al 14 settembre, eliminare il plugin coinvolto, verificare file e database, cambiare le password di tutti gli utenti WordPress, rigenerare chiavi e salt in wp-config.php e ruotare le altre credenziali conservate sul sito, comprese quelle per database, FTP/SFTP, pannello hosting e API di terze parti. È la stessa ragione per cui nelle campagne come WP-SHELLSTORM la rimozione della vulnerabilità non eliminava automaticamente web shell e persistenza già depositate.

Continua con:

• cPanel, SAP e N-central: quando un account con privilegi limitati diventa il percorso verso il controllo del server
• BdThemes compromessa: la supply chain WordPress crea amministratori nascosti senza un normale update malevolo

Acronis e Admin Menu Editor mostrano due facce dello stesso confine di fiducia

CVE-2026-87886 e la compromissione di Admin Menu Editor Pro non devono essere confuse: la prima è una vulnerabilità locale di escalation dei privilegi in componenti Acronis e richiede già un accesso limitato al server; la seconda è un vero incidente supply chain nel quale l’infrastruttura del produttore ha distribuito direttamente software trojanizzato. La conseguenza difensiva, tuttavia, converge sullo stesso principio. I plugin amministrativi e di backup non sono semplici estensioni funzionali: operano vicino ai dati e ai privilegi più sensibili dell’infrastruttura. Quando il loro codice è vulnerabile oppure il loro canale di distribuzione viene compromesso, la fiducia concessa dal sistema diventa il moltiplicatore dell’attacco. Nel caso Acronis la priorità è portare immediatamente le installazioni alle build corrette e verificare eventuali segnali di escalation sui server che potrebbero avere già subito un accesso locale. Nel caso Admin Menu Editor Pro il punto di partenza è ancora più netto: chi ha installato la 2.35 deve assumere la compromissione e procedere alla risposta all’incidente, perché aggiornare il componente non rimuove una web shell che ha già consegnato il sito all’attaccante.