En agosto de 2026, muchos proveedores de servicios gestionados (MSP) descubrieron que la consola con la que administran los servidores de sus clientes se había convertido en la puerta de entrada del atacante. La falla —CVE-2026-18577— no era del todo nueva: era el mismo agujero que N-able creía haber tapado semanas antes. Este es el caso de un parche incompleto que, en cuestión de días, terminó en el catálogo KEV de CISA y con MSPs comprometidos de punta a punta.
CVE-2026-18577 es una vulnerabilidad de bypass de autenticación (CVSS 8.2) en N-able N-central, la plataforma RMM que los MSP usan para administrar de forma centralizada los servidores y endpoints de sus clientes. Permite a un atacante remoto obtener acceso administrativo a la consola sin credenciales válidas. Es el parche incompleto de CVE-2026-18556: N-able la creyó cerrada en la versión 2026.2, pero quedó una segunda ruta explotable. CISA la sumó a su catálogo KEV el 3 de agosto de 2026.
¿Qué significa que CVE-2026-18577 sea un "parche incompleto"?
Un parche incompleto es una corrección que cierra una forma de explotar una falla pero deja abierta otra ruta hacia la misma debilidad de fondo. Eso es exactamente lo que pasó: N-able corrigió CVE-2026-18556 en la versión 2026.2, pero a comienzos de agosto los atacantes demostraron que existía un segundo camino —un "alternate path or channel"— que el fix original no cubría.
Ese camino recibió su propio identificador, CVE-2026-18577, con el mismo puntaje que su predecesora (CVSS 8.2). Según el análisis de Rapid7, la vulnerabilidad afecta tanto a las instalaciones on-premise como a las hospedadas en cloud, y permite a un atacante remoto obtener control administrativo de la consola. El detalle importante para cualquiera que administre software: aplicar una actualización con el número de CVE en el changelog no garantiza que la clase de bug esté erradicada.
¿Por qué comprometer una consola N-central escala tan rápido?
Porque N-able N-central no administra un servidor: administra todos los servidores y equipos que un MSP le conectó. Es una plataforma de administración remota y monitoreo (RMM) que los proveedores instalan —on-premise o en cloud— para gestionar de forma centralizada la flota de decenas o cientos de clientes desde una sola interfaz.
Ese diseño es su valor y su riesgo. Tomar una consola N-central le da al atacante un efecto multiplicador: desde ahí puede alcanzar cada endpoint que la consola controla. N-central incluye Take Control, una función legítima de acceso remoto pensada para que el soporte del MSP entre a los equipos de sus clientes. Convertida en herramienta ofensiva, esa misma función es un canal de acceso remoto ya instalado, confiable y silencioso.
¿Cómo usaron los atacantes el acceso?
Una vez dentro de la consola con permisos de administrador, los atacantes abusaron de Take Control para saltar a los endpoints administrados y desplegar persistencia. De acuerdo con la investigación de Huntress (firmada por Ben Bernstein y John Hammond), el patrón observado fue:
- Reconocimiento dirigido a servidores clave. Los atacantes buscaron y priorizaron activos críticos, típicamente Domain Controllers, y se movieron rápido entre múltiples hosts tras el acceso inicial.
- Sesiones bajo el usuario "MSP Support". Los Windows Event Logs mostraron inicios de sesión con el nombre de usuario por defecto "MSP Support" desde una IP maliciosa, sin tickets ni órdenes de trabajo que los justificaran.
- Persistencia con cloudflared. Sobre los equipos comprometidos se registró un servicio llamado
Cloudflared—la utilidad legítima de Cloudflare Tunnel, abusada acá para abrir un canal de acceso remoto encubierto que sobrevive a reinicios. - Binario disfrazado. Aparecía un archivo
svchost.execolocado en la carpeta Documents del usuario, imitando el nombre de un proceso legítimo de Windows para pasar desapercibido. - Enumeración antes de desconectar. En varios casos el atacante pidió el listado de procesos del sistema comprometido y se desconectó, en una fase de reconocimiento previa a una explotación más profunda.
¿Cuáles son los indicadores de compromiso (IOCs)?
Si administrás N-central, revisá tu entorno buscando estas señales concretas antes de darlo por sano:
- Un
svchost.exedentro de la carpeta Documents de cualquier usuario (el binario legítimo vive enC:\Windows\System32, nunca en Documents). - Un servicio registrado llamado
Cloudflareden máquinas donde nadie configuró Cloudflare Tunnel. - Conexiones salientes a IPs de nodos de salida VPN. Los reportes señalaron las direcciones
173.249.252.200,87.249.138.34,37.19.210.32y68.235.46.214, trazadas a nodos de salida de Mullvad y NordVPN. - Logins de "MSP Support" sin ticket asociado, sobre todo si apuntan a Domain Controllers.
¿Cuál fue la línea de tiempo del incidente?
El caso comprimió en poco más de una semana el ciclo completo de explotación, parche fallido y re-parche. Así se desarrolló:
| Fecha (2026) | Qué pasó |
|---|---|
| 1 de agosto | Se observa explotación activa de CVE-2026-18577 en la naturaleza. |
| 2 de agosto | N-able publica el aviso de seguridad y libera el primer hotfix (2026.3.1.7 / 2026.3 HF1). |
| 3 de agosto | CISA agrega CVE-2026-18577 a su catálogo KEV. |
| 5 de agosto | La falla original, CVE-2026-18556, también entra al catálogo KEV. |
| 6 de agosto | Vence el plazo de CISA para agencias federales (FCEB) y N-able libera un segundo hotfix (2026.3.1.10 / 2026.3 HF2). |
¿Por qué hizo falta un segundo hotfix?
Porque el primer parche tampoco alcanzó. El hotfix 2026.3.1.7 bloqueó la variante conocida, pero los atacantes encontraron otra variación que evadía sus chequeos y siguieron entrando. N-able liberó entonces el hotfix 2 (2026.3.1.10) con endurecimiento adicional, según reportó Help Net Security.
La advertencia más importante de N-able es que parchear no equivale a limpiar. En su comunicado, la empresa fue explícita: "Aplicar el Hotfix 2 cierra la vulnerabilidad que permitió el ingreso de los atacantes, pero no elimina a un actor de amenaza que ya pueda estar presente en tu entorno". Por eso recomendaron tratar como potencialmente comprometidos los entornos que se parchearon varios días después del lanzamiento, sobre todo porque se observó a los atacantes creando cuentas nuevas y reseteando otras para mantener acceso. Analistas de Microsoft atribuyeron la actividad a Storm-1175, un grupo con motivación financiera conocido por explotar vulnerabilidades recién parcheadas en campañas de ransomware.
N-able reconoció que "un número limitado de clientes" resultó comprometido, sin dar cifras exactas. Huntress, por su parte, indicó que hacia el 3 de agosto veía impacto en una sola organización de su base, sin señales de que se tratara de una campaña amplia e indiscriminada —al menos hasta esa etapa.
¿Qué lecciones deja para quien administra un servidor cloud?
La enseñanza central es que un identificador de CVE en un changelog no es una garantía de erradicación. Estas son las conclusiones accionables del caso:
- Parchear no es sinónimo de estar limpio. Si una falla estuvo explotada antes de que aplicaras el fix, asumí compromiso: revisá cuentas, sesiones remotas y persistencia (assume-breach), no solo el número de versión.
- El catálogo KEV de CISA es tu lista de prioridades. Que un CVE entre al KEV significa "explotado en la naturaleza, ahora": esos parches van primero, por encima de puntajes CVSS aislados.
- Las herramientas de administración remota necesitan defensa en profundidad. Una consola RMM, un panel o cualquier plano de control multi-cliente concentra riesgo. Restringí su exposición a internet, exigí MFA y auditá los accesos con Take Control-like functionality contra tickets reales.
- Monitoreá el tráfico saliente. El abuso de
cloudflaredes un patrón repetido: un túnel legítimo usado para exfiltración y C2. Alertá sobre servicios de túnel que nadie aprovisionó y sobre binarios con nombres de sistema en rutas inusuales. - Un parche incompleto es un patrón, no una anomalía. Ya cubrimos casos similares en este blog —fixes que dejaban un segundo path abierto en Ingress y NGINX. Cuando una corrección ataca el síntoma y no la clase de bug, esperá una segunda ronda.
Preguntas frecuentes
¿Qué versión de N-central corrige CVE-2026-18577?
La corrección llegó en N-central 2026.3.1 Hotfix 1 (2026.3.1.7) y se reforzó en el Hotfix 2 (2026.3.1.10). Todas las versiones anteriores a 2026.3 HF1 están afectadas. Aplicá el hotfix más reciente disponible.
¿Alcanza con aplicar el hotfix?
No necesariamente. Según N-able, el hotfix cierra la vía de ingreso pero no expulsa a un atacante que ya haya entrado. Si tu consola estuvo expuesta durante la ventana de explotación (desde el 1 de agosto de 2026), hacé además hunting de IOCs y revisión de cuentas.
¿A quién afecta: instalaciones on-premise o en cloud?
A ambas. La vulnerabilidad afecta tanto los despliegues on-premise como los hospedados en cloud de N-central en versiones previas al parche, según el análisis de Rapid7.
¿Cómo sé si mi consola N-central fue comprometida?
Buscá los IOCs conocidos: un svchost.exe en carpetas Documents, un servicio Cloudflared no aprovisionado, conexiones a las IPs reportadas y logins de "MSP Support" sin ticket que los respalde, especialmente hacia Domain Controllers.
¿Por qué CISA le puso plazo a este CVE?
Porque entró al catálogo de Vulnerabilidades Explotadas Conocidas (KEV) el 3 de agosto de 2026, lo que obligó a las agencias federales de EE. UU. a remediar antes del 6 de agosto. La inclusión en el KEV es la señal de que una falla ya se está usando en ataques reales.