Acronis patcha CVE-2026-87886: exploit in-the-wild nel plugin cPanel

Acronis ha rilasciato il 15 settembre 2026 patch urgenti per una vulnerabilità di local privilege escalation nel suo Backup plugin per cPanel & WHM e nell'estensione per Plesk. La falla, identificata come CVE-2026-87886 con punteggio CVSS 7.8 secondo l'advisory del vendor, è già stata sfruttata in attacchi mirati contro deployment cPanel & WHM, costringendo gli amministratori a una verifica immediata delle build installate che nasconde una complicazione operativa non banale: la scelta tra due percorsi di aggiornamento con prerequisiti di backend diversi.

La falla: da permessi file difettosi a controllo totale locale

La vulnerabilità risiede in insecure file permissions nel codice del plugin Acronis per cPanel & WHM e nell'estensione per Plesk. Un attaccante che abbia già ottenuto accesso locale con privilegi limitati — tipicamente tramite un account utente compromesso — può sfruttare questi permessi per elevare i propri diritti sul sistema, senza necessità di interazione da parte dell'utente legittimo.

La condizione è particolarmente insidiosa negli ambienti di hosting condiviso, dove la compromissione di un singolo account cliente può diventare il punto di partenza per muoversi lateralmente all'interno del server. Il plugin di backup, per sua natura, opera con privilegi elevati per accedere ai dati degli utenti: questa architettura lo rende un obiettivo privilegiato per chi cerca di scalare i permessi.

Secondo le fonti, la vulnerabilità è classificata con punteggio CVSS 7.8 da Acronis, posizionandola nella fascia alta della scala senza raggiungere la criticità massima. La distinzione è rilevante: la natura locale della falla richiede un prerequisito di accesso iniziale che riduce la superficie di attacco rispetto a una vulnerabilità remotamente sfruttabile, ma non ne sminuisce il pericolo in ambienti multi-tenant dove la compromissione di account utente è un evento ricorrente.

Attacchi confermati, ma su base incerta

Acronis ha comunicato che l'exploitazione è stata rilevata in-the-wild. Secondo SecurityWeek, che riporta una citazione diretta dall'advisory del vendor:

"Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments"

Help Net Security e BleepingComputer convergono sullo stesso dato, con una precisazione cruciale aggiunta da quest'ultima: la valutazione si basa su "a single report from a potentially affected customer". Questo elemento, documentato esplicitamente nella fonte, costituisce un limite strutturale della claim: non si tratta di una campagna osservata su larga scala o di pattern multipli confermati indipendentemente, ma di un'unica segnalazione che Acronis ha ritenuto sufficiente per dichiarare lo stato di exploitazione attiva.

Non emergono, allo stato attuale, evidenze di sfruttamento su deployment Plesk. La distinzione tra i due pannelli di controllo è operativa: sebbene condividano lo stesso codice vulnerabile nel componente Acronis, solo l'ecosistema cPanel & WHM risulta essere stato bersaglio di attacchi confermati.

Il labirinto delle build: perché 1.9.3 non basta

La correzione non segue il percorso lineare che gli amministratori potrebbero atteso. Non è sufficiente indicare "versione 1.9.3" come sicura: la build esatta determina la vulnerabilità o meno del sistema.

Secondo WindowsForum, che ha analizzato i dati pubblici di Acronis, la build 1.9.3.998 — tecnicamente appartenente alla linea 1.9.3 — rimane al di sotto della soglia correttiva. Il fix arriva con la build 1.9.3.1021, distribuita come hotfix 1.9.3 HF3. Per l'estensione Plesk, la soglia è la build 1.8.11.638.

Si aggiunge un ulteriore strato di complessità. Esiste una versione 1.9.4 build 1022 che include il fix, ma introduce prerequisiti di backend diversi: richiede Acronis Cyber Cloud e l'agente di protezione alla versione C26.08, contro il C26.02 sufficiente per la 1.9.3.1021. Gli amministratori con infrastrutture legacy o vincoli di aggiornamento del backend si trovano così di fronte a una scelta forzata: rimanere sulla linea 1.9.3 con il minimo impatto operativo, o abbracciare la 1.9.4 con un più ampio ciclo di upgrade della piattaforma sottostante.

Questa articolazione — build anziché versioni di marketing, prerequisiti di backend che biforcano i percorsi — è tipica del software enterprise ma raramente viene comunicata con la chiarezza necessaria agli operatori che devono agire in urgenza. Il rischio concreto è che un amministratore aggiorni alla "1.9.3" senza verificare la build, rimanendo esposto con la sensazione di aver corretto il problema.

Cosa fare adesso

• Verificare la build esatta installata del plugin Acronis per cPanel & WHM o dell'estensione Plesk: le soglie minime di sicurezza sono rispettivamente 1.9.3.1021 e 1.8.11.638
• Se il backend Acronis Cyber Cloud è alla versione C26.02, applicare il percorso 1.9.3 HF3 (build 1021); se è già a C26.08 o superiore, valutare il passaggio a 1.9.4 build 1022
• Riconoscere che Acronis non ha pubblicato indicatori di compromesso né dettagli tecnici dell'exploit, rendendo impossibile il threat hunting retroattivo basato su signature: la verifica della build installata è l'unica azione concreta disponibile
• Per i deployment cPanel & WHM, considerare prioritaria la verifica dato che costituiscono l'unico bersaglio con exploitazione confermata; per Plesk, mantenere il normale ciclo di patching senza allarmismo aggiuntivo

Il vuoto operativo senza IoC

L'assenza di indicatori di compromesso pubblicati da Acronis lascia gli amministratori in una posizione di asimmetria informativa. Non è possibile determinare se un server sia stato compromesso in passato tramite questa falla, né costruire regole di rilevamento per future intrusioni. La strategia difensiva si riduce al patching preventivo, senza la possibilità di una fase di bonifica basata su evidenze.

Questa scelta comunicativa da parte del vendor — comune in situazioni di exploitazione attiva dove la divulgazione di dettagli tecnici rischierebbe di amplificare gli attacchi — penalizza tuttavia gli operatori che gestiscono infrastrutture già potenzialmente compromesse. L'unica certezza che resta è la build installata: al di sotto delle soglie indicate, il sistema è vulnerabile; al di sopra, è corretto.

Perché il settore hosting è nel mirino

I componenti di backup integrati nei pannelli di controllo come cPanel e Plesk rappresentano un punto di attrazione specifico per gli attaccanti in ambienti multi-tenant. La loro funzione richiede accesso privilegiato ai dati di tutti gli account ospitati sul server, il che significa che una compromissione del plugin si traduce in potenziale esposizione trasversale.

La natura locale della vulnerabilità non diminuisce il rischio per i provider di hosting: in un contesto dove account cliente vengono regolarmente compromessi tramite credenziali rubate o applicazioni vulnerabili, il passaggio da "utente limitato" a "privilegi elevati" tramite un componente di backup è un percorso di attacco ben definito. La conferma di exploitazione in-the-wild, anche su base di singolo report, legittima la valutazione di questo vettore come attivamente sfruttato da operatori mirati.

La distinzione tra "attacchi limitati e mirati" e una campagna su larga scala è rilevante per la prioritizzazione delle risorse, non per la severità della vulnerabilità in sé. Un attaccante mirato che sceglie deliberatamente target di valore — provider di hosting con centinaia o migliaia di account — può generare impatti di gran lunga superiori a un worm automatizzato che colpisce indiscriminatamente.

Lettura: il problema delle build invisibili

Il caso CVE-2026-87886 evidenzia una frattura sistemica nella comunicazione dei vendor di sicurezza: le versioni di marketing ("1.9.3", "1.8.11") vengono percepite come sufficienti dagli amministratori, mentre la realtà tecnica è determinata dalle build interne spesso trasparenti o di difficile consultazione. In una situazione di exploitazione attiva, questa opacità introduce latenza nel patching e falsi positivi di sicurezza.

Il prerequisito backend C26.02 versus C26.08 aggiunge un ulteriore vincolo che molti workflow di gestione patch non sono strutturati per gestire: la correzione di una vulnerabilità in un componente perimetrale obbliga a valutare lo stato di un'infrastruttura sottostante. Per gli MSP che gestiscono centinaia di deployment eterogenei, questo non è un dettaglio tecnico ma una variabile di pianificazione con impatto sui tempi di intervento.

La combinazione di exploit confermato, base di rilevamento incerta e complessità di patching crea uno scenario dove la sicurezza effettiva dipende più dalla precisione operativa che dalla rapidità di reazione. Aggiornare "subito" alla versione sbagliata è tecnicamente possibile; aggiornare correttamente richiede informazioni che i vendor non sempre rendono immediatamente accessibili.

Fonti

• https://www.securityweek.com/acronis-patches-exploited-vulnerability-in-cpanel-backup-plugin/
• https://www.helpnetsecurity.com/2026/09/16/acronis-backup-plugin-vulnerability-exploited-cve-2026-87886/
• https://www.bleepingcomputer.com/news/security/acronis-warns-of-actively-exploited-flaw-in-its-cpanel-backup-plugin/
• https://windowsforum.com/news/cve-2026-87886-acronis-cpanel-fix-is-build-1-9-3-1021.444528/
• https://podcast.securityweek.com/

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

Fonti