N-able ha desconectado su plataforma de gestión remota N-central en las Américas, Europa y Asia-Pacífico después de que un investigador publicara más de 30 vulnerabilidades zero-day con exploits funcionales. Para los MSP que dependen de ella, es como si les hubieran apagado el centro de operaciones: sin consola no hay parcheo, ni monitorización, ni acceso remoto a los clientes.
Qué ha pasado
La noche del domingo 8 de noviembre de 2026, el investigador de seguridad Sean Bales publicó en GitHub un repositorio llamado Able2Shell con los detalles y el código de explotación (proof-of-concept) de 33 presuntas vulnerabilidades zero-day en N-able N-central, la plataforma de monitorización y gestión remota (RMM) que usan los proveedores de servicios gestionados (MSP) y los equipos de TI para administrar los dispositivos de sus clientes. Bales las probó contra N-central Appliance 2026.4.0.31, una versión aún no publicada, y cree que la mayoría afectan también a versiones anteriores. Confirmó además a BleepingComputer que el descubrimiento fue asistido por inteligencia artificial.
La respuesta de N-able fue drástica: el lunes 9 de noviembre declaró un incidente crítico de seguridad, apagó su nube de N-central en todo el mundo y pidió a los clientes con N-central en local que apagaran sus servidores hasta nuevo aviso. Está validando un hotfix, sin fecha estimada de vuelta al servicio, y prometió actualizaciones cada cuatro horas.
La cadena más grave no necesita ni usuario ni contraseña
Los fallos cubren casi todo el catálogo web: bypass de autenticación, exposición de credenciales, escritura arbitraria de archivos, directory traversal, XSS, inyección XXE y ejecución remota de código (RCE). Huntress resume el conjunto en cuatro cadenas: tres terminan en RCE y una en escalada a root. La más crítica, según Bales:
- XXE sin autenticación en la función de importación de servicios de N-central.
- El atacante roba una sesión local de confianza y restablece la contraseña de una cuenta.
- Ejecuta comandos en el servidor como el usuario de servicio
nable. - La misma cadena permite crear una cuenta de administrador habilitada («Default Administrator») con credenciales controladas por el atacante: acceso administrativo permanente a la consola.
El lote incluye además un XSS almacenado que ejecuta comandos como root cuando un administrador consulta metadatos de parche maliciosos y una escalada de nable a root. No hay CVEs asignados y ni BleepingComputer ni Huntress han verificado las 33 vulnerabilidades de forma independiente, pero que N-able haya apagado su propia nube y esté construyendo un hotfix da credibilidad a las reclamaciones.
El contexto: un año negro y una divulgación sin aviso
Bales no avisó a N-able antes de publicar: según BleepingComputer, la compañía supuestamente ignoró reportes que le hizo hace cinco o seis meses en otro producto —dos RCE y una escalada de privilegios que, según él, siguen sin parchear—, no respondió a sus correos y no le pagó por bug bounty. Tras la publicación, el CEO y el CTO le pidieron que retirara el repositorio y colaborara; según Bales, sin amenazas. Esos fallos no están en Able2Shell.
Es además el tercer golpe grave contra N-central en cuatro meses. En agosto de 2026, N-able parcheó CVE-2026-18556, que daba acceso no autenticado a la consola RMM; poco después se reveló CVE-2026-18577: el parche era incompleto. En septiembre, llegó CVE-2026-86218, un RCE pre-autenticación con CVSS 10.0 explotado en activo, que CISA añadió a su catálogo KEV. En total, CISA lista ya cinco fallos de N-central como explotados. Quien controla la consola de un MSP controla, en la práctica, todos sus clientes: en agosto y septiembre los atacantes usaron la función «Take Control» para pivotar a los endpoints de los clientes.
Qué hacer ahora
N-able afirma que, a las 15:15 UTC del 9 de noviembre, no había observado explotación activa ni accesos no autorizados. Con los exploits ya públicos, esa ventana puede cerrarse en horas.
Si usas N-central en local: apaga el servidor ahora y mantenlo apagado hasta que N-able confirme que es seguro restaurarlo; los parches de agosto y septiembre no cubren estos fallos. Revisa los registros de autenticación desde el 8 de noviembre y examina los logs de auditoría: cuentas de administrador nuevas —en especial una «Default Administrator» habilitada—, sesiones remotas anómalas y scripts desplegados que nadie reconoce. Si encuentras algo sospechoso, activa tu equipo de respuesta a incidentes y valora si los clientes gestionados también están afectados. Aplica el hotfix solo cuando N-able lo publique.
Si usas el servicio alojado: espera la interrupción y sigue la página de estado, y prepara el plan de contingencia: sin N-central no hay parcheo centralizado, ni despliegue de scripts, ni acceso remoto a los clientes.
Ángulo Blue Team: qué vigilaría un SOC
- El RMM es infraestructura crítica, no una herramienta más. Un RMM expuesto a internet con un fallo pre-autenticación es dejar la llave maestra de todos tus clientes colgada en la puerta. Si dependes de un MSP, pregunta qué RMM usa y cómo lo segmenta.
- Busca persistencia, no solo el exploit. Las cadenas crean cuentas de administrador y ejecutan comandos como
nabley como root. En los logs: cuentas nuevas o reactivadas, cambios de contraseña fuera de horario, sesiones desde IPs inusuales y procesos hijos del servicio de N-central que no deberían existir. Revisa también si los logs de auditoría han sido manipulados. - El precedente del «spraying» aguas abajo. En la explotación de CVE-2026-86218, los atacantes rociaron los entornos de los clientes con scripts no autorizados. La caza debe extenderse a los clientes finales: scripts sin ticket, tareas programadas nuevas y herramientas de acceso remoto fuera de catálogo.
La lección incómoda: cuando un investigador siente que el canal responsable no funciona, la divulgación pública con PoC se convierte en su única palanca, y empieza una carrera entre defensores y atacantes por el mismo código. N-able eligió apagarlo todo antes de que esa carrera empezara. Para los MSP afectados, es un apagón doloroso, pero probablemente la decisión correcta.
Fuentes
- BleepingComputer — «N-able takes cloud platform offline after 30+ ‘zero-days’ published» (9 de noviembre de 2026): https://www.bleepingcomputer.com/news/security/n-able-takes-cloud-platform-offline-after-30-plus-zero-days-published/
- Huntress — «N-able Disables Cloud Services Following Disclosure of ‘Able2Shell’ Exploit Chains» (9 de noviembre de 2026): https://www.huntress.com/blog/n-able-disables-cloud-services-following-disclosure-of-able2shell-exploit-chains
- N-able — Página de estado del incidente: https://uptime.n-able.com/event/202561/
- SecurityOnline.info — «33 N-central Vulnerabilities: Proof-of-Concept Exploit Out»: https://securityonline.info/n-central-vulnerabilities-poc-exploit/
- TechProlonged — «N-able pulls N-central offline after 33 alleged zero-days leak»: https://techprolonged.com/2026/11/n-able-pulls-n-central-offline-after-33-alleged-zero-days-leak/