33 zero-days con exploit obligan a N-able a apagar N-central

«As a precautionary measure, we are temporarily taking our Hosted N-central environment offline» (como medida de precaución, estamos dejando temporalmente fuera de línea nuestro entorno alojado de N-central). Con esa frase, publicada a las 15:15 UTC del 9 de noviembre de 2026 en su página de estado, N-able apagó el servicio alojado de N-central, su plataforma de monitorización y gestión remota (RMM) para proveedores de servicios gestionados, en América, Europa y Asia-Pacífico, y pidió a los clientes con servidor propio que hicieran lo mismo. Once horas antes, un investigador había subido a GitHub 33 vulnerabilidades sin parche con un exploit para cada una. El hotfix llegó el 10 de noviembre con siete CVE, dos de ellos con 9,3 en CVSS 4.0, y para entonces los honeypots de watchTowr y Previdian ya recibían intentos de explotación.

• Sean Bales publicó el 9 de noviembre en GitHub 33 vulnerabilidades de N-central con prueba de concepto y cuatro cadenas de explotación, una de ellas sin credenciales, sin avisar antes a N-able.
• N-able apagó el servicio alojado a las 15:15 UTC de ese día y pidió apagar los servidores on-premises. El 10 de noviembre publicó el Hotfix 2 (2026.4.1.26) con siete CVE, dos de ellos con 9,3 en CVSS 4.0.
• watchTowr y Previdian registraron intentos contra honeypots desde la noche del 9 de noviembre, sin ningún compromiso confirmado de clientes.
• Censys contó 1.728 servidores N-central expuestos el 9 de noviembre y España queda fuera de los diez primeros países.
• Actualiza el servidor, después los agentes y por último los probes, y revisa los logs desde el 8 de noviembre antes de volver a conectarlo.

De un commit a las 04:14 UTC al apagón de N-central alojado en tres regiones

El material apareció en el repositorio CVEs de la cuenta Oracle-Security de GitHub, en un README titulado Able2Shell cuyo primer commit, según el recuento de Tenable, está fechado a las 04:14 UTC del 9 de noviembre. El autor es Sean Bales, consultor de seguridad de aplicaciones según la cobertura de BleepingComputer, y las capturas del propio repositorio llevan su nombre en el prompt de la terminal. El documento describe 33 hallazgos con código Python de prueba de concepto para cada uno, cuatro cadenas de explotación completas y una advertencia sobre el alcance: todo se probó en N-central Appliance 2026.4.0.31, una compilación previa a la publicación, pero «most if not all vulnerabilities should work on previous versions» (la mayoría de las vulnerabilidades, si no todas, deberían funcionar en versiones anteriores).

La captura, tomada por Previdian de la página de estado de N-able, muestra el incidente 202561 tal como quedó publicado a las 15:15 UTC del 9 de noviembre. N-able habla de una divulgación pública y una comunicación no responsable de vulnerabilidades críticas por parte de un investigador independiente, afirma no haber visto explotación activa y pide a los clientes on-premises que apaguen sus servidores hasta nuevo aviso. Los servicios de Ecoverse bajo N-able Login (inventario, parcheo, gestión de vulnerabilidades, scripts y políticas) siguieron disponibles. La compañía se comprometió a actualizar el aviso cada cuatro horas y no dio fecha de restauración.

Bales no avisó al fabricante. A BleepingComputer le confirmó que la búsqueda de los fallos se apoyó en IA y lo resumió así: «I did not disclose any of the 0-days I posted last night» (no comuniqué ninguno de los zero-days que publiqué anoche). El motivo que da es otro producto de N-able: asegura haber enviado hace cinco o seis meses dos ejecuciones remotas de código y una escalada de privilegios que siguen sin parche y sin respuesta a sus correos, y de ahí su conclusión de que «they don't take disclosure seriously» (no se toman en serio la divulgación). Tras la publicación, el consejero delegado y el director de tecnología de N-able se pusieron en contacto con él para pedirle que retirara el repositorio y trabajara con ellos. «They did not threaten me or anything though» (no me amenazaron ni nada parecido), añadió. N-able no ha respondido a las preguntas del medio sobre esos informes anteriores.

La respuesta tardó poco más de un día. El 10 de noviembre N-able publicó N-central 2026.4 Hotfix 2, compilación 2026.4.1.26, que describe como actualización de seguridad crítica, y a lo largo de ese día anunció que todos los servidores alojados de todas las regiones estaban ya actualizados y de vuelta en línea. En ese mismo aviso reconoció «scanning activity associated with the published proof-of-concept code» (actividad de escaneo asociada al código de prueba de concepto publicado), sin evidencia de que ningún entorno de cliente hubiera sido explotado con éxito.

Un XXE sin credenciales en la importación de servicios que acaba ejecutando id como usuario nable

La cadena que el investigador considera más seria no necesita cuenta. Parte de una primitiva de escritura anónima en la interfaz MMS2 del servidor, que procesa entidades externas de XML antes de comprobar la sesión. Ese XXE hace que el appliance descargue un fichero del servidor del atacante y, con lo que devuelve, el exploit reutiliza la confianza de la sesión local NCI para restablecer la contraseña de una cuenta y ejecutar un JSP que ha dejado preparado. El resultado es ejecución de comandos como nable, el usuario de servicio con uid 992, y la misma cadena puede crear una cuenta Default Administrator habilitada con las credenciales que elija el atacante.

La salida de la prueba de concepto que publica el repositorio lo cuenta en nueve líneas: cuenta de administrador creada y aceptada, acción protegida respondida con 200, el comando id devolviendo uid=992(nable), y después la cuenta borrada, la contraseña original restaurada y los registros de preparación neutralizados. Esa limpieza final importa para quien vaya a revisar un servidor: una cuenta de administrador que ya no existe y una contraseña que vuelve a ser la de antes no dejan la huella que uno espera encontrar.

Las otras dos cadenas que llegan a ejecución remota se apoyan en un administrador legítimo. Una contraseña de la interfaz MMS3 que el investigador califica de predecible permite a cualquiera inyectar metadatos en los detalles de un parche, y el script almacenado se ejecuta en el navegador del administrador que abre esa vista. Desde ahí, una variante llama a un sumidero de expresiones OGNL y obtiene comandos como nable, y la otra usa la sesión del administrador para colar una inyección en la gramática de syslog-ng a través de la exportación de auditoría, que corre como root. La cuarta cadena empieza con un path traversal en los ficheros genéricos del SIS, que coloca un JSP ejecutable en el árbol de Jetty, y termina en un instalador de syslog sin contraseña que carga una configuración de un directorio en el que nable puede escribir.

En esta segunda captura del README, el instalador de syslog devuelve uid=0(root) en el contexto syslogd_t de SELinux a partir de una ejecución iniciada como nable. Entre los 33 hallazgos hay varios más que no necesitan encadenarse para hacer daño: la divulgación anónima de las credenciales de la base de datos a través del descubrimiento de activos, un Probe.ListAll que lista los appliances de otros clientes sin autenticar, una sobrescritura global de configuración vía SysConfig.Set, la terminación anónima de sesiones de control remoto, la enumeración de cuentas por el restablecimiento de contraseña y unas credenciales reutilizables del Ecosystem Agent expuestas por MMS3. Un panel que acaba de corregir trece fallos y una cadena a root parece pequeño al lado.

Los registros de CVE que N-able ha publicado como CNA encajan con esa descripción en el punto que más cuenta. El de CVE-2026-125883, las vulnerabilidades XXE múltiples, lleva un vector sin privilegios ni interacción (PR:N y UI:N). El de CVE-2026-125880, el XSS almacenado en los metadatos de parches, exige privilegios altos e interacción activa (PR:H y UI:A), cuando el investigador sostiene que la inyección es anónima y solo la ejecución depende del administrador. Tenable deja constancia de esa diferencia y de que N-able no ha dicho a cuál de los 33 hallazgos corresponde cada CVE.

Siete CVE en el Hotfix 2 y 33 hallazgos que N-able no ha mapeado

Las puntuaciones son las del fabricante. A las 11:00 UTC del 11 de noviembre, NVD tenía los siete registros en estado Received, publicados a las 22:18 UTC del día anterior, sin análisis propio ni vector 3.1, y ninguno figuraba en el catálogo KEV de CISA. Uno de ellos, CVE-2026-91000, había sido reservado el 14 de septiembre, antes de la divulgación de Able2Shell. Otro, CVE-2026-125882, lleva crédito a Nate Fair, de Sprocket Security, y coincide con un path traversal del repositorio de ficheros que también aparece en el README.

Las notas de la versión 2026.4 HF2 añaden lo que el parche cambia más allá de los siete CVE: comprobaciones de autenticación y permisos reforzadas en el servidor, validación nueva en la subida de ficheros y el tratamiento de logs, endurecimiento de la comunicación entre agentes y probes, actualización del sistema operativo y de componentes de terceros, y la retirada de la gestión de dispositivos móviles heredada. El control remoto integrado queda deshabilitado de forma temporal, mientras Take Control sigue funcionando. La ruta de actualización soportada parte de 2025.4, 2026.1, 2026.2, 2026.3, 2026.3.1 (hotfix 1 a 4), 2026.4 (compilación 2026.4.0.27) y 2026.4 Hotfix 1 (2026.4.0.32). N-able anuncia un hotfix posterior con más correcciones de seguridad, lo que sugiere que los siete CVE no agotan la lista.

En Europa, el NCSC neerlandés publicó el 11 de noviembre el aviso NCSC-2026-0478 con probabilidad media y daño alto, y enumera los mismos tipos de fallo: XXE, inyección OGNL, XSS almacenado en contexto de administrador, escalada local por una configuración de syslog-ng mal protegida y por canales IPC inseguros, SSRF en la validación de esquemas al importar servicios y path traversal con ejecución de código en la subida al repositorio de ficheros. INCIBE-CERT no había publicado aviso sobre Able2Shell a esa misma hora, aunque sí tiene ficha desde el 1 de agosto de CVE-2026-18556, el bypass de autenticación de N-central del verano.

Intentos contra honeypots desde dos IP y 1.728 servidores a la vista, ninguno de los diez primeros países es España

El laboratorio watchTowr fue el primero en contar en X, el 10 de noviembre, que había «observed exploitation attempts against N-able N-central honeypots overnight» (observado intentos de explotación contra honeypots de N-able N-central durante la noche), y pedía auditar los servidores en busca de compromiso y restringir el acceso. Previdian, que mantiene un entorno señuelo de N-central, detalla lo que vio: 68 observaciones desde una única dirección IP, 5.231.45[.]175, a partir de las 22:08 UTC del 9 de noviembre. Hubo sondeos exploratorios con parámetros vacíos y XML malformado, peticiones POST a /dms/services/ServerUI con un DOCTYPE que apuntaba a un fichero a.dtd servido desde esa misma IP en el puerto 8097, una importación de servicio remota con svc.xml como ruta e intentos de leer /etc/passwd, /etc/shadow y /proc/self/environ. Previdian subraya que sus señuelos responden 200 a todo y que «An HTTP 200 response from a decoy does not establish those outcomes» (una respuesta HTTP 200 de un señuelo no demuestra esos resultados): ni toma de cuenta, ni ejecución de JSP, ni comando alguno.

Beazley Security Labs añade en su aviso BSL-A1242, actualizado dos veces el 10 de noviembre, un segundo origen, 3.74.48[.]121, peticiones SOAP sin autenticar con un mensaje SessionHello contra /dms2/services2/ServerMMS2 y un user-agent que termina en N-central-sec-audit/1.0, fácil de cambiar y por tanto poco fiable en negativo. Beazley mantiene que un compromiso confirmado de un servidor de cliente «has not been reported» (no se ha notificado), y Huntress decía lo mismo el 10 de noviembre de los entornos de sus partners.

La exposición la midió Censys el 9 de noviembre: 1.728 hosts con N-central accesibles desde internet, con la consulta que su aviso publica y con la salvedad de que se apoya en el título HTML de la consola, lo que puede contar de más o de menos.

host.services.software:(vendor="n-able" and product="n-central") and host.services.endpoints.http.html_title:"N-central"

El mapa de Censys reparte esos hosts por países: Estados Unidos encabeza con 794, seguido de Alemania con 212, Australia con 164, Canadá con 124, Países Bajos con 104, Reino Unido con 89, Sudáfrica con 62, Finlandia con 24, Bélgica con 22 e Irlanda con 18. España no aparece entre los diez primeros, así que su cifra queda por debajo de los 18 de Irlanda, pero no es cero: N-central se vende en España a través de distribuidores de software para MSP y cada uno de esos servidores administra, por diseño, los equipos de decenas de clientes. N-able declara más de 25.000 partners MSP y telemetría de más de 11 millones de endpoints, según recoge CSO Online. Cuando escribimos esta noticia no existe un recuento público de servidores N-central en España ni de cuántos siguen sin el hotfix.

Subir a 2026.4.1.26, agentes antes que probes y leer los logs desde el 8 de noviembre antes de encender

Por orden de urgencia, esto es lo que conviene hacer con un N-central propio.

1. Si el servidor sigue encendido sin el hotfix, apágalo o, si no puedes, quítale la exposición a internet y limita el acceso a las redes de administración de confianza. N-able pide mantenerlo fuera de línea hasta completar la actualización, y eso incluye los servidores de pruebas, preproducción y recuperación ante desastres.
2. Instala N-central 2026.4 Hotfix 2 (compilación 2026.4.1.26) desde la página de descargas de N-able. Si tu versión es anterior a 2025.4, pasa primero por una versión soportada. En el servicio alojado la actualización ya la ha hecho N-able.
3. Actualiza después los agentes y, solo cuando todos estén en 2026.4.1.26, los probes. Un probe actualizado no puede hablar con agentes antiguos, y hasta que agente y PME estén al día la caché de parches sin conexión no funciona. El motor de parcheo se despliega solo.
4. Antes de restaurar el servicio, revisa la actividad de inicio de sesión y autenticación desde el 8 de noviembre: cuentas Default Administrator habilitadas, cuentas con direcciones de correo desconocidas, restablecimientos de contraseña y cambios de privilegios que nadie pidió, scripts o políticas de automatización nuevas, sesiones de control remoto inesperadas contra equipos gestionados y huecos o modificaciones en los registros de auditoría.
5. Busca en los logs web y del proxy que haya delante del servidor las direcciones IP y los endpoints de la tabla anterior, con la cautela que pide el FBI en estos casos: una IP puede cambiar de manos.
6. Si aparece cualquiera de esos indicios, no limpies ni restaures: preserva logs y snapshots, abre un caso de respuesta a incidentes y extiende la revisión a las redes de clientes que cuelgan de ese servidor. Rota después las credenciales que N-central guarda, empezando por las de la base de datos y las de los agentes, porque dos de los hallazgos las exponen sin autenticación.
7. Avisa a INCIBE-CERT si eres empresa o MSP y al CCN-CERT si eres organismo público, e informa a los clientes cuyos equipos administras desde ese servidor.

Estas tres búsquedas, sobre los logs de acceso exportados del servidor o del proxy inverso, cubren los endpoints, el user-agent y las dos direcciones que publican Beazley y Previdian.

grep -E "/dms2/services2/ServerMMS2|/dms/services/ServerUI" access.log | grep -vE "IP_DE_TUS_PROBES"
grep -F "N-central-sec-audit/1.0" access.log
grep -E "3\.74\.48\.121|5\.231\.45\.175" access.log

Cualquier petición a ServerMMS2 o ServerUI desde una dirección que no sea de un probe o de un agente conocidos merece revisarse a mano, y una línea con el user-agent de auditoría es un intento seguro.

Cinco entradas en KEV en quince meses y una divulgación que nadie ha explicado del todo

N-central llega a esta semana con antecedentes. El catálogo KEV de CISA, que el 10 de noviembre sumaba 1.779 entradas, contiene cinco de N-able: CVE-2025-8875 y CVE-2025-8876, añadidas el 13 de agosto de 2025, CVE-2026-18577 y CVE-2026-18556, del 3 y el 4 de agosto de 2026, y CVE-2026-86218, una ejecución remota previa a la autenticación con 10,0 en CVSS 4.0 que entró el 8 de septiembre. Las dos primeras fueron zero-days que Lumen atribuye a Volt Typhoon dentro de la red Silent Train, como contamos al hilo de KeyDrift en Cisco SD-WAN.

De la de agosto, el equipo de investigación de Sophos documentó una intrusión iniciada a las 08:00 UTC del 3 de agosto en la que el atacante usó el servidor N-central para llegar al servidor de copias y a los controladores de dominio, creó una cuenta llamada veeam, restableció contraseñas de administradores de dominio, desplegó seis herramientas de acceso remoto y un túnel de Cloudflare renombrado como MicrosoftEdgeUpdate64.exe, y lanzó la herramienta de evasión de EDR PhantomKiller. Eso es lo que un RMM comprometido permite hacer en una tarde, y la razón por la que un apagón global es una decisión de contención defendible.

Nuestra lectura es que las dos partes tienen algo que explicar. Publicar 33 exploits funcionales sin aviso contra un producto que administra millones de endpoints pone en riesgo a terceros que no tuvieron nada que ver con los correos sin responder del investigador, y la cronología lo confirma: los primeros intentos contra señuelos llegaron unas dieciocho horas después del commit. Pero el relato de Bales, con tres fallos de otro producto de N-able pendientes desde hace medio año, sigue sin respuesta pública del fabricante, y la propia página de estado habla de una comunicación no responsable sin decir qué proceso de divulgación ofrece N-able a quien encuentra algo. Cuando en este blog publicamos un XXE en 2019, el fabricante tardó más de un año en confirmar el parche y aun así esperamos. Ese modelo depende de que al otro lado alguien conteste.

Hay dos lecturas más que conviene apuntar. La primera es el papel de la IA en el descubrimiento, que Bales reconoce y que ya vimos en los fallos de FortiOS hallados con IA: 33 hallazgos en un solo producto, con exploit y capturas para cada uno, es un volumen que hasta hace poco exigía un equipo. La segunda es el perfil de víctima. Un MSP español con N-central on-premises ha pasado dos días sin monitorización, sin parcheo centralizado y sin control remoto, el mismo tipo de dependencia que dejó al descubierto la credencial robada de ConnectWise en octubre y que convierte a estas plataformas en el objetivo que Microsoft describió al atribuir el ataque a ConnectWise a Storm-0940. El hotfix cierra siete CVE. Antes de dar el servidor por limpio, exporta los logs desde el 8 de noviembre y busca la cuenta Default Administrator que el exploit crea y borra en el mismo minuto.