El agente que instalamos en tus equipos también es una puerta

El 3 de agosto, CISA metió CVE-2026-18577 en su catálogo de vulnerabilidades explotadas con fecha límite el día 6. Es un fallo en N-central, la consola desde la que muchos proveedores de IT gestionan los equipos de sus clientes. Si no usas ese producto, la tentación es pasar de largo. No lo hagas: si tienes un proveedor de IT, tienes un agente suyo corriendo con privilegios en cada uno de tus equipos. Nosotros ponemos uno. Este post va de eso, y no es cómodo de escribir.

Cuatro días, en orden

Cuatro días de cronología explican el resto. El 31 de julio, N-able detecta «un aumento de incidencias de licenciamiento» entre sus clientes con N-central instalado en casa, y pone a trabajar a los equipos de ingeniería y seguridad. El 1 de agosto se publica CVE-2026-18556: un salto de autenticación por una vía alternativa (CWE-288) que afecta a N-central hasta la versión 2026.1 y que ya se había corregido en la 2026.2. El 2 de agosto se publica CVE-2026-18577, y la descripción del NIST cabe en una línea: «un parche incompleto para CVE-2026-18556 permite el salto de autenticación y la toma de control de cuentas en N-central hasta la versión 2026.3.1». Misma puntuación, 8,2 en CVSS 4.0. El 3 de agosto, CISA lo mete en el KEV con plazo para el 6 de agosto. El arreglo es el hotfix 2026.3.1.7.

El punto de partida es lo más honesto de toda esta historia: lo primero que se vio no fue una alerta de seguridad. Fueron errores de licencia. Todo apunta a que alguien estaba dentro de suficientes consolas como para que el contador de licencias empezara a dar números raros —el fabricante no ha explicado la relación exacta—, y esa fue la señal. No un EDR, no un SIEM, no un aviso de nadie: la contabilidad.

Y conviene poner la escala sobre la mesa antes de seguir, porque es lo que hace que este caso no sea el de un fabricante con mala suerte. Una consola de gestión de parques no administra una empresa: administra las de todos los clientes de un proveedor a la vez. Quien entra ahí no ha entrado en una red; ha entrado en todas las que ese proveedor lleva. Esa concentración es exactamente lo que hace viable el modelo —es la razón por la que sale a cuenta que alguien externo mantenga tus equipos— y también la razón por la que vale tanto atacarlo. Nosotros vivimos de esa concentración, así que lo que viene no lo escribimos desde la grada.

No hizo falta malware. Usaron el producto

Según el relato del propio fabricante, tras el salto de autenticación el atacante usó la función Take Control —el control remoto que trae el producto— para conectarse a máquinas dentro del entorno gestionado. Huntress, que estaba viendo el incidente desde dentro de sus clientes, añade el detalle: las sesiones salían de la cuenta por defecto «MSP Support» y dejaban rastro en los eventos de Windows 4102, 8192 y 8193. Desde ahí, reconocimiento de alto nivel buscando servidores clave —«normalmente controladores de dominio»— y movimiento lateral rápido entre equipos.

Y luego el movimiento que separa a un intruso oportunista de alguien que sabe lo que hace. Cita literal del fabricante: «una vez en esos dispositivos, los atacantes registraron un nuevo servicio para un túnel de CloudFlare, lo que les permitía persistir en el entorno después de que se les revocara el acceso al servidor N-central». Traducido: previeron que les iban a cerrar la consola y se abrieron una salida propia antes. Los indicadores que publican son de una modestia que asusta: un servicio llamado Cloudflared —que es una herramienta legítima de Cloudflare— y un fichero svchost.exe en la carpeta Documentos de un usuario, o sea un binario suplantando el nombre de un proceso de Windows. Y un dato que conviene dar aunque debilite el titular: Huntress dice que, a fecha de su última actualización, no ha visto ninguno de los dos en su telemetría.

Ese es el patrón: la herramienta de gestión haciendo exactamente su trabajo, con otro dueño. Un antivirus no tiene nada que marcar cuando la conexión remota la abre el software de gestión legítimo, firmado, instalado por el proveedor y autorizado en todas las políticas. Es el mismo motivo por el que en su día escribimos que parchear no es limpiar: cerrar la entrada no expulsa a quien ya está dentro, y aquí el túnel estaba puesto precisamente para sobrevivir al cierre.

El parche tampoco era el final

La ficha del KEV lo dice sin adornos: este fallo «es el resultado de un parche incompleto para CVE-2026-18556». O sea que la organización que hizo los deberes —vio el aviso, aplicó la corrección, cerró el ticket— siguió expuesta, y el intervalo entre una cosa y la otra no fue de meses: fue de días. Que un parche no cierre lo que dice cerrar ya lo hemos contado aquí y no vamos a repetir el argumento; lo que sí es nuevo está en la propia ficha de CISA: la acción requerida no se queda en «aplique el parche», remite a los requisitos de triaje forense de su directiva BOD 26-04. Es el regulador diciendo por escrito que actualizar no cierra el caso. «Actualizado» no es un estado: es la fecha de la última vez que miraste.

El número que separa lo gestionado de lo propio

Huntress fue publicando el porcentaje de servidores N-central que alcanza desde su propia telemetría —la de sus partners y clientes, no un censo del parque mundial— y que seguían sin parchear. La evolución de un solo día cuenta una historia entera. A las 00:45 (hora del Este) del 3 de agosto: un 55,6% de los servidores alojados en la nube del fabricante que Huntress veía, sin parchear. Trece horas y media después, a las 14:15: prácticamente todos los de la nube ya estaban al día, el total sin parchear había bajado al 13,6%… y los autohospedados seguían al 28,6%.

Vamos a decir lo que ese dato significa aunque no nos favorezca del todo: en este incidente concreto, el que tenía la consola alojada en el fabricante ganó por goleada. A las pocas horas su consola ya estaba parcheada sin que nadie de su equipo tuviera que despertarse. El que la tenía en casa —normalmente por buenas razones: control, datos, integraciones— dependía de que una persona leyera un correo un domingo. Nosotros operamos infraestructura propia y defendemos que hay cargas que deben estar en casa; eso no nos impide reconocer que para el plano de gestión, la actualización automática del fabricante es una ventaja real y medible, y aquí se midió.

El matiz, para no vender la moto del otro lado: esa misma automatización significa que el fabricante decide cuándo se toca tu consola. Ninguna de las dos opciones es gratis. Lo que no es defendible es la tercera, que es la habitual: tenerla en casa y parchearla cuando toque.

Esto no va de un fabricante

Sería fácil cerrar el post diciendo «vaya producto». Sería fácil y sería falso. Ese mismo producto ya había estado en el catálogo de CISA hace casi exactamente un año: CVE-2025-8875 y CVE-2025-8876, ambas dadas de alta el 13 de agosto de 2025. Dos veranos, tres entradas en el catálogo. Eso no es mala suerte: es lo que le pasa a cualquier cosa que concentre mucho privilegio sobre mucha gente. Las centralitas telefónicas manuales tenían el mismo problema de diseño: quien atendía las clavijas podía entrar en cualquier conversación de la ciudad. No era un defecto de quien hacía aquel trabajo, era la topología. Un siglo después la topología es idéntica y las clavijas son una consola web.

Y la tendencia de fondo está medida. El informe de brechas de Verizon de este año pone dos cifras juntas que describen exactamente este caso: el 48% de las brechas ya tienen un tercero implicado, un 60% más que el año anterior; y el 31% empiezan por la explotación de una vulnerabilidad, que es la primera vez en diecinueve años de informe que ese vector supera a las credenciales robadas. Un fallo en el software de un tercero que te gestiona es las dos cosas a la vez. Ya no es un escenario de manual: es la casilla más poblada del tablero.

La parte incómoda: nosotros somos ese tercero

Hacemos mantenimiento de parques informáticos, y mantener un parque de verdad exige poder llegar a él: un agente con privilegios en cada equipo, inventario, despliegue de parches y control remoto. No hay una versión ligera de eso. Quien te diga que gestiona tus equipos sin tener acceso privilegiado a tus equipos, o no los gestiona o no te lo está contando.

La conclusión fácil sería «pues quítate el agente». Es peor. Un parque sin gestionar es exactamente lo que describíamos al hablar de los BMC expuestos que no son de nadie: equipos con privilegio, sin dueño, sin inventario y sin nadie que los actualice. Entre un parque gestionado con un riesgo concentrado y conocido, y un parque sin gestionar con el riesgo repartido e invisible, el primero se defiende mejor. Pero se defiende mejor, no solo.

Lo que no vamos a escribir es que nuestra herramienta sea inexpugnable. Nadie que trabaje en esto puede firmar esa frase con la cara seria. Lo que sí se puede prometer es lo que pasa el día que falle, y eso sí se puede exigir por escrito, a nosotros y a cualquiera.

Seis cosas que puedes exigirle a tu proveedor

• Que la consola no esté publicada en Internet a pelo. Si es autohospedada, detrás de VPN o con lista de orígenes permitidos. Si es la nube del fabricante, con SSO y segundo factor obligatorio para todo el mundo, sin excepciones «temporales».
• Que las cuentas por defecto del fabricante tengan dueño o no existan. El «MSP Support» de este caso es el ejemplo perfecto: una cuenta que viene de fábrica, que nadie creó y que por lo tanto nadie vigila.
• Que el control remoto deje registro y que tú puedas leerlo. Quién se conectó, a qué máquina, cuándo y durante cuánto. Si eso existe pero solo lo ve el proveedor, es un registro para el proveedor, no para ti.
• Que exista una vía de corte que no dependa del proveedor. Cómo se revoca ese acceso en una tarde si hace falta. Y con el matiz que enseña este caso: cortar la consola no basta si alguien ya se abrió su propio túnel desde dentro; el corte tiene que ir acompañado de una revisión de servicios y salidas de red en los equipos.
• Que haya detección dentro de los equipos, no solo en la consola. Lo que delata este tipo de incidente no es un fichero: es una sesión remota a las cuatro de la mañana, un servicio nuevo, un salto hacia un controlador de dominio desde un equipo que nunca lo había tocado.
• Que el proveedor se comprometa a avisarte, con plazo. Esto ya no es solo buena educación: es lo que la trasposición de NIS2 traslada por contrato a la cadena de proveedores. Si tu proveedor se entera un viernes de que su consola estuvo abierta, tú deberías saberlo el viernes.

La pregunta que sí sirve

No preguntes «¿es seguro vuestro sistema de gestión?». Nadie va a contestar que no, y la respuesta no te dice nada. La pregunta que sirve es aburrida y concreta: «enséñame las últimas treinta conexiones remotas a mis equipos, con usuario, máquina, fecha y duración».

Si eso llega en un rato y en un formato que existía antes de que lo pidieras, hay una operación detrás. Si tarda tres días y llega escrito a mano en el cuerpo de un correo, ya tienes la respuesta a la primera pregunta. Y si no tienes proveedor externo porque lo lleváis en casa, la pregunta es exactamente la misma, solo que te la haces tú.

Nos ganamos la vida con ese privilegio. Lo mínimo es no fingir que no existe.

Fuentes (verificadas): alta de CVE-2026-18577 en el catálogo de vulnerabilidades explotadas el 03-08-2026, plazo del 06-08-2026, nombre del fallo y la frase «resultado de un parche incompleto para CVE-2026-18556»; altas previas de CVE-2025-8875 y CVE-2025-8876 el 13-08-2025: CISA, Known Exploited Vulnerabilities Catalog. Descripciones, fechas de publicación (01 y 02-08-2026), CWE-288 y puntuación 8,2 en CVSS 4.0 de ambos CVE: NVD. Aumento de incidencias de licenciamiento el 31-07-2026, uso de Take Control, cita literal sobre el túnel de CloudFlare, indicadores (Cloudflared, svchost.exe en Documentos), versiones afectadas y hotfix 2026.3.1.7: Help Net Security, 03-08-2026 y SecurityWeek, 03-08-2026. Cuenta «MSP Support», eventos de Windows 4102/8192/8193, reconocimiento hacia controladores de dominio y porcentajes de servidores sin parchear (55,6% a las 00:45 ET; 13,6% del total y 28,6% de los autohospedados a las 14:15 ET del 03-08-2026): Huntress. 48% de brechas con un tercero implicado (+60% interanual) y 31% iniciadas por explotación de vulnerabilidad, por primera vez por delante de las credenciales robadas en 19 años de informe: Verizon, Data Breach Investigations Report 2026. El criterio, la lectura del caso y las opiniones son nuestros.