Soporte remoto: el fichero se ejecuta en la máquina del técnico

Cuando alguien de tu proveedor de IT abre una sesión remota contra un ordenador tuyo, lo que se comparte es un canal, no una pantalla. Y un canal tiene dos extremos. Casi todo lo que se escribe sobre riesgo de proveedor asume que el peligro baja —que le entran a él y desde su consola llegan a ti—. El aviso que CISA publicó ayer describe el camino contrario, y lo dice el propio fabricante con todas las letras: «los servidores de ScreenConnect no están afectados». Los afectados son los equipos desde los que se atiende.

Qué dice exactamente el aviso

El boletín de ConnectWise lleva fecha del 8 de septiembre de 2026 y una frase corta: «una condición en el cliente de ScreenConnect puede permitir que se transfieran y ejecuten ficheros a través de una sesión remota activa sin autorización ni confirmación del Host, en determinadas circunstancias». Es CVE-2026-84869, con 9,9 y vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Se arregla en la versión 26.6.5. Y aquí va la letra pequeña que conviene no saltarse: el boletín le dice a los clientes de nube que no tienen que hacer nada… y acto seguido, a todos, que «después de actualizar, asegúrate de reinstalar tus clientes Host y actualizar tus agentes de acceso». Como el fallo vive en el cliente, actualizar el servidor no toca el portátil del técnico.

La parte que nos hizo levantar la vista está dos líneas más abajo, en la tabla de alcance: los servidores no están afectados; los clientes Host, sí. En el vocabulario de ScreenConnect, el Host es quien se conecta para ayudar. O sea, el portátil del técnico. Nuestra lectura —y la marcamos como nuestra— es que eso invierte la dirección que todo el mundo tiene en la cabeza: durante una sesión legítima, lo que acaba ejecutando un fichero que nadie confirmó no es el equipo del cliente, sino el de quien está al otro lado prestando el servicio.

La mitigación delata al vector

Cuando un fabricante no puede darte el parche al momento, la alternativa que ofrece suele explicar el fallo mejor que el propio texto del aviso. Aquí la alternativa es: entra en Administración > Seguridad > Roles y desmarca el permiso TransferFiles en los grupos de sesión. No hay filtro de red que sirva, ni regla de cortafuegos, ni reinicio. Lo que se apaga es una función, y una de las que se usan cuarenta veces al día. Esa era, además, la única defensa disponible durante cinco días: ConnectWise publicó un aviso sobre el comportamiento de la transferencia de ficheros el jueves 3 de septiembre, diciendo que el identificador CVE y la corrección oficial llegarían dentro de la misma semana, y el parche no salió hasta el 8.

El otro extremo: dos parches urgentes en dos días

Tres días antes que ScreenConnect, el 8 de septiembre, CISA había metido en la misma lista CVE-2026-86218, en N-able N-central: inyección de código estático (CWE-96), ejecución remota sin autenticar y un 10,0 redondo. La corrección es la build 2026.3.1.14, publicada por el fabricante el 6 de septiembre a las 03:47. El día anterior, el 5, ese mismo fabricante había publicado otra: la build 2026.3.1.13, que cerraba CVE-2026-86206 (6,9) y CVE-2026-86207 (7,7), reportadas por Rapid7 y Huntress. Dos actualizaciones de emergencia, en días consecutivos, en la pieza desde la que se administra el parque entero de una cartera de clientes.

Y no es casualidad que sea el mismo producto del que escribimos el 4 de agosto, cuando dos saltos de autenticación consecutivos —el segundo, parche incompleto del primero— nos hicieron contar desde dentro por qué el agente de tu proveedor de IT es superficie de ataque. Entonces la rama iba por la corrección 2026.3.1.7. Han pasado cinco semanas y va por la 2026.3.1.14. No pretendemos que el número de build sea una métrica de calidad, no lo es; pero esos dígitos son ventanas de mantenimiento que alguien tuvo que abrir, de madrugada, en producción, sin avisar con quince días.

Dos fabricantes, la misma frase, y CISA diciendo otra cosa

N-able escribe, sobre CVE-2026-86218: «no tenemos confirmaciones de que esta vulnerabilidad se haya explotado en entornos de producción, pero los sistemas sin parchear siguen en riesgo». El boletín de ConnectWise, en su versión del 8 de septiembre, no menciona explotación. Y sin embargo los dos avisos están en el catálogo KEV de CISA, que por definición recoge vulnerabilidades explotadas conocidas: el de N-central entró el 8 con fecha límite el 11, y el de ScreenConnect entró el 11 con fecha límite el 14, que es el lunes.

No lo contamos para señalar a nadie. Un fabricante afirma lo que puede sostener con su propia telemetría, y es honesto que no afirme de más. Lo contamos porque la señal útil llegó por otro lado y bastante antes. Sobre el fallo de N-central, Arctic Wolf escribe que «se observó explotación antes de la divulgación pública, e investigadores independientes han reproducido la vulnerabilidad». Si esperas a que el fabricante confirme, mueves ficha tarde. Y la entrada en el catálogo tampoco es el principio de la historia: desde la directiva BOD 26-04 la acción requerida ya no se limita a «parchea», pide triaje forense, que traducido significa asumir que igual no llegaste el primero.

Los hemos contado: quince en lo que va de 2026

Dos avisos de la misma familia en tres días parecían muchos, así que en vez de opinar nos bajamos el fichero. El catálogo KEV se publica en JSON abierto; la versión que usamos es la 2026.09.11, con 1.709 entradas. Del 1 de enero al 11 de septiembre de 2026 hay 225 altas. De esas, quince son de programas cuyo trabajo consiste en gobernar ordenadores que no son suyos:

• N-able N-central — 3 (3 y 4 de agosto, 8 de septiembre)
• SimpleHelp — 3 (dos el 24 de abril, una el 29 de junio)
• Ivanti Endpoint Manager Mobile — 3 (29 de enero, 8 de abril, 7 de mayo)
• ConnectWise ScreenConnect — 2 (28 de abril, 11 de septiembre)
• Ivanti Endpoint Manager — 1 (9 de marzo) y BeyondTrust Remote Support / PRA — 1 (13 de febrero)
• Microsoft Configuration Manager — 1 (12 de febrero) y Quest KACE Systems Management Appliance — 1 (20 de abril)

Quince. Microsoft Windows, en ese mismo periodo, suma trece. No hace falta ninguna estadística de cuota de mercado para saber cuál de los dos conjuntos está instalado en más sitios. Para comparar con el año pasado: en todo 2025 esa familia —contando además LANSCOPE Endpoint Manager, de Motex— sumó once entradas. Vamos por quince y quedan tres meses y medio.

Dos matices, porque sin ellos el número engaña. El primero: el KEV no mide cuántos fallos tiene un producto, mide de cuáles consta a CISA que se están explotando; un producto muy vigilado aparece más. El segundo, y es el importante: la frontera de la familia la hemos puesto nosotros, así que la publicamos entera para que puedas discutirla. Dentro va lo que administra o toma el control de ordenadores. Fuera hemos dejado tres cosas que rozan la categoría —SolarWinds Web Help Desk (tres altas; es ticketing), SolarWinds Serv-U (una; transferencia de ficheros) e Ivanti Sentry (una; pasarela)— y, sobre todo, los planos de gestión de equipos de red, que son otra familia con el mismo problema: Cisco Catalyst SD-WAN Manager (cuatro), Cisco Secure Firewall Management Center (tres) y Check Point SmartConsole (una). Métete esas ocho y el número se va a veintitrés. El método de recuento es el mismo que usamos cuando contamos qué edad tienen de verdad los fallos del catálogo: descargar el JSON y contar con jq, para que cualquiera lo rehaga.

No es que el código sea peor. Es que el premio es mejor

La tentación es concluir que estos productos están mal hechos. No lo creemos, y desde luego no lo podemos demostrar. Lo que sí tienen los seis en común son tres propiedades que, juntas, describen el objetivo ideal: concentran privilegio (una consola manda sobre el parque entero de muchas empresas a la vez), son alcanzables por red porque si no, no sirven, y guardan credenciales de acceso permanente a sitios donde nadie más entra sin llamar. Un atacante que elige dónde invertir su tiempo compara el radio de la explosión.

Y por eso el fallo de ScreenConnect nos parece el más interesante de los dos, aunque su nota sea una décima menor. El de N-central es la historia conocida: rompen el concentrador, bajan a todo el mundo. El otro dice que la sesión de soporte, esa que abrimos con la conciencia tranquila porque «entramos nosotros», puede funcionar en sentido contrario. Y la máquina del técnico es, casi siempre, la máquina desde la que se entra a todas las demás. Lo mismo que nos preguntamos en su día sobre quién puede apagar tus servidores, pero mirando hacia dentro de casa.

Tres preguntas para tu proveedor de IT. También para nosotros

Somos proveedor de servicios gestionados, así que esto va de nosotros tanto como de cualquiera. No vamos a recomendarte una herramienta concreta —cambiar de marca no cambia la categoría—, pero sí las preguntas que nos parecen justas. Si quien te atiende no sabe responderlas en una llamada, ya has aprendido algo:

1. ¿Cuánto tardaste en aplicar el último parche de emergencia de tu consola? No «¿parcheáis?». La fecha concreta del último, y quién lo hizo a las tres de la mañana. Si la respuesta empieza por «bueno, nosotros vamos con la versión en nube», es una respuesta buena: el fabricante te lo actualiza y te enteras después. Pero entonces la pregunta siguiente es qué pasó mientras.
2. ¿Los equipos de vuestros técnicos están gestionados como los míos? Después de lo de ScreenConnect, ésta ya no es retórica. Portátil con disco cifrado, EDR gestionado con alguien mirando la consola, sin cuentas de administrador local compartidas y sin instalar lo que haga falta «para esta incidencia».
3. ¿Qué permisos tiene el rol con el que se conectan a mi empresa? La mitigación del aviso de esta semana es desmarcar una casilla de un rol. Eso significa que los roles existen y que alguien decidió cómo están. ¿Todos los técnicos tienen transferencia de ficheros y sesión desatendida sobre todo el parque, o se pide por ticket?
4. ¿Cómo sabéis que TODOS los clientes Host de vuestros técnicos están actualizados y reinstalados? Ésta es específica del fallo de esta semana y es la que más gente va a fallar. El servidor se actualiza en un sitio; los clientes Host están repartidos por los portátiles de la gente, y el boletín pide reinstalarlos uno a uno. «Está en la nube» no responde a esta pregunta.

Y ahora la parte incómoda, que es contestarlas nosotros. No publicamos qué consola de control remoto usamos, y la razón no es la seguridad por oscuridad, que no funciona: es que decirlo convierte esta conversación en una comparativa de marcas, y la marca es justo lo que no importa. Lo que sí podemos poner por escrito es lo de siempre. Nuestra monitorización es Zabbix con SmokePing, la fuente de verdad de la red es NetBox y la automatización interna corre sobre n8n autoalojado. Ninguna de las cuatro es glamurosa y ninguna es una consola de soporte remoto, pero todas comparten lo único que aquí importa: están inventariadas, tienen dueño con nombre y apellidos y tienen ventana de actualización, igual que si fueran de un cliente. El día que una herramienta interna se queda fuera del inventario, lo que tienes es una máquina con permisos sobre las demás y sin nadie mirándola.

Lo que este post no arregla

Hay que separar los dos casos, porque «lo tenemos en la nube» sirve para uno y no para el otro. Con N-central es cierto: el fabricante parcheó los entornos alojados y quien está ahí no tuvo que hacer nada. Con ScreenConnect no, y ésa es la trampa del aviso: el fallo está en el cliente, así que el servidor gestionado queda al día mientras el portátil del técnico sigue con la versión vieja hasta que alguien lo reinstala a mano. La otra cara, para los dos: la ventana en la que el sistema fue vulnerable existió, la gestionó otro y no la viste. Y el parche no deshace lo que pasara antes, que es lo que escribimos hace dos días sobre el parche de Cisco que cierra la puerta pero no te devuelve el plano. Una precisión honesta sobre lo de arriba: no afirmamos que se esté explotando el CVE de ScreenConnect. Lo que sí está documentado es el mecanismo, y por otra vía. En agosto, Huntress publicó tres incidentes en organizaciones sin relación entre ellas —el 20 y el 24— en los que unos clientes ScreenConnect manipulados, instalados con ingeniería social y no explotando ningún fallo, metían una cadena de cuatro VBScript en un mensaje de transferencia de ficheros; conectarse a uno de esos clientes hacía que el sistema Host recibiera y ejecutara la misma cadena. Aquello necesitó un cliente manipulado. Lo que el fabricante ha descrito en septiembre es una condición del cliente normal. Y no, tampoco te decimos que cambies de herramienta: te decimos que la categoría tiene una propiedad incómoda y que conviene mirarla antes de que la mire otro.

Nota de fuentes

Todo se ha contrastado el 12 de septiembre de 2026. ScreenConnect: boletín de seguridad de ConnectWise del 8 de septiembre de 2026 y su divulgación pública para CVE-2026-84869 (descripción literal, 9,9 con vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, versiones anteriores a 26.6.5, «ScreenConnect servers are not impacted», sistemas Host afectados, y la mitigación de desmarcar TransferFiles en Administración > Seguridad > Roles). N-central: aviso de N-able del 6 de septiembre de 2026 a las 03:47 (hotfix 4, build 2026.3.1.14, CVE-2026-86218, la frase sobre ausencia de confirmaciones de explotación y la indicación de que los entornos en nube ya están parcheados) y el del 5 de septiembre (hotfix 3, build 2026.3.1.13, CVE-2026-86206 y CVE-2026-86207, con crédito a Rapid7 y Huntress). Recuento propio: fichero JSON público del catálogo KEV de CISA, versión 2026.09.11 publicada el 11-sep-2026 a las 19:32 UTC, 1.709 entradas, descargado con curl y contado con jq; de él salen las 225 altas de 2026, las quince de la familia de gestión y acceso remoto con su desglose por producto y fecha, las trece de Microsoft Windows en el mismo periodo, las ocho de los planos de gestión de red que declaramos excluidas, las once de 2025 y las fechas y plazos de las dos entradas de esta semana (CVE-2026-86218 alta el 8 con plazo el 11; CVE-2026-84869 alta el 11 con plazo el 14), además de la referencia a la directiva BOD 26-04 y a sus requisitos de triaje forense que figuran en el propio campo de acción requerida. Los CVSS de CVE-2026-86206 y CVE-2026-86207 proceden del análisis publicado por Rapid7. La cita sobre explotación previa a la divulgación es de Arctic Wolf («Exploitation was observed prior to public disclosure, and independent researchers have reproduced the vulnerability»). El aviso previo de ConnectWise del jueves 3 de septiembre, con el anuncio de que el CVE y la corrección llegarían esa misma semana, está recogido por SecurityWeek (7-sep-2026). Los tres incidentes de agosto con clientes ScreenConnect manipulados (20 y 24 de agosto, organizaciones sin relación entre ellas, acceso inicial por estafa de soporte con Quick Assist, un instalador MSI por phishing y un formulario falso de devolución; cadena de cuatro VBScript empaquetada en un mensaje de transferencia de ficheros y ejecutada por el sistema Host al conectarse) son de Huntress, que declara expresamente que NO explotan CVE-2026-84869. Es lectura NUESTRA y no de las fuentes: que el alcance declarado por ConnectWise invierta la dirección habitual del riesgo de proveedor; que la mitigación por permiso de rol revele que el vector es una función del producto; la definición de la familia de productos contada y su frontera, declarada arriba con lo que dejamos fuera; la comparación con Windows; y las seis preguntas. La fotografía de portada es «Disassembled iMac at a computer repair service», de Ivan Radic, publicada en Wikimedia Commons bajo licencia Creative Commons CC BY 2.0 y recortada por nosotros para el formato de portada.