N-able retira en línea su nube N-central tras 33 zero-days

Treinta y tres exploits funcionales, publicados un domingo, bastaron para que N-able apagara su propia nube. La empresa retiró esta semana N-central alojado en todo el mundo y pidió también a los clientes on-premises que apagaran sus servidores, después de que un investigador publicara código de prueba de concepto para una colección de zero-days que llama Able2Shell. La factura ya se está contando. Los datos de Censys citados por The Hacker News sitúan 1.728 instancias de N-central directamente en internet, y cada una de ellas es un plano de gestión que puede parchear, ejecutar scripts y controlar de forma remota flotas de endpoints. Un MSP sin su RMM es un MSP que no puede dar servicio a sus clientes. Un MSP con un RMM comprometido está bastante peor.

N-central es un software de monitorización y gestión remota (RMM): la herramienta que los proveedores de servicios gestionados y los equipos de TI empresariales usan para administrar, parchear y dar soporte a sistemas de endpoints a gran escala. Ahí está todo el sentido del producto, y también todo el problema. Un servidor N-central comprometido no expone un segmento de red: expone cada equipo bajo su control, en todos los clientes a los que da servicio el MSP. Cuando el fabricante de esa herramienta te dice que la apagues y esperes, la aritmética operativa del RMM merece una mirada muy seria.

Día 0: un domingo de publicaciones, cuatro cadenas de ataque, sin autenticación requerida

Tarde del domingo 8 de noviembre, el investigador de seguridad ofensiva Sean Bales —que publica con el alias de GitHub Oracle-Security— liberó públicamente los exploits de Able2Shell, según CSO Online. Los probó contra N-central Appliance 2026.4.0.31, una versión previa a la publicación, y señaló en la documentación del repositorio que la mayoría, si no todas, las fallas deberían funcionar también en versiones anteriores, incluida la actual. N-able no ha dicho cuántas de las 33 pudo reproducir.

Los exploits están organizados en cuatro cadenas. Léelas como lo haría un respondedor de incidentes, porque es el orden que seguiría un intruso:

• Cadena uno: acceso inicial sin credenciales. Un fallo XXE en una función de importación de servicios roba una sesión local de confianza, restablece la contraseña de una cuenta y ejecuta comandos como el usuario de servicio nable. La misma cadena puede crear una cuenta Default Administrator con credenciales elegidas por el atacante. Control total del appliance, sin necesidad de iniciar sesión.
• Cadenas dos y tres: persistencia a través del administrador. Una contraseña de appliance predecible permite a un atacante anónimo inyectar metadatos maliciosos de parches. Cuando un administrador abre los detalles del parche, una carga XSS almacenada se ejecuta en su navegador e invoca una interfaz de ejecución de comandos como el usuario nable. La sesión de administrador secuestrada también puede enviar una configuración de exportación de auditoría manipulada que ejecuta comandos como root.
• Cadena cuatro: la escritura directa. Un fallo de salto de directorio (path traversal) en una función de repositorio de software escribe una página web ejecutable en el directorio web del servidor, y después escala a root mediante un instalador sin contraseña que lee la configuración desde un directorio en el que el usuario nable puede escribir.
• Ronda extra. La divulgación también describe un desbordamiento de pila en un componente nativo GenericTCP que logra la ejecución de comandos como root.

Nada de esto es exótico. XXE, XSS almacenado, path traversal, una configuración de syslog-ng escribible, un desbordamiento de pila clásico: son clases de error tan antiguas que ya podrían votar. He trabajado en intrusiones que se apoyaron exactamente en estas primitivas, y la palabra que usaría no es una en la que confíe en el marketing de los fabricantes. Lo aburrido funciona. Lo aburrido consiguió root aquí, de cuatro maneras distintas.

Durante la noche: los honeypots respondieron la pregunta que todos se hacen

La brecha entre la divulgación y la explotación se midió en horas, no en días. WatchTowr afirmó haber observado intentos de explotación contra sus honeypots de N-central durante la noche posterior a la publicación. Defused Cyber informó de sondeos activos sobre la superficie de ataque exacta que describen las PoC:

«Hemos visto la apertura de sesiones de agente anónimas, la descarga de la configuración del appliance y el acceso al endpoint de control remoto sin autenticación», declaró Defused Cyber. «Estas rutas forman parte de la superficie de explotación de los 0-day».

Previdian, una firma de inteligencia de amenazas, registró 68 intentos de explotación contra uno de sus honeypots desde una única dirección IP en unas 18 horas desde la publicación. N-able confirmó que detecta actividad de escaneo vinculada al código PoC publicado, pero afirma que no hay evidencia de explotación exitosa en ningún entorno de clientes. Mantén separados estos dos hechos. El escaneo está confirmado. El compromiso, no. La distancia entre ambos es la ventana de parcheo, y esta se abrió un domingo con código de explotación funcional ya público.

Dos días después, el martes, N-able publicó N-central 2026.4 HF2 y confirmó que todos los servidores N-central alojados, en todas las regiones, habían sido actualizados. El entorno clásico alojado permaneció fuera de servicio durante la remediación; los servicios Ecoverse bajo N-able Login —Asset View, Patching, Vulnerability Management, scripting, políticas y etiquetado— siguieron disponibles. Se pidió a los clientes on-premises que mantuvieran sus servidores apagados hasta que las actualizaciones se aplicaran correctamente.

Siete CVE frente a treinta y tres fallos

El hotfix corrige siete CVE. La divulgación contenía treinta y tres. Esa aritmética importa, y N-able ha dicho que llegará un hotfix de seguimiento con más actualizaciones de seguridad. Entre el conjunto corregido:

• CVE-2026-125883 — múltiples vulnerabilidades XXE
• CVE-2026-125881 — SSRF mediante schema-hint en la validación de esquemas de importación de servicios
• CVE-2026-91000 — canales IPC inseguros que llevan a una escalada local de privilegios
• Las demás correcciones del conjunto cubren fallos de inyección, cross-site scripting, path traversal y escalada de privilegios descritos en la divulgación, aunque N-able aún no ha asociado cada uno de los 33 problemas reportados con un identificador público.

Si contrastas las notas de parche con las cuatro cadenas, la cobertura es tranquilizadora pero incompleta a primera vista: las clases de error principales detrás del robo de sesión, la ejecución de scripts en contexto de administrador, la escritura de archivos y la escalada a root aparecen todas en el conjunto corregido. Lo que sigue sin parchear hasta que llegue el seguimiento no está completamente enumerado públicamente, lo que significa que los defensores deberían tratar HF2 como el inicio de la respuesta, no como su final. Huntress aconseja a los clientes revisar la actividad de inicio de sesión y autenticación desde el 8 de noviembre en adelante para detectar accesos inesperados o no autorizados, examinar los registros de auditoría en busca de indicadores secundarios y restablecer el servicio solo cuando N-able diga que es seguro. Esa fecha del 8 de noviembre es el punto de referencia correcto. Es el Día 0, y cualquier cosa extraña en tus registros a partir de ahí merece una segunda mirada.

Las cuentas del RMM dejan de cuadrar

Aquí está la pregunta más difícil que obliga a plantear este incidente. El RMM existe porque centralizar la gestión es eficiente: una consola, miles de endpoints, un puñado de técnicos. El margen de cada MSP vive en esa proporción. Pero la misma arquitectura que hace rentable al RMM lo convierte en un objetivo concentrado, y esa concentración no es teórica. CSO Online señala que es la cuarta vez en 15 meses que N-able se ve obligada a una respuesta de emergencia, incluidas dos fallas parchadas en agosto de 2025. Hemos visto el mismo patrón en sus competidores: ConnectWise suspendió su servicio de copias de seguridad en la nube tras una brecha de credenciales que expuso el mismo cuello de botella de los MSP desde otro ángulo.

El lado de los costes del balance suele ser invisible hasta una semana como esta. Los clientes alojados perdieron por completo su plano de gestión durante un tiempo. Los clientes on-premises recibieron la orden de apagar y esperar. Y 1.728 instancias estaban en internet público cuando llegó el código de explotación funcional: cada una de ellas, una llave maestra preposicionada para toda la base de clientes de alguien. Cuando valores el RMM, valora también el radio de impacto.

¿Cuándo podría haberse detectado?

Es la pregunta que hago al final de cada cronología, y esta cronología tiene respuestas. Las sesiones de agente anónimas que se abren sin autenticación no deberían mezclarse con el ruido de referencia: es una fuente de registros con una firma. La descarga de la configuración del appliance por sesiones sin credenciales es detectable. Una cuenta Default Administrator recién creada en un servidor de gestión es lo más ruidoso que puede ser la persistencia. Y una sesión de administrador que envía una configuración de exportación de auditoría manipulada tras ver los metadatos de un parche es una secuencia que tus registros de auditoría capturan o no capturan. Si tu N-central está expuesto a internet con el registro por defecto y sin alertas sobre la creación de cuentas, la respuesta honesta es que no lo habrías detectado. Corrígelo mientras los servidores están apagados de todos modos.

El hotfix de seguimiento sigue pendiente, la lista completa de 33 fallos aún no está asociada a CVE, y el escaneo no se ha detenido. Aprende la lección en orden: instala HF2 antes de restaurar nada, audita hasta el 8 de noviembre y luego decide —de forma deliberada y por escrito— cuánta de tu base de clientes quieres que dependa de un solo appliance. La gestión centralizada es una apuesta. Esta semana mostró las probabilidades.