Acronis Backup CVE-2026-87886: un tenant ottiene root sull'intero host cPanel

L'unico controllo che ogni manuale anti-ransomware ti dice di rinforzare è il backup. Copie immutabili, vault offline, restore testati: il senso è che quando tutto il resto è cifrato, il backup è la cosa che sopravvive. Vale allora la pena fermarsi sulla forma di CVE-2026-87886: una falla nel plugin Acronis Backup per cPanel & WHM che permette a un utente locale a bassi privilegi di diventare root. Lo strumento che hai installato per sopravvivere a un attacco è lo strumento che consegna la macchina.

CISA l'ha aggiunta al catalogo Known Exploited Vulnerabilities il 16 settembre 2026, citando sfruttamento attivo. Acronis stessa ha confermato che gli attacchi sono reali ma "limitati e mirati" e — come ormai è la norma nel day zero — non ha pubblicato dettagli tecnici. Quella combinazione, un agente di backup con root sulla superficie più densamente multi-tenant dell'hosting, è il motivo per cui questo 7.8 si comporta come qualcosa di peggio.

Cos'è davvero CVE-2026-87886

La causa radice è banale e, per un software di backup, quasi tradizionale: permessi di file predefiniti errati (CWE-276). Un componente che il plugin distribuisce ed esegue con privilegi elevati resta scrivibile — o raggiungibile — da un account non privilegiato. Un attaccante che ha già un punto d'appoggio a bassi privilegi sul server modifica o inserisce un file che il processo di backup privilegiato poi esegue o considera affidabile, e il confine di privilegio crolla fino a root.

I fatti verificati, dall'advisory Acronis SEC-10986 e dalla voce KEV:

Attributo	Valore
CVE	CVE-2026-87886
CVSS 3.1	7.8 (Alta)
Debolezza	CWE-276 — Incorrect Default Permissions
Vettore	Locale, richiede bassi privilegi, nessuna interazione utente
Interessati	Plugin Acronis Backup per cPanel & WHM (Linux) < build 1.9.3.1021
	Estensione Acronis Backup per Plesk (Linux) < build 1.8.11.638
Corretto in	cPanel & WHM: 1.9.3 HF3 (build 1.9.3.1021) · Plesk: 1.8.11.638
Sfruttata	Sì — attacchi limitati e mirati contro il plugin per cPanel & WHM
Aggiunta al KEV	2026-09-16

"Locale, richiede bassi privilegi" è la frase che fa rinviare un CVE dalla maggior parte delle code di triage, perché sembra dire che l'attaccante deve già essere dentro. Su un server dedicato è un'obiezione legittima. Su un nodo di shared hosting è l'intero modello di business: quella macchina è deliberatamente popolata da centinaia di tenant a bassi privilegi che hanno comprato esattamente il punto d'appoggio da cui questo exploit parte. Un account cPanel compromesso o malevolo, una web app PHP debole su un solo vhost, e l'attaccante si trova precisamente dove CVE-2026-87886 comincia. L'escalation a root possiede poi ogni altro tenant sulla macchina.

Perché "attaccare il backup" è tutto il piano, non una nota a piè di pagina

Non è un bug isolato; è l'ultima voce di una lunga serie. I prodotti di backup eseguono per progetto daemon e servizi privilegiati — devono leggere ogni file per proteggerlo — il che rende la loro superficie d'attacco locale insolitamente preziosa. La stessa classe ricorre in tutto il mercato: Kaseya Unitrends distribuiva un file world-writable che permetteva a un utente locale di eseguire codice ed escalare (CVE-2021-43034); Veeam Backup & Replication portava una local privilege escalation (CVE-2026-21672); CloudBerry Backup consentiva a un utente normale di escalare tramite un'azione pre/post-backup (CVE-2019-15720). Il pattern servizio-privilegiato-più-permessi-larghi è un elemento permanente della categoria.

Gli attaccanti sanno perché il bersaglio vale lo sforzo, e i numeri sono netti. Nel report Sophos State of Ransomware 2026, il 94% delle organizzazioni colpite da ransomware ha dichiarato che gli attaccanti hanno tentato di compromettere i backup durante l'attacco, e quei tentativi sono riusciti nel 57% dei casi. Il tornaconto non è sottile: quando i backup cadono insieme a tutto il resto, i costi mediani di ripristino sono circa otto volte più alti rispetto alle vittime i cui backup restano intatti.

"Abbiamo backup offline e immutabili, quindi il ransomware non è un rischio esistenziale per noi." — un CISO ragionevole, che descrive un controllo il cui agente di gestione gira come root su una macchina piena di tenant non fidati.

Quella frase è vera esattamente fino a quando l'agente di backup non diventa esso stesso la primitiva di privilege escalation. Il piano che gli attaccanti eseguono non è "cifra e spera che la vittima non abbia backup". È "ottieni un punto d'appoggio, escala attraverso qualunque servizio privilegiato sia più lasco, neutralizza prima il ripristino, poi cifra". CVE-2026-87886 è un secondo passo pronto all'uso per quel piano sulla classe di server più affollata di internet.

Il raggio d'impatto multi-tenant

Su un nodo cPanel/WHM condiviso l'escalation non compromette un solo account: cambia chi è l'attaccante sull'intera macchina.

• Ogni vhost, ogni tenant. Root legge ogni home directory, ogni wp-config.php, ogni credenziale di database, ogni chiave API memorizzata sulla macchina.
• I backup di tutti loro. L'agente Acronis ha, per funzione, accesso in lettura/scrittura allo store di backup di ogni account che protegge. Root sull'agente è root sul punto di ripristino di tutti.
• Le credenziali del provider. I nodi cPanel/WHM contengono token API verso il control plane dell'hosting, il DNS e spesso la gerarchia dei reseller — il pivot da una macchina all'intero parco.
• Una posizione fidata per la fase successiva. Da root, l'attaccante può manomettere i backup in silenzio, aspettare e detonare quando decide — la cadenza della doppia estorsione che rende reale il moltiplicatore di costi Sophos.

La parte scomoda è cosa succede alle tue prove una volta raggiunta quella root. I log locali di un host compromesso, la cronologia dei job dell'agente di backup, l'audit trail di cPanel — tutto è ora scritto dall'attaccante. Gli incident responder che ricostruiscono l'intrusione dalla telemetria on-box stanno, nel senso più letterale, leggendo una dichiarazione che l'avversario era libero di modificare.

Remediation

CVE-2026-87886 è sfruttata ed è nel KEV, quindi sotto i livelli risk-based della BOD 26-04 di CISA appartiene al secchio della remediation rapida, non alla finestra di patch del mese prossimo. Lavora il report dall'alto verso il basso.

1. Sono interessato?

Verifica la build del plugin/estensione installata su ogni nodo cPanel/WHM e Plesk:

# cPanel & WHM
cat /usr/local/cpanel/3rdparty/acronis/VERSION 2>/dev/null
rpm -qa | grep -i acronis
# Plesk
plesk bin extension --list | grep -i acronis

Sei esposto se il plugin per cPanel & WHM è sotto la build 1.9.3.1021 o l'estensione Plesk è sotto la 1.8.11.638. Lo sfruttamento finora ha colpito specificamente il plugin per cPanel & WHM — tratta quei nodi come priorità massima.

2. Patch — versioni corrette esatte.

Aggiorna al plugin Acronis Backup per cPanel & WHM 1.9.3 HF3 (build 1.9.3.1021) e all'estensione Acronis Backup per Plesk 1.8.11.638 o successive, secondo l'advisory SEC-10986. È l'unica correzione reale — la falla è nei permessi dei file distribuiti, quindi solo la build corretta la rimuove.

3. Non puoi applicare la patch subito? Controlli compensativi.

• Restringi i permessi sulle directory del plugin e sui file di proprietà del servizio: nessuna scrittura per gruppo/altri su ciò che l'agente privilegiato legge o esegue; verifica i file world-writable sotto il path di installazione Acronis (find <acronis_path> -perm -0002 -type f).
• Limita chi può raggiungere la macchina a bassi privilegi: sospendi o isola ogni account tenant di cui non puoi rispondere finché la finestra è aperta.
• Se possibile, ferma il servizio privilegiato del plugin fino alla patch — un backup in pausa è recuperabile; un nodo con root altrui no.

4. Caccia alla compromissione.

Assumi che il punto d'appoggio preceda la patch. Mappa su MITRE ATT&CK e caccia off-box dove possibile:

• T1068 / T1222 (Exploitation for Privilege Escalation / File & Directory Permission Modification): cerca utenti non privilegiati che scrivono su path di proprietà del servizio Acronis, seguiti da un processo dello stesso utente che si riesegue come root. Le watch auditd sul path di installazione lo intercettano; un attaccante con root può cancellare l'audit locale, quindi invia questi eventi a un collector remoto.
• T1490 / T1485 (Inhibit System Recovery / Data Destruction): cancellazioni di backup impreviste, modifiche alle policy di retention o annullamenti di job nella console Acronis — soprattutto raggruppati subito prima di un evento di cifratura.
• T1078 (Valid Accounts): accessi cross-tenant, nuovi login WHM/root da sorgenti insolite, account reseller appena creati.
• T1041 (Exfiltration Over C2): volume in uscita sostenuto o connessioni verso ASN mai visti prima da un nodo il cui egress normale è ristretto (aggiornamenti, controlli di licenza, target di backup che hai definito).

5. Eradica e verifica.

Se trovi prove di escalation, la patch non è remediation. La compromissione a livello root di un host multi-tenant significa: ricostruisci il nodo invece di ripulirlo sul posto; ruota ogni credenziale che la macchina poteva leggere — password DB dei tenant, token API, chiavi del control plane e del DNS, chiavi SSH; e verifica che i backup ripristinino a uno stato noto-buono da una copia offline, partendo dal presupposto che quelle online fossero raggiungibili. Conferma la pulizia dopo la ricostruzione, non prima.

Dove si colloca Zero Hunt: il filo è l'unico testimone onesto

Tutto quanto sopra ruota attorno a un fatto duro: una volta che CVE-2026-87886 dà all'attaccante root sull'host di backup, non ci si può più fidare che l'host racconti cosa gli è successo. La cronologia dei job dell'agente, i log locali, l'audit trail — tutto scrivibile dall'avversario. È esattamente lo scenario per cui è stato costruito il pilastro AI Traffic Analysis di Zero Hunt. Il modello di deep learning gira sulla GPU dell'appliance con quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) a un baseline di 2.7+ Gbit/s, leggendo la rete mentre l'attività accade — non nel digest SIEM di domani che la macchina compromessa ha contribuito a scrivere. La testa di fingerprinting applicativo sa che aspetto ha il traffico normale di Acronis e cPanel, così una shell interattiva, un beacon verso un ASN mai visto, un fan-out laterale cross-tenant o la raffica di cancellazioni dello store di backup prima di una cifratura emergono nel momento in cui appaiono sul filo — l'unica superficie che un'appliance con root altrui non può riscrivere.

Questo risponde al rilevamento. La domanda precedente — questa privilege escalation è davvero raggiungibile sulla tua build, o è un 7.8 che puoi rimandare senza rischi? — è dove segue lo swarm dell'AI Generative Pentest: una campagna change-triggered prende un punto d'appoggio realistico a bassi privilegi ed esegue l'escalation a root contro la tua versione specifica, con l'exploit scritto per-target da un LLM locale (mai prelevato da un PoC pubblico), backtestato nell'AI Gym prima di toccare la produzione, e ogni finding firmato ECDSA per una catena di custodia che l'host compromesso non può falsificare. E poiché i backup sono un controllo di resilienza obbligatorio sotto NIS2, DORA e ISO 27001, il layer di compliance di Zero Hunt mappa quel singolo finding su tutti i 32 framework insieme — così "dimostra che il tuo controllo di ripristino non è esso stesso la via d'attacco" diventa evidenza firmata, non un'affermazione.

La lezione di CVE-2026-87886 è più vecchia del CVE: un controllo che non puoi osservare in modo indipendente è un controllo di cui ti fidi sulla fiducia. Per il modello dell'attaccante che punta prima al ripristino, vedi la nostra analisi sul ransomware di sola esfiltrazione e sull'escalation a root nello shared hosting.