Por Mid 
N-able N-central arrastra desde el 2 de agosto de 2026 una vulnerabilidad crítica de omisión de autenticación, catalogada como CVE-2026-18577 y explotada de forma activa. Un atacante remoto y sin credenciales podía hacerse con el control administrativo de la consola y, desde ahí, alcanzar todos los equipos gestionados.
El fabricante publicó ese mismo día la versión 2026.3.1.7, que corrige el fallo. Si administras una consola de N-able N-central, actualizar no es tarea para el próximo mantenimiento programado: es para hoy.
Llegó como parche de urgencia y por una razón poco tranquilizadora: corrige una vía de explotación que un arreglo anterior había dejado abierta.
Resumen del incidente
- CVE: CVE-2026-18577 (previamente CVE-2026-18556), 8.2 en CVSS 4.0.
- Afecta a: versiones anteriores a 2026.3.1.7, en nube y en instalaciones propias.
- Corregido en: 2026.3.1.7, publicada el 2 de agosto de 2026.
- Estado: explotación activa confirmada por el fabricante y por Huntress.
Qué ha ocurrido con N-able N-central
N-able N-central es una plataforma de monitorización y gestión remota (RMM) que utilizan sobre todo proveedores de servicios gestionados. Su función es precisamente la que la convierte en un objetivo tan valioso: desde una única consola se administran, se parchean y se controlan miles de equipos repartidos entre decenas de organizaciones cliente.
El 1 y 2 de agosto de 2026 el fabricante comunicó que un atacante había identificado una vulnerabilidad y la había explotado con éxito para obtener acceso administrativo remoto. La empresa afirma haber identificado un número limitado de clientes afectados y haber contactado directamente con ellos. Huntress, por su parte, confirmó haber observado la explotación en al menos una organización de su red de clientes y socios.
Lo relevante aquí no es solo el fallo, sino su alcance: comprometer una consola de N-able N-central no equivale a comprometer un servidor, equivale a comprometer todo lo que ese servidor administra.
Un parche incompleto: la parte incómoda del caso
La cronología del fallo en N-able N-central es la lección más valiosa de este incidente. Existía una vulnerabilidad previa, CVE-2026-18556, que afectaba a las versiones hasta la 2026.1 y que el fabricante dio por corregida en la 2026.2. Semanas después se descubrió que había una vía alternativa para explotar exactamente el mismo problema, que el arreglo anterior no bloqueaba.
Esa vía alternativa es CVE-2026-18577, y amplió el rango afectado a todas las compilaciones anteriores a 2026.3.1.7. Ambas comparten puntuación, 8.2 en CVSS 4.0, y naturaleza: omisión de autenticación mediante una ruta o canal alternativo.
Conclusión operativa
Haber aplicado el parche de junio no te protege. Si tu instalación de N-able N-central está en cualquier versión por debajo de 2026.3.1.7, sigue siendo vulnerable aunque creyeras el asunto cerrado.
No es un patrón nuevo. Ya lo vimos en el caso de PAN-OS con CVE-2024-3400, donde la corrección inicial tuvo que revisarse. La enseñanza es siempre la misma: un CVE marcado como resuelto merece seguimiento, no archivo.
Qué hicieron los atacantes tras entrar en N-able N-central
Según el análisis de Huntress, la actividad posterior al acceso a N-able N-central siguió un guion muy reconocible y aprovechó las funciones legítimas de la propia plataforma, que es lo que hace este caso especialmente difícil de detectar.
- Ejecución de scripts en los equipos gestionados, usando el mecanismo de despliegue habitual del producto.
- Abuso de la función Take Control para abrir sesiones remotas hacia sistemas críticos, incluidos controladores de dominio y servidores de ficheros.
- Túneles de Cloudflare desplegados como mecanismo de persistencia, difíciles de distinguir del tráfico saliente legítimo.
- Modificación de políticas y roles de usuario para conservar el acceso.
Nada de esto requiere malware propiamente dicho. Es la herramienta de administración haciendo aquello para lo que fue diseñada, solo que con el atacante al volante. Por eso las defensas basadas únicamente en firmas de fichero aportan tan poco frente a un compromiso de N-able N-central.
Cómo comprobar si tu N-able N-central está comprometido
Actualizar N-able N-central cierra la puerta, pero no responde a la pregunta importante: ¿entró alguien antes? Estos son los registros que conviene revisar, según la guía de detección publicada por los investigadores.
| Dónde mirar | Qué buscar |
|---|---|
ui_access_control.log en la consola | Inicios de sesión desde direcciones o países inusuales |
C:\ProgramData\GetSupportService_N-Central\Logs\ | Sesiones de control remoto no justificadas |
| Cuentas de soporte del fabricante | Actividad bajo esas identidades sin ticket asociado |
| Registro de sesiones remotas | Accesos a controladores de dominio o servidores de ficheros |
| Tráfico saliente | Conexiones persistentes a servicios de túnel |
Huntress señaló además un detalle que complica la detección: varias de las direcciones implicadas correspondían a nodos de salida de servicios VPN comerciales. Eso significa que filtrar por geolocalización o por reputación de IP no es suficiente, y que el foco debe ponerse en el comportamiento —qué se hizo desde esa sesión— más que en el origen.
Presta especial atención al criterio horario: una sesión de control remoto un domingo por la madrugada, sin incidencia abierta que la respalde, es una señal de alarma por sí sola. Y revisa altas de usuarios o cambios de rol en las semanas previas, porque son el rastro más habitual de un intento de persistencia.
Medidas urgentes para proteger N-able N-central
El orden importa. Estas acciones sobre tu instalación de N-able N-central están priorizadas por impacto real sobre el riesgo.
- Actualiza a 2026.3.1.7 de inmediato. Es la única corrección efectiva del fallo.
- Exige doble factor en todas las cuentas, sin excepciones para las administrativas.
- Saca la consola de Internet. Restringe el acceso por VPN o por listas de origen permitidas.
- Audita usuarios y permisos, y revoca cualquier cuenta o token que no reconozcas.
- Revisa los registros del apartado anterior buscando actividad previa a la actualización.
- Valora apagar el servicio si está expuesto y no puedes parchear en horas. Es una decisión dura, pero proporcionada al riesgo.
Si detectas indicios de compromiso, no te limites a la consola: asume que todo equipo gestionado desde ella pudo verse afectado y trata el incidente con ese alcance desde el principio.
Qué hacer si gestionas N-able N-central para terceros
Si eres proveedor de servicios gestionados, el incidente tiene una capa añadida que conviene no aparcar: la comunicación. Tus clientes no administran N-able N-central, pero sus equipos están al otro extremo de esa consola, y cualquier acceso indebido les afecta directamente.
- Documenta la ventana de exposición: desde qué versión venías y en qué momento exacto aplicaste la 2026.3.1.7.
- Conserva los registros antes de que roten. Son la única prueba de lo que ocurrió, y en un incidente serio los necesitarás íntegros.
- Avisa aunque no haya indicios. Un cliente prefiere saber que revisaste y no encontraste nada, a enterarse tres meses después por otra vía.
- Revisa las credenciales almacenadas en la plataforma y rota las que dieran acceso privilegiado a entornos de cliente.
Ese último punto se pasa por alto con frecuencia. Una consola de N-able N-central suele custodiar credenciales de administración de muchos entornos distintos; si hubo compromiso, deben considerarse expuestas todas ellas, no solo las de la propia plataforma.
Por qué el RMM es un objetivo tan rentable
Este incidente encaja en una tendencia bien establecida: atacar el punto que concentra el acceso en lugar de cada objetivo por separado. Un proveedor gestionado con doscientos clientes ofrece, desde una sola consola, doscientas redes. La relación entre esfuerzo y beneficio es difícil de igualar.
Es el mismo razonamiento que hemos visto en los ataques a la cadena de suministro como el caso XZ o en el fallo crítico de Splunk Enterprise: comprometer la herramienta de confianza sale mucho más a cuenta que comprometer a sus usuarios uno a uno. Los 86.644 firewalls Fortinet comprometidos en FortiBleed contaban una historia parecida.
La conclusión práctica para cualquier equipo: las herramientas de administración remota merecen el mismo trato que un controlador de dominio. Nunca expuestas directamente, siempre con doble factor, con registro centralizado y con un plan de parcheo de horas, no de semanas.
Conclusión sobre el caso N-able N-central
Hay dos lecturas. La inmediata es operativa y no admite matices: actualiza a 2026.3.1.7, cierra la exposición y revisa los registros buscando actividad anterior. La segunda es estructural: cuando una consola concentra el control de miles de equipos, su seguridad deja de ser un asunto interno y pasa a ser un riesgo compartido con todos los clientes que dependen de ella.
El detalle del parche incompleto merece quedarse grabado. Marcar un CVE como resuelto y no volver a mirarlo es exactamente lo que permitió que esta segunda vía siguiera abierta durante semanas. Puedes seguir el resto de avisos en nuestra sección de vulnerabilidades.
Preguntas frecuentes sobre N-able N-central
¿Estoy afectado si uso la versión en nube?
La vulnerabilidad afecta tanto a instalaciones propias como a despliegues en nube. Si tu instancia la gestiona el fabricante, confirma con soporte que ya está en 2026.3.1.7; si la gestionas tú, la actualización es responsabilidad tuya.
Apliqué el parche anterior, ¿me vale?
No. La corrección de CVE-2026-18556 en la versión 2026.2 no bloquea la vía alternativa de CVE-2026-18577. Solo la 2026.3.1.7 o posterior resuelve el problema.
¿Cómo sé si me han comprometido?
Revisa ui_access_control.log en busca de accesos anómalos, los registros de control remoto en los endpoints y cualquier actividad bajo cuentas de soporte sin ticket. Ante la duda, trata el caso como incidente y amplía el alcance a los equipos gestionados.
¿Basta con activar el doble factor?
No como medida única. Se trata de una omisión de autenticación, así que el atacante puede evitar el flujo de inicio de sesión. El doble factor es una capa necesaria, pero no sustituye a la actualización.
Fuentes
- N-able — N-central Security Update, 2 de agosto de 2026
- Huntress — Critical N-able N-central Vulnerability and Active Exploitation
- NVD — CVE-2026-18577
- The Hacker News — N-able Says Attackers Take Over N-central Servers
Información contrastada el 3 de agosto de 2026. Este artículo tiene finalidad informativa y defensiva; no incluye detalles de explotación.