N-able corrige una RCE crítica sin autenticación previa en N-central mientras se contradicen los informes de explotación

N-able ha publicado una actualización de emergencia para N-central, su plataforma local de monitorización y gestión remota, con la que corrige una vulnerabilidad crítica que permite ejecutar código de forma remota sin autenticación.

Identificada como CVE-2026-86218, la vulnerabilidad afecta a todas las compilaciones de N-central anteriores a 2026.3.1.14. Esto incluye 2026.3.1.13, distribuida como Hotfix 3 poco antes de que se divulgara la nueva vulnerabilidad.

La compilación corregida, N-central 2026.3.1.14, está disponible como 2026.3 Hotfix 4. N-able publicó y actualizó el registro CVE el 6 de septiembre de 2026 y recomienda a todos los clientes con instalaciones locales que actualicen de inmediato.

No está claro si los atacantes ya están explotando la vulnerabilidad. N-able ha emitido declaraciones contradictorias: algunos avisos de la empresa indican que no hay una explotación confirmada en entornos de producción, mientras que un aviso de incidente independiente afirma que se ha observado explotación en la naturaleza.

Una vulnerabilidad de máxima gravedad que no requiere credenciales

CVE-2026-86218 tiene la puntuación máxima de 10,0 en CVSS 4.0, con el siguiente vector:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

La evaluación describe una vulnerabilidad accesible a través de la red y explotable con una complejidad de ataque baja. El atacante no necesita una cuenta, privilegios ni la interacción de un usuario legítimo.

Una explotación satisfactoria puede provocar impactos graves en la confidencialidad, la integridad y la disponibilidad, tanto en el servidor de N-central como en los sistemas posteriores. Esto resulta especialmente relevante en un producto RMM, ya que los servidores de N-central administran flotas de endpoints de clientes y ofrecen funciones de control remoto.

La debilidad subyacente está clasificada como CWE-96, es decir, neutralización incorrecta de directivas en código guardado estáticamente. Esta categoría suele describirse como inyección de código estático: se incorporan directivas controladas por el atacante a código u otro recurso ejecutable que se almacena y procesa posteriormente.

N-able no ha publicado cuál es el componente vulnerable, el formato requerido de las solicitudes, el procedimiento de explotación ni otros detalles técnicos suficientes para reproducir el problema. Tampoco se han proporcionado indicadores de compromiso públicos.

Según el registro CVE, el rango afectado comienza en la versión 0 e incluye todas las versiones anteriores a 2026.3.1.14. El producto vulnerable es el servidor de N-central, no los agentes administrados.

Los sistemas con Hotfix 3 siguen expuestos

Hotfix 4 es necesario incluso en los servidores que ya han recibido Hotfix 3, compilación 2026.3.1.13. La versión anterior corregía dos vulnerabilidades independientes:

• CVE-2026-86206 permitía acceder sin autorización a API internas a través del filtro de control de acceso a las API internas de N-central. N-able le asignó una puntuación CVSS de 6,9, gravedad media, mientras que la NVD la clasifica como CWE-791. Está corregida en N-central 2026.3 HF3 y 2026.4.
• CVE-2026-86207 era una omisión de autenticación que afectaba a API de uso exclusivamente interno. N-able le asignó una puntuación CVSS de 7,7, gravedad alta, y está clasificada como CWE-305. Las versiones anteriores a 2026.3 HF3 están afectadas.

N-able afirma que esas dos vulnerabilidades no guardan relación con CVE-2026-86218. Por tanto, instalar Hotfix 3 no mitiga la nueva vía de ejecución de código sin autenticación previa.

Hotfix 4 es la cuarta actualización de la rama N-central 2026.3 en cinco semanas. Hotfix 1, compilación 2026.3.1.7, llegó el 2 de agosto para corregir CVE-2026-18577, una corrección incompleta de una omisión de autenticación anterior. Hotfix 2, compilación 2026.3.1.10, le siguió el 6 de agosto con medidas adicionales de refuerzo.

Hotfix 3, compilación 2026.3.1.13, se publicó el 5 de septiembre. Hotfix 4 llegó el 6 de septiembre.

Esta rápida sucesión implica que los administradores no pueden considerar que la presencia de un hotfix reciente de 2026.3 demuestre que un servidor está protegido. Es necesario comprobar directamente el número de compilación.

N-able ofrece versiones contradictorias sobre la explotación activa

La situación de la explotación sigue sin resolverse.

El material de lanzamiento de Hotfix 4 y la actualización de estado de N-able indican que una parte externa notificó responsablemente la vulnerabilidad a través del programa de divulgación de la empresa. Esas comunicaciones afirman que N-able no dispone de pruebas confirmadas de explotación en entornos de producción.

Un aviso de incidente independiente de N-able ofrece una versión diferente. Afirma que un tercer investigador de seguridad independiente notificó una vulnerabilidad nueva y no relacionada que se había observado mientras era explotada en la naturaleza.

El aviso no identifica quién observó los ataques, qué entornos se vieron afectados, cuándo tuvo lugar la actividad ni cómo se verificó la explotación. La documentación de N-able también denomina a CVE-2026-86218 «día cero crítico», pero la empresa no ha definido cómo utiliza ese término.

El incidente seguía abierto en la página de estado de N-able el 7 de septiembre de 2026. No se ha atribuido la actividad a ningún actor de amenazas.

Huntress comenzó a analizar un compromiso el 4 de septiembre, después de que se vulnerara el entorno de producción de N-central de un cliente que estaba completamente actualizado. Sus investigadores reprodujeron una cadena de explotación contra la compilación 2026.3.1.10, en la que podrían haber intervenido una o ambas vulnerabilidades corregidas posteriormente por Hotfix 3.

Sin embargo, los registros relevantes del dispositivo ya se habían rotado. Huntress no pudo determinar si CVE-2026-86218 formaba parte de esa intrusión.

Por tanto, existe un motivo creíble para considerar la vulnerabilidad una amenaza inmediata, pero todavía no hay pruebas documentadas públicamente que establezcan un ataque concreto mediante este CVE.

Las vulnerabilidades anteriores de N-central se incorporaron al catálogo KEV de CISA

No se ha informado de que CVE-2026-86218 se haya incorporado al catálogo de vulnerabilidades explotadas conocidas de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos. No se conoce ningún plazo de corrección de KEV para esta vulnerabilidad.

Sin embargo, varias vulnerabilidades recientes de N-central sí han entrado en el catálogo.

CVE-2026-18577, una corrección incompleta que permitía omitir la autenticación y tomar el control de cuentas, se incorporó a KEV el 3 de agosto de 2026. Las agencias federales recibieron como fecha límite de corrección el 6 de agosto de 2026. La vulnerabilidad afecta a las versiones de N-central anteriores a 2026.3 y tiene una puntuación CVSS 3.1 de 8,1.

CVE-2026-18556 se incorporó el 4 de agosto de 2026, con una fecha límite de corrección del 7 de agosto de 2026. Esta omisión de autenticación por una vía alternativa afecta a N-central <= 2026.1 y tiene una puntuación CVSS de 7,4.

Para ambas vulnerabilidades, CISA exige aplicar medidas de mitigación alineadas con las instrucciones del proveedor, las directrices de aplicación de parches basada en riesgos BOD 26-04 y sus requisitos de triaje forense.

Otros dos problemas anteriores de N-central, CVE-2025-8875 y CVE-2025-8876, entraron en KEV el 13 de agosto de 2025, con una fecha límite federal del 20 de agosto de 2025. Recibieron puntuaciones CVSS de 7,8 y 8,8, respectivamente. CISA instó a las organizaciones a aplicar las medidas de mitigación del proveedor, seguir las directrices aplicables para servicios en la nube de BOD 22-01 o dejar de utilizar el producto si no había medidas de mitigación disponibles.

La historia reciente es operativamente relevante: N-central ha sido atacado en repetidas ocasiones mediante vulnerabilidades que proporcionan acceso privilegiado o ejecución de código.

Aplicar primero el parche y después investigar posibles accesos persistentes

Todas las organizaciones que ejecuten N-central en instalaciones locales deberían instalar 2026.3 Hotfix 4, lo que actualizará el servidor a la compilación 2026.3.1.14. N-able ofrece rutas de actualización directa desde:

• 2025.4
• 2026.1
• 2026.2
• 2026.3
• Compilaciones de hotfix existentes de 2026.3.1

Los agentes administrados no necesitan una actualización para CVE-2026-86218. Según se ha informado, N-central Online, también conocido como NCOD, ya ha sido parcheado.

Si no es posible instalar la actualización de inmediato, los administradores deberían restringir el acceso entrante a la consola mediante una lista de direcciones IP permitidas o una VPN. Un servidor de N-central accesible desde Internet que no pueda actualizarse con rapidez debería retirarse temporalmente de la red.

Aplicar el parche no demuestra que un sistema ya expuesto esté limpio. Los administradores deberían auditar N-central para detectar usuarios no autorizados, creación inesperada de cuentas y cambios de privilegios sin explicación.

En ataques anteriores detectados tras una intrusión el 31 de julio, los atacantes utilizaron acceso administrativo para abusar de la función Take Control de N-central. Después registraron servicios de túnel de Cloudflare en endpoints administrados, lo que les permitió conservar el acceso una vez eliminada su vía de entrada a través de N-central.

Por tanto, los defensores deberían revisar:

• Modificaciones de cuentas administrativas y de usuario;
• Actividad de Take Control en los endpoints administrados;
• Acceso a las API internas de N-central;
• Túneles de Cloudflare nuevos o no autorizados;
• Sesiones de gestión remota inesperadas;
• Registros disponibles del servidor y del dispositivo antes de que se roten.

N-able no ha publicado indicadores específicos de CVE, una solución alternativa ni reglas de detección detalladas. Hasta que se aclare la discrepancia sobre la explotación, las organizaciones deberían tratar la compilación 2026.3.1.14 como la versión mínima segura y conservar las pruebas antes de que la retención normal de registros las elimine.