Il plugin Acronis Backup cPanel (CVE-2026-87886) è sfruttato

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Sicurezza delle infrastrutture per team enterprise in USA e UE

La risposta breve

Cosa ha divulgato Acronis

Il plugin Acronis Backup per cPanel & WHM e la relativa estensione per Plesk collegano un pannello di controllo di hosting all'infrastruttura di backup Acronis. Consentono agli amministratori di eseguire backup e ripristini di siti web, database, caselle di posta e interi server direttamente dal pannello — il che significa che il plugin gira con ampio accesso a file e processi della macchina. Un software così privilegiato è un bersaglio di alto valore: una debolezza al suo interno non resta confinata a un solo account.

A settembre 2026 Acronis ha divulgato CVE-2026-87886, un'escalation di privilegi locale radicata in permessi di file predefiniti non sicuri (CWE-276). Poiché alcuni file o directory installati dal plugin sono scrivibili o eseguibili da account che non dovrebbero avere quell'accesso, un attaccante autenticato che detiene già una posizione poco privilegiata sul server Linux può sfruttarli per elevare i privilegi — fino a root — senza alcuna interazione da parte di un utente legittimo. La falla ha un punteggio CVSS di 7.8 e Acronis descrive lo sfruttamento come a bassa complessità.

Punto cruciale: Acronis ha dichiarato che lo sfruttamento è stato rilevato in the wild in attacchi limitati e mirati contro il plugin cPanel & WHM; non ha osservato lo sfruttamento dell'estensione Plesk, che pure è interessata e va corretta. Poco dopo la divulgazione, la CISA ha aggiunto CVE-2026-87886 al proprio catalogo delle vulnerabilità note sfruttate il 16 settembre 2026, con scadenza al 19 settembre per le agenzie federali civili statunitensi — lo stesso trattamento riservato alle falle di massima gravità ben più clamorose del giorno, perché è l'uso reale, non il punteggio grezzo, a valere un inserimento nel KEV. La remediation è semplice: aggiornare il plugin al build corretto. La stessa disciplina di hardening che applichiamo su una piattaforma Cloud e DevOps — privilegio minimo, permessi di file stretti e una pipeline di patch rapida — è esattamente ciò che a questa falla è mancato.

Perché una falla «locale» è grave

È allettante archiviare una falla locale, autenticata e da 7.8 sotto i titoloni pre-autenticazione da 10.0 — e questo istinto è esattamente il modo in cui queste falle vengono sfruttate. Le intrusioni reali sono catene, non singoli passaggi. Gli attaccanti ottengono a basso costo un punto d'appoggio poco privilegiato: un'applicazione web vulnerabile, una chiave SSH trapelata, una web shell caricata tramite un CMS compromesso o semplicemente un account tenant su una macchina condivisa. Da solo, quel punto d'appoggio è limitato. Una falla di escalation dei privilegi è la seconda metà della catena — il passaggio che trasforma «posso eseguire codice come utente ristretto» in «possiedo la macchina».

Su un server di hosting multi-tenant quel raggio d'impatto è enorme. Root non significa un solo sito; significa ogni sito web, database e casella di posta sull'host, più il piano di controllo dei backup stesso. Proprio quest'ultimo punto rende un'escalation vicina ai backup particolarmente pericolosa: un attaccante che raggiunge il livello che gestisce i backup può leggerli, esfiltrarli o distruggerli, eliminando in silenzio la via di ripristino su cui un'organizzazione conta se segue un ransomware. Lo strumento acquistato per garantire la recuperabilità diventa il perno che la mina.

Nessuna configurazione ingegnosa corregge permessi di file non sicuri in codice di terze parti — i permessi corretti arrivano nel build con la patch, ecco perché aggiornare il plugin è l'intera remediation. Questo riporta il vero rischio alla velocità di patching del software che non hai scritto: plugin dei pannelli di controllo, agent di backup e add-on di gestione escono dalla tua cadenza di aggiornamento proprio perché sembrano infrastruttura anziché codice applicativo, ed è in questo divario che attende un'escalation sfruttata in the wild.

Cosa significa per i team software italiani

La prima lezione è che gli add-on privilegiati del tuo stack di hosting fanno parte della tua superficie d'attacco. I team inventariano e aggiornano i framework nei propri repository, poi trattano il pannello di controllo e i suoi plugin come una scatola nera che «funziona e basta». Ma agent di backup ed estensioni del pannello detengono alcuni degli accessi più potenti sul server, e una falla di permessi in uno di essi è una via diretta verso root. Tutto ciò che fai per irrobustire il codice applicativo — privilegio minimo, accesso minimo ai file, aggiornamenti tempestivi — deve estendersi al software di terze parti che sta sotto.

La seconda lezione riguarda la difesa in profondità, affinché un punto d'appoggio non sia fatale. Questa escalation rende solo dopo che un attaccante dispone già di una posizione poco privilegiata; quindi ogni controllo che rende quel primo appoggio più difficile o più rumoroso — isolare i tenant, limitare ciò che un processo web può eseguire, monitorare cambi di privilegi inattesi e tenere il piano di backup su credenziali e reti separate — limita direttamente il danno. Dai per scontato che i primi punti d'appoggio accadranno e progetta in modo che arrivare a root richieda più di un plugin non aggiornato.

Terzo, questo è un evento di conformità e di garanzia di ripristino, non solo un ticket operativo. Un compromesso root di un server che ospita siti e caselle di posta di clienti ricade nelle aspettative di GDPR, NIS2 e DORA in UE — e poiché il livello di backup è nel perimetro, tocca anche la tua capacità di dimostrare che il ripristino è intatto. Poter mostrare quali host eseguivano il plugin interessato, quando hai applicato la patch e che i backup erano verificati e ad accesso controllato è la documentazione che auditor e autorità chiederanno per prima.

Cosa fare ora

1. Inventaria gli host interessati. Trova ogni server Linux che esegue cPanel & WHM o Plesk con il plugin o l'estensione Acronis Backup installati — incluse macchine di staging, legacy e reseller fuori dall'elenco principale degli asset.
2. Aggiorna subito il plugin. Installa il build 1.9.3.1021 (1.9.3 HF3) per cPanel & WHM o 1.8.11.638 (1.8.11) per Plesk, o successivo. Non esiste un workaround sui permessi, quindi trattalo come una modifica d'emergenza. Applica la patch anche a Plesk, sebbene sia stato osservato solo lo sfruttamento di cPanel/WHM.
3. Dai la caccia all'escalation. Esamina i log di server, sudo e plugin per cambi di privilegi inattesi, nuovi file o cron job di proprietà di root e attività di account poco privilegiati che all'improvviso hanno agito come root. Un intruso root può aver manomesso quei log: verifica su più fonti.
4. Verifica i backup. Conferma che i backup siano presenti, ripristinabili e archiviati con credenziali e accesso di rete separati dagli host che proteggono — lo scopo di un attacco al livello di backup è eliminare l'opzione di ripristino prima della fase successiva.
5. Contieni, ruota, poi testa. Se un host era raggiungibile e non aggiornato, trattalo come potenzialmente compromesso: ruota credenziali, chiavi e segreti che deteneva e aggiungi i pannelli di controllo hosting e i loro plugin al perimetro del prossimo penetration test, così l'infrastruttura privilegiata smette di essere un punto cieco.

Domande frequenti

Fonti

Help Net Security — Acronis backup plugin flaw exploited in targeted attacks (CVE-2026-87886)
Security Affairs — CISA Adds Acronis Backup, Cisco ISE, and Google Pixel Flaws to KEV Catalog
CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog