Apaga la consola que gestiona todos tus equipos, hasta nuevo aviso

El lunes 9 de noviembre, un fabricante de software de gestión remota publicó en su panel de estado una recomendación que casi nunca se lee. No pedía aplicar un parche: pedía a los clientes con servidor propio «retirar temporalmente de servicio sus servidores N-central y mantenerlos apagados hasta que N-able confirme que pueden volver a encenderse con seguridad». Apagar la consola desde la que se administran todas las máquinas, y dejarla apagada.

Da igual si usas ese producto. La pregunta que deja encima de la mesa no es de producto: ¿cuántas horas aguanta tu empresa sin el sistema que parchea, inventaría, monitoriza y entra en todas tus máquinas? ¿Y quién, de tu plantilla, se entera un domingo por la noche de que hay que apagarlo? Nosotros somos proveedor de servicios gestionados, así que esta historia nos incluye: va de la pieza que tenemos todos y que nadie incluye en el plan de contingencia porque es, precisamente, la que se usa para ejecutar el plan de contingencia.

Lo que dice el aviso, con la hora puesta

El aviso lo publica N-able, fabricante de N-central, una plataforma de monitorización y gestión remota que usan proveedores de IT y departamentos internos para administrar parques de equipos enteros. Lo leímos directamente de su panel público, no de la prensa, y conviene contar cómo, porque esa parte acabó siendo noticia por sí sola. A las 12:34 UTC de hoy el incidente figuraba abierto el 9 de noviembre a las 15:15 UTC, con tres actualizaciones, y hablaba de una «divulgación pública y comunicación no responsable de vulnerabilidades críticas». A las 13:10 UTC volvimos a mirar y el registro era otro: otro identificador interno, hora de apertura las 14:00 UTC, una sola actualización, el adjetivo «no responsable» retirado y un párrafo nuevo. El panel no guarda historial —el módulo que lo guardaría está desactivado—, así que de la versión de la mañana solo queda lo que uno se haya descargado.

Lo que no ha cambiado entre las dos versiones es lo importante: severidad «Major Outage» y seis servicios afectados a la vez —N-central alojado en América, Asia-Pacífico y Europa, y N-central en servidor propio en las mismas tres regiones—, el apagado preventivo de la nube del propio fabricante («como medida de precaución, hemos retirado temporalmente de servicio nuestros entornos alojados de N-central») y la recomendación a los de servidor propio, que el texto marca como «recomendamos encarecidamente». Ahí está la parte que separa dos contratos que mucha gente firma pensando que son el mismo: a los clientes del servicio alojado se lo apagaron ellos; a los de servidor propio les recomendaron apagarlo. A media tarde de un lunes, unos se enteraron y ya estaba hecho; los otros tuvieron que enterarse, decidirlo y ejecutarlo.

Lo que sí ha cambiado es la frase que más importa operativamente. Por la mañana decía: «En este momento no hemos visto explotación activa de estas vulnerabilidades». El texto de la tarde dice: «Como era de esperar, estamos observando actividad de escaneo asociada al código de prueba de concepto publicado. En este momento, sin embargo, no tenemos evidencia de que el entorno de ningún cliente haya sido explotado con éxito». Sigue sin haber brecha confirmada, y ese matiz importa cuando el titular que te llega por Slack dice otra cosa; pero ya hay alguien probando llaves en la puerta, y eso cambia el cálculo de cuánto puedes esperar.

Hay que decir lo que han hecho bien, que es poco frecuente. Reconocen el daño sin maquillarlo: «Somos conscientes del impacto operativo significativo que estas acciones pueden tener. No damos este paso a la ligera». Y en la actualización de las 09:46 UTC —la última que vimos antes de la reescritura— decían algo que un departamento de marketing habría recortado: que la hora estimada del arreglo «es provisional y puede moverse», porque quieren que la compilación «pase nuestros estándares de calidad habituales incluso en estas circunstancias difíciles». Y hay que decir también la otra mitad: la promesa de actualizar «cada cuatro horas» aparece dentro de la actualización de las 05:00 UTC, trece horas y tres cuartos después de abrir el incidente, y la siguiente llegó cuarenta y seis minutos más tarde de lo prometido. Trece horas de silencio son muchas noches de guardia.

Seis días entre «actualiza» y «apágalo»

En el mismo panel sigue abierto un aviso anterior, del 3 de noviembre a las 15:00 UTC. Dice: «Los clientes con instalación propia deberían actualizar a N-central 2026.4 HF1 cuanto antes». El parche salió el 2 de noviembre a las 18:30 GMT, compilación 2026.4.0.32, y lo que arregla es el sistema operativo de debajo: N-central corre sobre AlmaLinux 9 y el hotfix trae las actualizaciones de seguridad de la distribución, entre ellas CVE-2026-98432 —un uso después de liberar en la pila IPv4 del kernel de Linux, 9,8 según el expediente del NVD y según las propias notas del fabricante— y CVE-2026-114406, que retira la confianza a unos certificados raíz. Del tercero, CVE-2026-111497, escriben una frase que casi ningún fabricante escribe: que N-central no usa el decodificador Brotli afectado y por tanto no es vulnerable, pero que actualizan igual por higiene.

Entre ese «actualiza cuanto antes» del día 3 y el «mantenlo apagado» del día 9 hay seis días. Las dos instrucciones son correctas, no se contradicen y las dos exigen exactamente lo mismo de tu lado: que alguien esté leyendo. La diferencia está en otro sitio. Lo que arregló el hotfix tenía número: tres CVE, su puntuación, su entrada en el NVD, su línea en el informe del escáner. Lo que obligó a apagar la plataforma seis días después está en la aplicación de encima y, a la hora en que escribimos esto, no tiene ninguno: consultando el NVD por «N-central» salen 28 expedientes y el más reciente se publicó el 6 de septiembre. Tu escáner de vulnerabilidades solo puede enseñarte la capa que ya tiene número, y la que te tumba un lunes suele ir por delante del catálogo.

El material se publicó el domingo 8 bajo el nombre Able2Shell, y la cifra que circula por la prensa es de 33 fallos de día cero con pruebas de concepto. Esa cifra no la podemos verificar nosotros: el fabricante no ha dado ningún número en ninguna de sus comunicaciones, y la búsqueda pública de repositorios de GitHub no devuelve hoy ningún resultado para «Able2Shell». De la autoría, lo que hay es desigual: BleepingComputer identifica al investigador como Sean Bales y dice haber hablado con él; otros medios no nombran a nadie y citan solo la cuenta de GitHub desde la que se publicó. Así que dejamos la cifra donde está, como lo que es, y nos quedamos con lo que sí firma el fabricante: fueron suficientes para apagar tres regiones. Si quieres el procedimiento para cuando el parche todavía no existe, lo escribimos entero en tu política de parcheo no contempla que no haya parche.

El bucle: lo que parchea es lo que hay que apagar

Cuando apagas un servidor de ficheros, pierdes ficheros. Cuando apagas el plano de gestión, pierdes la capacidad de arreglar todo lo demás: es la única pieza del parque cuyo apagado te deja sin la herramienta con la que ibas a responder al apagado. Y lo que cae con ella no es una función, son seis:

En este caso concreto había bote salvavidas: el fabricante mantuvo en pie su plano nuevo, el de la nube, y publicó qué seguía disponible desde allí —vista de activos, parcheo, gestión de vulnerabilidades, scripts, políticas y etiquetado—, además de abrir ese mismo día un motor de parcheo de Windows en preview y solo bajo demanda y el control remoto desde la vista de activos. Y aquí es donde se saca la lección equivocada. Ese bote existía porque el fabricante tenía dos planos; la mayoría de instalaciones que vemos tienen uno. Una sola consola que concentra acceso, inventario, parcheo y automatización sale barata de operar y es cómoda hasta que deja de serlo: el día malo es un interruptor único. Sobre quién tiene de verdad autoridad para accionar un interruptor así ya escribimos a cuenta de otro apagón: tus servidores los puede apagar alguien con quien no has firmado nada.

Esto no empezó el domingo

El catálogo de vulnerabilidades explotadas de CISA —la lista de fallos de los que hay constancia de uso real, no de los que podrían usarse— llevaba ya cinco entradas de este mismo producto antes del domingo. Las sacamos hoy del fichero oficial, versión 2026.11.09 publicada ayer a las 19:54 UTC, con 1.773 expedientes en total:

De esa tabla nos quedamos con dos cosas. Una, el orden: CVE-2026-18577 entró en el catálogo un día antes que CVE-2026-18556, y el 18577 es, según su propio expediente, «el resultado de un parche incompleto de CVE-2026-18556». El parche del salto de autenticación llegó al catálogo de explotados antes que el fallo que venía a tapar. Dos, el plazo: las tres entradas de 2026 traen tres días para las agencias federales estadounidenses. No es un plazo excepcional reservado a lo grave —desde que CISA cambió de directiva, tres días es la banda más corta de las que usa y la que más reparte: 155 de los 289 expedientes dados de alta en 2026—, así que el termómetro no es el plazo. El termómetro es que este producto haya entrado cinco veces. De lo que significa confiar en un agente que corre con permisos totales en cada máquina hablamos en el agente de tu proveedor de IT es superficie de ataque. Lo de ahora es el capítulo siguiente: el servidor que manda sobre todos esos agentes.

¿Por qué canal te llega la mala noticia?

Esta parte la medimos nosotros hoy y es reproducible en dos minutos. El fabricante tiene dos sitios públicos. Uno es el blog de notas de versión, que es un WordPress y por tanto tiene RSS: el canal al que se suscribe la gente. El otro es el panel de estado, una aplicación web cuyos datos solo salen si consultas su API, que no publica RSS y que, como vimos arriba, no conserva lo que borra. Preguntamos al primero por entradas de noviembre sobre el incidente del día 9: cero. Hay dos entradas de noviembre que tocan seguridad —el aviso de Risk Intelligence del día 6 y las propias notas del hotfix del día 2, que citamos más arriba—, pero ninguna menciona el apagado. Lo último publicado allí el día 9 son dos entradas de producto, a las 14:18 y a las 21:39 UTC. La recomendación de apagar los servidores vive, íntegra, en el otro sitio.

Seamos justos con ellos: la entrada de las 21:39 es el motor de parcheo en preview, y el propio aviso del incidente la enlaza como alternativa para quien se ha quedado sin consola, o sea que forma parte de la respuesta. El panel de estado, además, permite suscribirse. Pero la consecuencia práctica no cambia y es incómoda: si tu vigilancia de proveedores consiste en un lector de RSS, el 9 de noviembre habrías visto una novedad de producto y no la recomendación de apagar. Esto no va de comunicación corporativa. Va de una columna que debería existir en tu inventario de proveedores, al lado del nombre: dónde publica cada uno las malas noticias, quién de los tuyos está suscrito, y qué pasa cuando eso cae en domingo.

Runbook: 48 horas sin plano de gestión

Esto es lo que nosotros ejecutaríamos, en este orden, el día que a cualquiera de nuestras herramientas de gestión le toque la china. Está escrito para que lo copies y lo adaptes, no para que lo admires.

Primera hora. Confirmar la recomendación en el canal del fabricante, no en el titular: hora exacta, versiones afectadas, qué dice de explotación activa. Y guardar una copia de lo que dice hoy, porque esa página puede cambiar debajo de ti. Antes de apagar, llevarse los registros a otro sitio: si el aparato se apaga y luego hay que mirar hacia atrás, lo volátil ya no está. Si apagarlo de golpe no es viable, el paso intermedio es sacarlo de internet y dejarlo accesible solo desde la red de gestión, que es donde debería haber estado siempre.

Primeras cuatro horas. Comprobar —ejecutando, no recordando— que entras a las máquinas sin esa herramienta: una cuenta local o de dominio que funcione, la tarjeta de gestión del servidor, la VPN con su segundo factor. Si el único camino de vuelta pasaba por el agente que acabas de apagar, ese es tu hallazgo del día. Sacar el inventario de donde no dependa de la herramienta y avisar a quien le vaya a doler: usuarios que no tendrán soporte remoto hoy, y dirección, que prefiere enterarse por ti.

Las 48 horas. Parchear a mano por prioridad —lo que esté en el catálogo de explotados y lo que dé a internet, en ese orden— y anotar en una lista lo que se hace a pelo, porque cuando la consola vuelva habrá que reconciliar. Mantener una monitorización que no dependa del plano caído, aunque sea mínima. Y poner una fecha de revisión: si a las 48 horas sigues sin consola, ya no es un incidente del proveedor, es tu plan de continuidad.

El reencendido. No se vuelve en bloque. Primero un servidor, validado contra lo que diga el fabricante que arregla la versión nueva; después el resto. Y el último paso del runbook es el que casi nadie hace: escribir qué faltó. Este apagón no te lo cobra nadie como simulacro, pero lo es, y es el único que vas a tener este trimestre.

Si al leer esto has pensado que tú no tienes «nada de eso», búscalo mejor. Se llama Intune, o el servidor de copias, o la consola del EDR, o Ansible, o el hipervisor, o ese script de despliegue que corre como administrador de dominio desde hace seis años. Cualquier pieza capaz de ejecutar lo que le mandes en todas las máquinas a la vez es un plano de gestión, aunque en la factura ponga otra cosa. Y tiene las mismas tres preguntas: quién la actualiza, quién se entera cuando su fabricante publica algo feo, y cómo trabajas el día que haya que apagarla.

Lo que hacemos nosotros, y lo que no vamos a prometerte

Sería fácil cerrar esto con un «por eso, confía en nosotros». No va de eso. Nosotros también tenemos herramientas con alcance sobre parques enteros, y la única diferencia honesta que podemos reclamar es cómo las tratamos: el inventario y la documentación de red viven en NetBox, que es fuente de verdad y no un anexo del RMM; la monitorización es nuestra, con Zabbix y SmokePing, y por tanto no se cae con la consola de nadie; y las automatizaciones internas —n8n autoalojado, por ejemplo— están inventariadas como servicio de producción, con dueño y ventana de actualización, no como «un cacharro que montó alguien».

Lo que no te vamos a prometer es que a nosotros no nos pase. El fabricante del lunes es una empresa seria con página de incidentes, actualizaciones cada cuatro horas y la decencia de apagar su propia nube antes de que se lo pidieran. Si alguien te jura que su plano de gestión es inmune, te está vendiendo algo. El fallo es inevitable; lo que se decide en la mesa de diseño es si ese fallo se convierte en avería. La diferencia entre las dos cosas, el día del apagón, es un documento de dos páginas escrito antes y probado al menos una vez.

Fuentes (el 10-11-2026, con dos capturas del mismo sitio: 12:34 UTC y 13:10 UTC): todo el incidente sale del panel de estado público de N-able, cuyos datos se sirven desde su propia API y cuyo módulo de histórico está desactivado. De la captura de las 12:34, que conservamos: apertura el 09-11-2026 a las 15:15 UTC, tres actualizaciones, la expresión «divulgación pública y comunicación no responsable», la frase «En este momento no hemos visto explotación activa de estas vulnerabilidades» y las actualizaciones de las 05:00 UTC (que es donde aparece la promesa de actualizar cada cuatro horas) y de las 09:46 UTC (de donde salen «es provisional y puede moverse» y «pase nuestros estándares de calidad habituales incluso en estas circunstancias difíciles»). De la captura de las 13:10, que es la que verá quien pinche el enlace: otro identificador de incidente, apertura a las 14:00 UTC, una sola actualización, sin el adjetivo «no responsable», y el párrafo nuevo sobre la actividad de escaneo. Severidad «Major Outage», los seis servicios y «recomendamos encarecidamente» están en las dos. El aviso anterior del 03-11-2026 a las 15:00 UTC sigue abierto en el mismo panel. El hotfix (compilación 2026.4.0.32, AlmaLinux 9, los tres CVE y la nota de que el decodificador Brotli no se usa) está en las notas de versión del 02-11-2026, 18:30 GMT. El 9,8 de CVE-2026-98432 y su naturaleza (uso después de liberar en la pila IPv4 del kernel) son del NVD y coinciden con lo que publica el fabricante. Para CVE-2026-86218 damos las dos puntuaciones porque no son la misma cosa: 9,8 es la métrica CVSS 3.1 primaria del NVD y 10,0 es la CVSS 4.0 secundaria aportada por el fabricante. El recuento de 28 expedientes para «N-central» y la fecha del más reciente (06-09-2026) salen de la API del NVD hoy. La tabla de cinco entradas, sus fechas de alta y sus plazos son del catálogo de vulnerabilidades explotadas de CISA, fichero JSON versión 2026.11.09 publicado el 09-11-2026 a las 19:54 UTC con 1.773 expedientes; el reparto de plazos de 2026 (155 de 289 altas con tres días) lo contamos nosotros sobre ese mismo fichero. El recuento del blog de notas de versión es medición nuestra contra su API pública y es reproducible. La cifra de 33 fallos, el nombre Able2Shell, la fecha del domingo 08-11 y la identificación del investigador por parte de BleepingComputer proceden de la prensa, no del fabricante, y van marcadas como tales. Fotografía: «Power Lockout», de darkday (Brisbane, Australia), CC BY 2.0 vía Wikimedia Commons, original de 6.016 × 4.000, recortada por nosotros; la descripción del autor señala que los candados tienen la llave puesta, detalle que no hemos retocado.