Acronis publicó el 15 de septiembre el aviso SEC-10986 por CVE-2026-87886, una escalada de privilegios local por permisos de archivo inseguros. El texto completo de la descripción es una sola oración, y es la que importa: "Exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel & WHM deployments."

CISA lo sumó al catálogo de explotación activa al día siguiente, con plazo al 19 de septiembre.

Lo primero que conviene aclarar, porque el nombre confunde: el producto afectado no es Acronis Cyber Protect. Son dos integraciones con paneles de hosting: el plugin de Acronis Backup para cPanel & WHM y la extensión para Plesk. Si administrás Cyber Protect en los equipos de tu empresa, este aviso no es sobre tu instalación.

DatoCVE-2026-87886
Qué esEscalada de privilegios local por permisos de archivo inseguros
Puntaje7,8, alto, en CVSS 3.0, asignado por Acronis
VectorAV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
TipoCWE-276, permisos por defecto incorrectos
ProductosPlugin para cPanel & WHM y extensión para Plesk, ambos en Linux
Corregido en1.9.3.1021 (cPanel & WHM) y 1.8.11.638 (Plesk)
ExplotaciónConfirmada por el fabricante, en ataques dirigidos y limitados
Registro en NVDNinguno, al 17 de septiembre
En el catálogo de CISASí, desde el 16 de septiembre, con plazo al 19

Un detalle de forma que no es menor: el puntaje está en la escala CVSS 3.0, no 3.1, y lo asignó Acronis. No hay puntaje de NVD porque no hay registro en NVD: al momento de escribir esto, el identificador no devuelve nada en la API. Los dos únicos documentos públicos sobre esta falla son el aviso del fabricante y la ficha del catálogo de CISA.

¿Por qué un 7,8 "local" pesa más en un hosting compartido?

Mirado de lejos, el vector parece tranquilizador. AV:L quiere decir que el ataque es local: hay que estar dentro de la máquina. PR:L quiere decir que hace falta tener ya algún privilegio, aunque sea bajo. Nada de eso suena a emergencia, y por eso el puntaje es 7,8 y no 9,8.

El problema es qué significan esas dos condiciones en un servidor de hosting compartido.

El mismo vector, dos lecturas distintas Servidor dedicado de una empresa "Acceso local con privilegios bajos" es una barrera: primero hay que entrar de otra forma. La escalada es el segundo paso de un ataque, no el primero. Servidor de hosting compartido "Acceso local con privilegios bajos" es la condición normal de cada cliente. La barrera es ser cliente, o comprometer un solo sitio de los que hay en la máquina.

En una máquina compartida hay decenas o cientos de cuentas de cliente, cada una con su acceso por FTP, SSH o panel. Esa es exactamente la posición de partida que la falla requiere. No hay que vulnerar nada para conseguirla: se compra, o se obtiene comprometiendo cualquiera de los sitios alojados —un WordPress con un plugin viejo alcanza—.

No es una interpretación forzada. CISA describió con esas palabras otra falla del mismo ecosistema hace cuatro meses, en el plugin de LiteSpeed para cPanel: "can be abused by any cPanel user account to execute arbitrary scripts with root privileges". Cualquier cuenta de usuario de cPanel.

Qué significa llegar a root en un servidor compartido con cPanel

La escalada termina en root, y root en una máquina multiinquilino no es un privilegio más: es el techo. Desde ahí se leen los archivos y las bases de datos de todas las cuentas del servidor, no solo de la que sirvió para entrar.

De inquilino a dueño del edificio Una cuenta de cliente, igual a cualquier otra Permisos del plugin de backup mal puestos (CWE-276) root en el servidor Todas las cuentas del servidor El vecino de servidor es parte de tu superficie de ataque, y no lo elegís vos

Hay una ironía que conviene nombrar sin dramatizar: el componente que falla es el de las copias de seguridad, que es el que por diseño tiene permiso para leerlo todo. Un plugin de backup en un panel de hosting necesita alcanzar los archivos de cada cuenta; ese alcance es su función. Cuando los permisos de sus propios archivos quedan mal, lo que se hereda no es un acceso parcial.

Los complementos de cPanel y Plesk son una categoría nueva en el catálogo de CISA

Este caso no está solo, y el conjunto dice más que la pieza. Buscando en el catálogo de CISA las entradas del ecosistema de paneles de hosting, aparecen cuatro, y las cuatro son de 2026. Antes de este año no había ninguna.

Paneles de hosting en el catálogo: cuatro entradas, todas de 2026 30 abr cPanel y WHM el panel mismo 26 may LiteSpeed a root desde cPanel 15 jun LiteSpeed enlaces simbólicos 16 sep Acronis Backup a root desde cPanel Tres de las cuatro son complementos de terceros, no el panel

La forma del patrón importa más que el número. Tres de las cuatro no son fallas de cPanel ni de Plesk, sino de lo que se les instala encima: dos del plugin de LiteSpeed y esta, de Acronis. Y tres de las cuatro terminan en lo mismo, escalada a root desde una cuenta de cliente corriente. La cuarta, la del panel en sí en abril, es un bypass de autenticación con uso confirmado por grupos de ransomware según el catálogo.

El panel de hosting es una plataforma con complementos, igual que WordPress, y le está pasando lo mismo que a WordPress: la superficie de ataque real no es el núcleo, es el conjunto de cosas que se le agregan. Con un agravante, y es que acá el que instala los complementos no es el dueño del sitio sino el hosting. El razonamiento sobre qué parte de la seguridad de tu sitio te corresponde y cuál no está en qué cubre el hosting en la seguridad de WordPress.

¿A quién afecta CVE-2026-87886?

A los servidores donde esté instalado el plugin de Acronis Backup para cPanel & WHM en versión anterior a 1.9.3.1021, o la extensión de Acronis Backup para Plesk anterior a 1.8.11.638. Ambos, sobre Linux.

En términos de quién tiene que actuar, eso significa empresas de hosting, revendedores y quien administre su propio VPS con panel. El plugin es un complemento que ofrece backups gestionados a las cuentas del servidor, y es un agregado habitual en planes de hosting compartido y de revendedor.

Si tu empresa tiene un sitio alojado en un plan compartido, vos no podés parchear esto. No tenés acceso al panel de administración del servidor ni a sus complementos. Lo que sí podés es preguntar, y en esta falla puntual la pregunta es corta.

Y de nuevo la aclaración del principio, porque la confusión va a ser común: Acronis Cyber Protect no está en la lista de productos afectados. Es la plataforma de backup y EDR que se instala en los equipos de una empresa, y el aviso no la menciona. Si tenés Cyber Protect, esto no te toca por ese lado.

¿Quién puede ignorar el aviso de Acronis?

Quien no administre un servidor con cPanel o Plesk y no tenga sitios alojados en uno. En la práctica, para casi cualquier PyME con una web, la segunda mitad de esa frase no se cumple.

También queda afuera quien tenga el panel pero sin el complemento de Acronis: el aviso es específico de ese plugin, no de cPanel ni de Plesk. Las fallas del panel en sí son otras, y ya tuvieron su turno en abril.

Por qué Acronis no publicó ningún indicador de compromiso

Acá hay una diferencia con los casos de las últimas semanas que conviene decir con todas las letras, porque cambia lo que se puede hacer.

Cuando PaperCut, MikroTik, Cisco y ConnectWise reconocieron explotación activa, publicaron además indicadores: entradas de registro, nombres de archivo, direcciones, comandos. Con eso un administrador puede ir a buscar si le pasó.

El aviso de Acronis no publica ninguno. Son cuatro frases: el resumen, el puntaje, la lista de productos con su build corregida, y la confirmación de explotación. Los campos de referencias y de créditos están vacíos, y no hay registro en NVD que agregue nada. No hay nada que buscar.

La consecuencia práctica es incómoda pero clara: en este caso no existe la opción de "reviso y después decido". Queda actualizar, y —si el servidor estuvo expuesto— tratar la ausencia de evidencia como lo que es, ausencia de evidencia. Vale notar que CISA marcó esta entrada con el requisito de triaje forense de su directiva BOD 26-04, una casilla que empezó a usar el 1 de julio de este año y que aplicó a 55 de las 1713 entradas del catálogo. Traducido a una decisión concreta: conviene preservar los registros del servidor antes de actualizar, no después.

¿Qué le pregunto a mi hosting sobre el plugin de Acronis?

Tres preguntas, y las tres tienen respuesta corta. Si el proveedor no puede contestarlas hoy, esa también es una respuesta.

  1. ¿El servidor donde está mi sitio usa el plugin de Acronis Backup para cPanel o la extensión para Plesk? Si la respuesta es no, termina ahí.
  2. Si lo usa, ¿en qué build está? Tiene que ser 1.9.3.1021 o posterior en cPanel & WHM, 1.8.11.638 o posterior en Plesk.
  3. ¿Guardaron los registros del servidor antes de actualizar? Es la pregunta que separa a un proveedor que atendió el aviso de uno que apretó "actualizar".

Si administrás vos el servidor, el orden es el mismo pero invertido en urgencia: preservá registros, actualizá a las builds indicadas, y revisá qué cuentas del servidor tuvieron actividad inusual en las últimas semanas, sabiendo que no hay una firma concreta que buscar.

Y una recomendación que excede a esta falla: tu copia de seguridad no puede vivir solamente en el servidor que estás protegiendo. Si el backup de tu sitio lo administra el mismo hosting, en la misma máquina, con el mismo plugin, entonces un compromiso del servidor alcanza al sitio y a su copia a la vez. Tener al menos una copia fuera de ahí es lo que convierte un incidente en una molestia; el criterio está en backup y recuperación y el resto de la categoría, en hostings y cloud.

Es la tercera vez en dos semanas que la falla está en la herramienta de un tercero que administra tus equipos: pasó con N-able N-central y con ScreenConnect. El formato para dejar estas preguntas por escrito, una vez y archivadas, está en cómo responder un cuestionario de seguridad. Los términos, en el glosario, y el orden general de prioridades, en la guía de ciberseguridad para PyMEs de LATAM.


Preguntas frecuentes sobre CVE-2026-87886 y Acronis Backup

Tengo Acronis Cyber Protect en mi empresa. ¿Me afecta?

Por este aviso, no. Los productos que Acronis lista como afectados son dos: el plugin de Acronis Backup para cPanel & WHM y la extensión para Plesk, ambos sobre Linux. Cyber Protect, que es la plataforma de backup y seguridad que se instala en los equipos de una empresa, no aparece en la lista. Son productos distintos que comparten la marca y parte del nombre.

Si es una falla "local", ¿alguien de internet puede aprovecharla?

No directamente, y esa es la parte que baja el puntaje a 7,8. Hace falta tener ya una posición dentro del servidor. Lo que cambia el cálculo es dónde está instalado: en un servidor de hosting compartido esa posición la tiene cada cliente por contrato, y también la consigue cualquiera que comprometa uno solo de los sitios alojados en la máquina. El primer paso no hay que inventarlo: viene de fábrica.

¿Cómo sé si mi sitio fue afectado?

Con honestidad, desde tu lado no podés saberlo, y con este aviso tu proveedor tampoco la tiene fácil: Acronis no publicó indicadores de compromiso, ni referencias, ni hay registro en NVD con más detalle. Lo único verificable es la versión del plugin. Por eso la recomendación práctica es la de siempre para un servidor compartido que pudo estar comprometido: cambiar las contraseñas de tus cuentas —panel, FTP, base de datos— y revisar tu sitio por archivos que no hayas subido vos.

¿Por qué CISA le dio solo tres días de plazo?

Es el escalón más corto del catálogo y acá se apoya en un dato duro: el propio fabricante confirma explotación en ataques reales. El plazo obliga a los organismos federales de Estados Unidos, no a una empresa de la región ni a un hosting local, pero sirve de referencia. CISA además marcó la entrada con el requisito de triaje forense de la directiva BOD 26-04, que en criollo significa preservar evidencia antes de tocar nada.

Mi hosting dice que ya actualizó. ¿Alcanza con eso?

Alcanza para cerrar la falla hacia adelante, no para descartar lo que pueda haber pasado antes. Como no hay indicadores publicados, nadie puede afirmar con certeza que un servidor no fue tocado. Si tu sitio vive en un servidor que tuvo el plugin sin actualizar, lo razonable es rotar tus credenciales y confirmar que tenés una copia de seguridad guardada fuera de ese servidor, que es lo que te deja opciones si más adelante aparece algo.