Acronis Backup: «requereix accés local», i aquest accés el vens tu als teus clients

Un CVSS de 7,8 amb l'etiqueta «local» és, a la majoria d'equips, el CVE que s'aparca. No és un deu, no entra per internet, cal ser a dins. Aquest raonament és correcte en un servidor amb un sol administrador. En un servidor d'allotjament, ser a dins és el que els venes als teus clients.

El dimarts 15 de setembre a les 15:30 UTC, Acronis va publicar l'avís SEC-10986. L'endemà, CISA va incloure el mateix CVE al seu catàleg de vulnerabilitats explotades i li va posar data límit: 19 de setembre. Tres dies. La versió curta de l'avís cap en una ratlla: «Local privilege escalation due to insecure file permissions».

Una frase i dos números de versió

L'avís complet d'Acronis és més curt que aquest paràgraf. Diu que afecta el connector d'Acronis Backup per a cPanel & WHM a Linux, corregit a la compilació 1.9.3.1021, i l'extensió per a Plesk, corregida a la 1.8.11.638. Li assigna CVSS 7,8 —severitat alta— amb el vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, el classifica com a CWE-276 (permisos per defecte incorrectes) i hi afegeix una frase: «Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments».

I prou. Al registre de l'avís, els camps de referències i de crèdits són buits. No hi ha ruta de fitxer, no hi ha permís concret, no hi ha indicador de compromís, no hi ha cap data des de la qual se sap que s'està explotant. Quan The Hacker News ho va preguntar, un portaveu d'Acronis va respondre que no tenia informació addicional per compartir. Les notes de la versió sí que són clares en el to: «This update contains fixes for 1 high-severity security vulnerability and should be installed immediately by all users». Un detall que l'avís sí que concreta: l'explotació observada és contra desplegaments de cPanel & WHM. Per a Plesk hi ha pedaç, però atacs reportats no.

El vector, llegit a poc a poc

Les dues sigles que decideixen la prioritat d'aquest CVE en qualsevol full de càlcul són AV:L (l'atacant ha de ser a la màquina) i PR:L (en té prou amb un compte sense privilegis). La resta del vector és la part dolenta: sense interacció de l'usuari, i confidencialitat, integritat i disponibilitat compromeses del tot. Traduït: impacte total sobre el component vulnerable. I com que aquest component s'instal·la com a root, la traducció pràctica és que qui tingui un compte qualsevol en aquest servidor acaba sent amo del servidor.

Ara recorda on viu aquest connector. Viu en panells d'allotjament. I en un servidor amb cPanel, cada compte que dones d'alta és un usuari del sistema. La documentació de cPanel no ho diu amb aquestes paraules, però sí que diu el que importa: en crear el compte, «the system creates new account UIDs and GIDs with a number between 1000 and 60000», amb un nom únic de setze caràcters o menys. Un UID i un GID propis són, a la pràctica, una línia a /etc/passwd amb el seu directori personal.

Amb això sobre la taula, «accés local amb privilegis baixos» deixa de ser una barrera i passa a ser un inventari. El té cada client a qui li venes allotjament. El té cada desenvolupador a qui vas donar SSH per pujar una botiga. I el té, sense haver pagat res, qualsevol que aconsegueixi executar codi PHP al WordPress desactualitzat de qualsevol d'aquests clients, perquè en la configuració habitual de cPanel —PHP-FPM per usuari o suPHP— aquest PHP corre com l'usuari d'aquest compte. L'esglaó que normalment costa setmanes de feina —passar de codi en un web aliè a la màquina sencera— el regala un permís de fitxer.

Per què aquest procés i no un altre

Hi ha una raó per la qual una fallada de permisos fa més mal en un agent de còpies que en gairebé qualsevol altre programari. El procediment d'instal·lació del manual del connector —revisió de maig de 2026— comença així: «Log in to the cPanel server as a system administrator or root user». I per crear manualment les funcions que decideixen què veu cada compte, ho repeteix: «Log on to the host as a root user». L'agent de còpies ho pot llegir tot per definició; per això el poses.

L'índex d'aquest mateix manual serveix d'inventari del que hi ha a l'abast d'aquest procés. Descàrrega i recuperació de dominis. De fitxers. D'abocaments de bases de dades. De bústies de correu. De filtres de correu. De reenviaments. I un capítol que es diu «Exporting the entire account». En una sola màquina d'allotjament, això són les dades, el correu i les bases de dades de tots els negocis que hi allotges.

El mateix manual hi afegeix la frase que tanca el raonament, i convé llegir-la sencera: «Only the server administrator has permission to manage backups on the web hosting server. Resellers and end users can only access and restore their data if the self-service recovery feature is available for their accounts». Aquesta frontera —l'administrador del servidor a una banda; revenedors i clients a l'altra, i només fins on tu els obris— és la que esborra un permís de fitxer mal posat. Siguem precisos amb el que no sabem: Acronis no diu que en aquests atacs es toquessin les còpies, i nosaltres tampoc no ho diem. El que diem és què hi ha a l'abast de qui arriba a root en aquesta màquina, que és una pregunta que cadascú pot respondre sense esperar més detalls del fabricant.

La cua de pedaços ordena pel número equivocat

Una cua de pedaços s'ordena gairebé sempre per dues columnes: el número del CVSS i si la fallada entra per xarxa. Aquest CVE perd en totes dues. I tanmateix CISA el va posar el 16 de setembre al catàleg de vulnerabilitats explotades amb data límit del 19 —tres dies—, la mateixa finestra que va donar aquell mateix dia a una fallada de Cisco Identity Services Engine que sí que és remota i sense autenticar. El catàleg ordena per una sola cosa, que és si algú ho està fent servir.

Aquella finestra de tres dies surt de la directiva BOD 26-04, del 10 de juny de 2026, que va substituir el termini únic per una taula amb quatre variables: exposició de l'actiu, presència al catàleg, automatització de l'exploit i impacte tècnic. I hi ha una casella que convé conèixer, perquè canvia la feina: quan a un termini se li afegeix «& forensic triage», l'obligació no és només aplicar el pedaç, sinó «complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised». L'entrada d'aquest CVE al catàleg porta aquesta marca.

La directiva obliga les agències federals nord-americanes i ningú més; la mateixa CISA ho diu: «While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities». No t'obliga, però t'està regalant el criteri de priorització d'algú que veu les dades d'explotació de mig món. Nosaltres el tractem com una cua d'entrada. Ja en vam escriure a propòsit d'Artifactory, on el CVE «mitjà» va entrar abans que el crític: la severitat descriu el dany possible, no la probabilitat que et toqui a tu aquesta setmana.

Què faríem aquest mateix matí

Si operes o mantens servidors amb cPanel/WHM o Plesk i tenen el connector d'Acronis, això és el que ordenaríem, en aquest ordre:

• Mira la versió exacta del paquet. La referència són les compilacions 1.9.3.1021 (cPanel & WHM) i 1.8.11.638 (Plesk); a les notes d'Acronis la correcció figura com a 1.9.3 HF3. Un rpm -q o un dpkg -l del paquet del connector resol la pregunta en deu segons per servidor.
• Comprova que el repositori del fabricant continua configurat. L'script d'instal·lació, segons el manual, «will register the Stable plugin repository on the system for further plugin updates via yum or apt utilities». Si aquest repositori va quedar fora en reinstal·lar el sistema, o si les actualitzacions desateses exclouen els paquets de tercers, el pedaç no arribarà tot sol per molt urgent que sigui.
• Compta quants usuaris reals té aquesta màquina. No comptes de panell: línies a /etc/passwd amb UID de 1000 en endavant, tinguin shell interactiu o no. A cPanel la majoria porten noshell o jailshell, i tant se val: per a aquesta fallada n'hi ha prou de poder executar codi com aquest usuari. Aquest número és la mida de la teva superfície «local».
• Fes el triatge encara que no t'obligui cap directiva. Sense indicadors publicats, el que queda és el de sempre i serveix: fitxers nous o amb propietari canviat als directoris de l'agent, binaris amb setuid apareguts les últimes setmanes, tasques programades d'usuaris d'allotjament, claus afegides a authorized_keys de root, i sessions des d'adreces que no són les teves. Si no guardes registres fora del mateix servidor, aquest és el dia que te n'assabentes.
• Comprova si les còpies continuen sent còpies quan aquesta màquina cau. És la pregunta de fons: si algú és root al servidor protegit, pot esborrar o alterar el que ja hi ha desat? Amb retenció immutable i credencials que no visquin a l'equip protegit, la resposta és no. Sense això, la teva còpia és a un sudo de distància.
• I el punt que tothom es salta: fes la mateixa llista per als altres agents privilegiats d'aquesta màquina. El de monitoratge, el d'inventari, el d'antivirus, el d'accés remot. Tots es van instal·lar com a root i cap no apareix a l'inventari d'aplicacions.

Sobre el primer punt convé insistir-hi: tenir el pedaç instal·lat i tenir la versió corregida no són el mateix. Aquí la pregunta té una resposta numèrica exacta, així que comprova-la a cada servidor en comptes de fiar-te de l'informe mensual d'actualitzacions.

El que aquest cas NO demostra

Acronis no en surt pitjor que ningú: una fallada de permisos per defecte en un component que s'instal·la com a root és dels errors més repetits de l'ofici, i apareix en productes de totes les mides. Dels atacants no sabem per on van entrar a la màquina —l'avís calla, i qui t'expliqui el vector amb detall se l'està inventant—, de manera que el compte d'allotjament com a porta d'entrada és una hipòtesi nostra i va dita com a tal. I un 7,8 local tampoc no és urgent sempre: en un servidor d'aplicació amb dos administradors i cap altre usuari, seguir l'ordre habitual de la cua és perfectament raonable.

El que és útil del cas és més petit: el mateix CVE té urgències diferents en dos servidors diferents, i la diferència la decideix quanta gent té compte en aquesta màquina. Aquesta dada és al cap de qui administra el servidor, i normalment ningú no l'hi pregunta; a l'escàner de vulnerabilitats, segur que no hi és.

I queda l'assumpte de fons, que va més enllà d'aquest avís. Un agent de còpies és el procés amb més privilegi i menys vigilància de qualsevol servidor: s'instal·la un cop, funciona, i es deixa de mirar. Quan algú va a buscar les còpies, poques vegades ataca el repositori: ataca qui hi té permís, una credencial o un agent. Ho vam veure amb el grup que va esborrar les còpies als dos centres de dades alhora, on el que va viatjar entre seus va ser una clau, no cap exploit. La conseqüència pràctica és avorrida i val per avui: les còpies han de sobreviure al fet que el seu propi servidor estigui en mans d'un altre.

I si d'aquesta lectura et queda una sola tasca, que sigui la cinquena: provar una restauració completa amb les credencials de còpia fora del servidor protegit. Nosaltres cronometrem aquest assaig; l'últim de recuperació completa ens va sortir en catorze minuts, i ho diem com a prova que es pot mesurar, no com cap promesa contractual. És la part de recuperació davant desastres que ningú no assaja perquè no falla mai… fins al dia que l'agent deixa de ser teu.

Nota de fonts

Consultat tot el 17 de setembre de 2026. Un: l'avís SEC-10986 de la base de dades d'avisos d'Acronis, llegit al seu registre complet (identificador, CVE-2026-87886, CWE-276, severitat alta amb CVSS 7,8 i vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, productes i compilacions corregides 1.9.3.1021 i 1.8.11.638, publicat 2026-09-15T15:30:00Z); d'allà surt la citació sobre els atacs dirigits i la constatació que els camps de referències i crèdits són buits. Dos: el catàleg de vulnerabilitats explotades conegudes de CISA, versió 2026.09.16, entrada de CVE-2026-87886 —afegida el 16-09-2026, data límit 19-09-2026, marca de triatge forense— i l'alerta del mateix dia, d'on procedeix la frase sobre les agències FCEB; la comparació amb la fallada de Cisco Identity Services Engine (CVE-2026-76460) surt de l'entrada veïna, afegida aquell mateix dia amb la mateixa data límit. Tres: la directiva BOD 26-04, de 10 de juny de 2026, d'on procedeix la definició literal de «& forensic triage» i la taula de terminis per exposició, catàleg, automatització i impacte. Quatre: el manual «Acronis Backup plugin for cPanel & WHM» (revisió de maig de 2026, PDF oficial d'Acronis), d'on surten les instruccions d'instal·lació com a root, el registre del repositori per a actualitzacions via yum o apt, la frase sobre qui pot gestionar les còpies i l'índex d'operacions de descàrrega i recuperació. Cinc: la documentació de cPanel sobre creació de comptes a WHM, per als UID i GID entre 1000 i 60000. Sis: la cobertura de The Hacker News del 16-09-2026, d'on procedeixen la nota de la versió 1.9.3 HF3 i la resposta del portaveu d'Acronis. El que és opinió nostra va dit com a tal: que la prioritat d'un CVE local depèn del nombre d'usuaris de la màquina, que l'agent de còpies és el procés més privilegiat i menys vigilat d'un servidor, i l'ordre de les sis comprovacions. Ningú no ha publicat indicadors de compromís per a aquesta fallada; la llista de triatge és la nostra, no la del fabricant.