Acronis Backup: «requiere acceso local», y ese acceso se lo vendes tú a tus clientes

Un CVSS de 7,8 con la etiqueta «local» es, en la mayoría de equipos, el CVE que se aparca. No es un diez, no entra por internet, hace falta estar dentro. Ese razonamiento es correcto en un servidor con un solo administrador. En un servidor de hosting, estar dentro es lo que le vendes a tus clientes.

El martes 15 de septiembre a las 15:30 UTC, Acronis publicó el aviso SEC-10986. Al día siguiente, CISA metió el mismo CVE en su catálogo de vulnerabilidades explotadas y le puso fecha límite: 19 de septiembre. Tres días. La versión corta del aviso cabe en un renglón: «Local privilege escalation due to insecure file permissions».

Una frase y dos números de versión

El aviso completo de Acronis es más corto que este párrafo. Dice que afecta al plugin de Acronis Backup para cPanel & WHM en Linux, corregido en la compilación 1.9.3.1021, y a la extensión para Plesk, corregida en la 1.8.11.638. Le asigna CVSS 7,8 —severidad alta— con el vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, lo clasifica como CWE-276 (permisos por defecto incorrectos) y añade una frase: «Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments».

Y ya está. En el registro del aviso, los campos de referencias y de créditos vienen vacíos. No hay ruta de fichero, no hay permiso concreto, no hay indicador de compromiso, no hay una fecha desde la que se sabe que se está explotando. Cuando The Hacker News preguntó, un portavoz de Acronis respondió que no tenía información adicional que compartir. Las notas de la versión sí son claras en el tono: «This update contains fixes for 1 high-severity security vulnerability and should be installed immediately by all users». Un detalle que el aviso sí concreta: la explotación observada es contra despliegues de cPanel & WHM. Para Plesk hay parche, pero ataques reportados no.

El vector, leído despacio

Las dos siglas que deciden la prioridad de este CVE en cualquier hoja de cálculo son AV:L (el atacante tiene que estar en la máquina) y PR:L (le basta con una cuenta sin privilegios). Lo demás del vector es lo malo: sin interacción del usuario, y confidencialidad, integridad y disponibilidad comprometidas por completo. Traducido: impacto total sobre el componente vulnerable. Y como ese componente se instala como root, la traducción práctica es que quien tenga una cuenta cualquiera en ese servidor acaba siendo dueño del servidor.

Ahora recuerda dónde vive este plugin. Vive en paneles de hosting. Y en un servidor con cPanel, cada cuenta que das de alta es un usuario del sistema. La documentación de cPanel no lo dice con esas palabras, pero sí dice lo que importa: al crear la cuenta, «the system creates new account UIDs and GIDs with a number between 1000 and 60000», con un nombre único de dieciséis caracteres o menos. Un UID y un GID propios son, en la práctica, una línea en /etc/passwd con su directorio personal.

Con eso encima de la mesa, «acceso local con privilegios bajos» deja de ser una barrera y pasa a ser un inventario. Lo tiene cada cliente al que le vendes alojamiento. Lo tiene cada desarrollador al que le diste SSH para subir una tienda. Y lo tiene, sin haber pagado nada, cualquiera que consiga ejecutar código PHP en el WordPress desactualizado de cualquiera de esos clientes, porque en la configuración habitual de cPanel —PHP-FPM por usuario o suPHP— ese PHP corre como el usuario de esa cuenta. El escalón que normalmente cuesta semanas de trabajo —pasar de código en una web ajena a la máquina entera— lo regala un permiso de fichero.

Por qué ese proceso y no otro

Hay una razón por la que un fallo de permisos duele más en un agente de copias que en casi cualquier otro software. El procedimiento de instalación del manual del plugin —revisión de mayo de 2026— empieza así: «Log in to the cPanel server as a system administrator or root user». Y para crear manualmente las funciones que deciden qué ve cada cuenta, lo repite: «Log on to the host as a root user». El agente de copias puede leerlo todo por definición; para eso lo pones.

El índice de ese mismo manual sirve de inventario de lo que hay al alcance de ese proceso. Descarga y recuperación de dominios. De ficheros. De volcados de bases de datos. De buzones de correo. De filtros de correo. De reenvíos. Y un capítulo llamado «Exporting the entire account». En una sola máquina de hosting, eso son los datos, el correo y las bases de datos de todos los negocios que alojas.

El propio manual añade la frase que cierra el razonamiento, y conviene leerla entera: «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». Esa frontera —el administrador del servidor a un lado; revendedores y clientes al otro, y solo hasta donde tú les abras— es la que borra un permiso de fichero mal puesto. Seamos precisos con lo que no sabemos: Acronis no dice que en estos ataques se tocaran las copias, y nosotros tampoco lo decimos. Lo que decimos es lo que hay al alcance de quien llega a root en esa máquina, que es una pregunta que cada uno puede responder sin esperar a más detalles del fabricante.

La cola de parches ordena por el número equivocado

Una cola de parcheo se ordena casi siempre por dos columnas: el número del CVSS y si el fallo entra por red. Este CVE pierde en las dos. Y sin embargo CISA lo puso el 16 de septiembre en el catálogo de vulnerabilidades explotadas con fecha límite del 19 —tres días—, la misma ventana que dio ese mismo día a un fallo de Cisco Identity Services Engine que sí es remoto y sin autenticar. El catálogo ordena por una sola cosa, que es si alguien lo está usando.

Esa ventana de tres días sale de la directiva BOD 26-04, del 10 de junio de 2026, que sustituyó el plazo único por una tabla con cuatro variables: exposición del activo, presencia en el catálogo, automatización del exploit e impacto técnico. Y hay una casilla que conviene conocer, porque cambia el trabajo: cuando a un plazo se le añade «& forensic triage», la obligación no es solo parchear, sino «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». La entrada de este CVE en el catálogo lleva esa marca.

La directiva obliga a las agencias federales estadounidenses y a nadie más; la propia CISA lo dice: «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 te obliga, pero te está regalando el criterio de priorización de alguien que ve los datos de explotación de medio mundo. Nosotros lo tratamos como cola de entrada. Ya escribimos sobre esto a propósito de Artifactory, donde el CVE «medio» entró antes que el crítico: la severidad describe el daño posible, no la probabilidad de que te toque a ti esta semana.

Qué haríamos esta misma mañana

Si operas o mantienes servidores con cPanel/WHM o Plesk y tienen el plugin de Acronis, esto es lo que ordenaríamos, en este orden:

• Mira la versión exacta del paquete. La referencia son las compilaciones 1.9.3.1021 (cPanel & WHM) y 1.8.11.638 (Plesk); en las notas de Acronis la corrección figura como 1.9.3 HF3. Un rpm -q o un dpkg -l del paquete del plugin resuelve la pregunta en diez segundos por servidor.
• Comprueba que el repositorio del fabricante sigue configurado. El script de instalación, según el manual, «will register the Stable plugin repository on the system for further plugin updates via yum or apt utilities». Si ese repositorio se quedó fuera al reinstalar el sistema, o si las actualizaciones no desatendidas excluyen los paquetes de terceros, el parche no va a llegar solo por muy urgente que sea.
• Cuenta cuántos usuarios reales tiene esa máquina. No cuentas de panel: líneas en /etc/passwd con UID de 1000 en adelante, tengan shell interactivo o no. En cPanel la mayoría llevan noshell o jailshell, y da lo mismo: para este fallo basta con poder ejecutar código como ese usuario. Ese número es el tamaño de tu superficie «local».
• Haz el triaje aunque no te obligue ninguna directiva. Sin indicadores publicados, lo que queda es lo de siempre y sirve: ficheros nuevos o con propietario cambiado en los directorios del agente, binarios con setuid aparecidos en las últimas semanas, tareas programadas de usuarios de hosting, claves añadidas en authorized_keys de root, y sesiones desde direcciones que no son las tuyas. Si no guardas registros fuera del propio servidor, este es el día en que te enteras.
• Comprueba si las copias siguen siendo copias cuando esa máquina cae. Es la pregunta de fondo: si alguien es root en el servidor protegido, ¿puede borrar o alterar lo ya guardado? Con retención inmutable y credenciales que no vivan en el equipo protegido, la respuesta es no. Sin eso, tu copia está a un sudo de distancia.
• Y el punto que se salta todo el mundo: haz la misma lista para los demás agentes privilegiados de esa máquina. El de monitorización, el de inventario, el de antivirus, el de acceso remoto. Todos se instalaron como root y ninguno aparece en el inventario de aplicaciones.

Sobre el primer punto conviene insistir: tener el parche instalado y tener la versión corregida no son lo mismo. Aquí la pregunta tiene una respuesta numérica exacta, así que compruébala en cada servidor en vez de fiarte del informe mensual de actualizaciones.

Lo que este caso NO demuestra

Acronis no queda aquí peor que nadie: un fallo de permisos por defecto en un componente que se instala como root es de los errores más repetidos del oficio, y aparece en productos de todos los tamaños. Sobre los atacantes no sabemos por dónde entraron en la máquina —el aviso calla, y quien te cuente el vector con detalle se lo está inventando—, así que la cuenta de hosting como puerta de entrada es una hipótesis nuestra y va dicha como tal. Y un 7,8 local tampoco es urgente siempre: en un servidor de aplicación con dos administradores y ningún usuario más, seguir el orden habitual de la cola es perfectamente razonable.

Lo útil del caso es más pequeño: el mismo CVE tiene urgencias distintas en dos servidores distintos, y la diferencia la decide cuánta gente tiene cuenta en esa máquina. Ese dato está en la cabeza del que administra el servidor, y normalmente nadie se lo pregunta; desde luego no está en el escáner de vulnerabilidades.

Y queda el asunto de fondo, que va más allá de este aviso. Un agente de copias es el proceso con más privilegio y menos vigilancia de cualquier servidor: se instala una vez, funciona, y deja de mirarse. Cuando alguien va a por las copias rara vez ataca el repositorio: ataca lo que tiene permiso sobre él, una credencial o un agente. Lo vimos con el grupo que borró las copias en los dos centros de datos a la vez, donde lo que viajó entre sedes fue una clave, no un exploit. La consecuencia práctica es aburrida y vale para hoy: las copias tienen que sobrevivir a que su propio servidor esté en manos de otro.

Y si de esta lectura te queda una sola tarea, que sea la quinta: probar una restauración completa con las credenciales de copia fuera del servidor protegido. Nosotros cronometramos ese ensayo; el último de recuperación completa nos salió en catorce minutos, y lo decimos como prueba de que se puede medir, no como promesa contractual. Es la parte de recuperación ante desastres que nadie ensaya porque no falla nunca… hasta el día que el agente deja de ser tuyo.

Nota de fuentes

Consultado todo el 17 de septiembre de 2026. Uno: el aviso SEC-10986 de la base de datos de avisos de Acronis, leído en su registro completo (identificador, CVE-2026-87886, CWE-276, severidad alta con CVSS 7,8 y vector CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, productos y compilaciones corregidas 1.9.3.1021 y 1.8.11.638, publicado 2026-09-15T15:30:00Z); de ahí sale la cita sobre los ataques dirigidos y la constatación de que los campos de referencias y créditos están vacíos. Dos: el catálogo de vulnerabilidades explotadas conocidas de CISA, versión 2026.09.16, entrada de CVE-2026-87886 —añadida el 16-09-2026, fecha límite 19-09-2026, marca de triaje forense— y la alerta del mismo día, de la que procede la frase sobre las agencias FCEB; la comparación con el fallo de Cisco Identity Services Engine (CVE-2026-76460) sale de la entrada vecina, añadida ese mismo día con la misma fecha límite. Tres: la directiva BOD 26-04, de 10 de junio de 2026, de donde procede la definición literal de «& forensic triage» y la tabla de plazos por exposición, catálogo, automatización e impacto. Cuatro: el manual «Acronis Backup plugin for cPanel & WHM» (revisión de mayo de 2026, PDF oficial de Acronis), de donde salen las instrucciones de instalación como root, el registro del repositorio para actualizaciones vía yum o apt, la frase sobre quién puede gestionar las copias y el índice de operaciones de descarga y recuperación. Cinco: la documentación de cPanel sobre creación de cuentas en WHM, para los UID y GID entre 1000 y 60000. Seis: la cobertura de The Hacker News del 16-09-2026, de donde proceden la nota de la versión 1.9.3 HF3 y la respuesta del portavoz de Acronis. Lo que es opinión nuestra va dicho como tal: que la prioridad de un CVE local depende del número de usuarios de la máquina, que el agente de copias es el proceso más privilegiado y menos vigilado de un servidor, y el orden de las seis comprobaciones. Nadie ha publicado indicadores de compromiso para este fallo; la lista de triaje es la nuestra, no la del fabricante.