ConnectWise ScreenConnect: CVE-2026-84869 infecta la máquina del técnico

ConnectWise publicó el 8 de septiembre la corrección de CVE-2026-84869, una falla con 9,9 en CVSS 3.1 en el cliente de ScreenConnect. La descripción del fabricante es breve y vale leerla con atención, porque dice algo que se lee mal de apuro: "this could allow files to be transferred to and executed on the Host client system, including through elevated execution actions."

En el sistema del Host. El Host, en ScreenConnect, es el técnico: la persona que se conecta a asistir. La falla no permite atacar el equipo del cliente desde afuera; permite que el equipo del cliente ataque a quien se conecta a ayudarlo.

CISA la sumó al catálogo de explotación activa el 11 de septiembre con plazo al 14. Huntress documentó su explotación en ataques reales desde el 20 de agosto, 19 días antes de que existiera el parche.

Dos detalles del vector que explican el resto de la nota: PR:L significa que hace falta un privilegio bajo, que acá es simplemente tener una sesión activa; y S:C, scope changed, es la forma en que CVSS dice que el daño sale del componente vulnerable y cae sobre otro. Es exactamente lo que pasa: la sesión cruza de una máquina a la otra.

¿Por qué CVE-2026-84869 ataca al técnico y no al cliente?

En una sesión de soporte normal el flujo de confianza va en una sola dirección: el técnico manda, el equipo asistido obedece, y las acciones sensibles —transferir un archivo, ejecutarlo— requieren que el Host las apruebe. Esa aprobación es el control que la falla anula.

Lo que Huntress reconstruyó es un cliente de ScreenConnect modificado, instalado en el equipo de la víctima por vías que no tienen nada de sofisticadas: estafas de soporte técnico falso, correos con instaladores maliciosos y formularios de reembolso apócrifos en resultados de búsqueda. Ese cliente modificado se queda esperando.

El detalle técnico que Huntress documenta es preciso y explica por qué esto funciona sin que nadie haga clic: el cliente modificado lee la colección de conexiones que ScreenConnect mantiene (EndPointStatusMessage.Connections), filtra las sesiones de Host que no había visto antes por su identificador de conexión, arma un mensaje de transferencia de archivos con la acción puesta en Run y lo encola hacia esa sesión nueva. Sin la falla, ahí el Host tendría que aprobar. Con la falla, no.

De ahí sale la parte que Huntress llama propagación de tipo gusano: la máquina del técnico, ya infectada, se conecta a otros clientes, y el ciclo se repite. El radio de impacto de un solo cliente infectado es la cartera entera del proveedor.

Es la misma lección que dejó N-able N-central hace una semana, pero por un camino distinto: allá la falla estaba en el servidor de administración; acá está en la sesión de soporte, y no hace falta que el proveedor tenga nada mal configurado. Le alcanza con atender a un cliente infectado.

Lo que el aviso de ConnectWise no dice

Acá hay una diferencia de tono que conviene marcar, porque cambia la urgencia con la que uno reacciona.

El aviso de ConnectWise describe el problema como "a condition in the ScreenConnect client" y una "client-side file-transfer handling condition". Es una redacción cuidadosa y técnicamente correcta, pero en todo el documento no hay una sola mención a explotación, a ataques observados ni a actividad en la vida real. Quien lea solamente el boletín del fabricante se lleva la impresión de una corrección de comportamiento que conviene aplicar.

La evidencia de explotación viene de otro lado: la publicó Huntress, que documentó tres organizaciones afectadas —dos incidentes el 20 de agosto y uno el 24— y describió la cadena completa. Y CISA la incorporó al catálogo de explotación activa el 11 de septiembre, que es la confirmación oficial.

No es una acusación: un fabricante puede tener razones legítimas para no detallar incidentes de clientes, y ConnectWise sí publicó el parche y una mitigación temporal. Es una observación práctica sobre de dónde sale la señal de urgencia, y se repite: con MikroTik el aviso del fabricante decía que no publicaba detalles mientras CERT Polska confirmaba ataques en curso. La regla que queda es incómoda pero útil: el boletín del fabricante dice qué arreglar; rara vez dice cuán tarde vas.

Las herramientas del proveedor de IT llevan nueve entradas al catálogo en 2026

Vale la pena mirar esto con números, porque deja de parecer mala suerte.

Contando en el catálogo de CISA las entradas de herramientas de administración y acceso remoto —ScreenConnect, N-able N-central, SimpleHelp, BeyondTrust, Kaseya VSA, TeamViewer—, son 20 en toda la historia del catálogo. De esas, 9 son de 2026, casi tantas como las once de todos los años anteriores juntos.

Para ScreenConnect en particular es la cuarta entrada: CVE-2024-1709 en febrero de 2024, CVE-2025-3935 en junio de 2025, CVE-2024-1708 en abril de 2026 y esta.

La lectura no es que estas herramientas sean malas, sino que son el objetivo correcto. Una consola que administra cien empresas vale cien veces más que cualquiera de esas empresas por separado, y el atacante lo sabe. Es el mismo razonamiento por el que en PaperCut los atacantes, una vez adentro, instalaban un agente de acceso remoto legítimo para quedarse.

¿A quién afecta CVE-2026-84869?

A toda instalación de ScreenConnect anterior a 26.6.5, pero con una distinción que decide qué tenés que hacer:

• En la nube de ScreenConnect: ConnectWise ya actualizó los servidores y dice que no hace falta acción del lado del servidor. Pero recomienda expresamente actualizar los clientes de Host y los agentes de acceso, que es donde está la falla. No alcanza con que el servidor esté al día.
• En instalación propia (on-premise): hay que actualizar a 26.6.5 o posterior. Para los que lo tienen integrado con Automate, la actualización va por Automate Product Updates y requiere la suscripción de Automate Assurance activa.

Hay además un obstáculo administrativo que ConnectWise menciona y que en la región es más común de lo que parece: si la licencia está fuera de mantenimiento, hay que renovarla antes de poder instalar la versión corregida. Conviene averiguarlo hoy y no el día que se decida actualizar.

Los servidores de ScreenConnect no están afectados por esta falla. El componente vulnerable es el cliente.

¿Quién puede ignorar el aviso de ConnectWise?

Quien no use ScreenConnect ni reciba soporte de alguien que lo use. Es una herramienta concreta: si tu proveedor te asiste por AnyDesk, TeamViewer, Quick Assist o una VPN, esta falla puntual no te toca.

Ahora, la pregunta de fondo sí aplica igual, y es la única parte de esta nota que sirve sin tener ScreenConnect: cuando alguien de afuera se conecta a tus equipos, ¿qué otros equipos toca esa misma persona ese mismo día? La respuesta define tu exposición real, cualquiera sea la herramienta.

¿Cómo sé si mi ScreenConnect fue usado para esto?

El indicador más directo está en el propio registro de sesiones de ScreenConnect. Huntress señala buscar entradas de tipo RunFiles o RanFiles en las que los archivos ejecutados sean sospechosos y, sobre todo, en las que el origen sea Process: Guest. Un archivo que se ejecuta en la sesión y que no lo lanzó el técnico es toda la anomalía: en una sesión de soporte legítima, quien ejecuta cosas es el Host.

En los equipos, las señales que Huntress documenta:

• Ejecución de wscript.exe como proceso hijo del cliente de ScreenConnect. Un cliente de escritorio remoto no tiene por qué lanzar el intérprete de scripts de Windows.
• Una cadena de cuatro scripts llamados 1.vbs, 2.vbs, 3.vbs y 4.vbs, copiados bajo C:\Users\Public\Libraries\Default\Lib\Lib1.
• Persistencia por clave de registro de usuario: HKCU\Software\Microsoft\Windows\CurrentVersion\Run con el valor WindowsServiceHost, apuntando a un WindowsServiceHost.vbs en el AppData del usuario.
• Archivos temporales value.txt y map.txt en %TEMP%.
• Herramientas de acceso remoto adicionales que nadie instaló, del tipo UltraViewer o AnyDesk.

Huntress publicó además la lista completa de hashes y de infraestructura de mando y control en su análisis. Conviene tomarlos de ahí, de la fuente, y no de una copia: son cadenas largas donde un carácter cambiado arruina la búsqueda.

Y la advertencia de fondo, que es la de siempre cuando hay ejecución de código: si aparece cualquiera de estos rastros, el problema no se arregla actualizando. El SOC de Huntress recomendó reinstalar los equipos desde medios limpios, por la cantidad de mecanismos de persistencia involucrados.

¿Qué hago si mi proveedor de IT usa ScreenConnect?

1. Preguntá hoy en qué versión está, servidor y clientes. Si es anterior a 26.6.5, la respuesta correcta no es "lo vemos la semana que viene": hubo 19 días con ataques y sin parche, y el catálogo de CISA venció el 14.
2. Si administrás vos la instalación, actualizá a 26.6.5 o posterior. En la nube, además, reinstalá los clientes de Host y los agentes de acceso: el servidor actualizado no arregla un cliente viejo.
3. Si no podés actualizar ya, aplicá la mitigación temporal del fabricante: en Administration > Security > Roles, editar cada rol, revisar cada grupo de sesión con permisos asignados y desmarcar el permiso TransferFiles. Hay que repetirlo rol por rol. ConnectWise aclara que no reemplaza al parche, y tiene razón: apaga la función de la que abusa el ataque, no la falla.
4. Revisá el registro de sesiones de las últimas semanas buscando ejecuciones con origen Guest, y los equipos —incluido el del técnico— contra los indicadores de arriba.
5. Verificá que el EDR esté mirando las sesiones de soporte. En esta cadena la detección realista no es la falla sino la conducta: un cliente de escritorio remoto que lanza wscript.exe, o una clave de arranque nueva en HKCU. Si no tenés nada que vea eso, el criterio para decidirlo está en EDR o antivirus, cuándo se justifica y las opciones en antivirus y EDR.
6. Dejalo por escrito. Esta es la clase de pregunta que conviene hacer una vez y archivar: qué herramienta usa el proveedor, en qué versión, y quién avisa cuando sale un parche crítico. El formato está en cómo responder un cuestionario de seguridad, que sirve igual para preguntar.

El orden general de prioridades está en la guía de ciberseguridad para PyMEs de LATAM y los términos, en el glosario.

Preguntas frecuentes sobre CVE-2026-84869 y ScreenConnect

Si mi ScreenConnect está en la nube, ¿ya estoy cubierto?

No del todo, y es la confusión más fácil de cometer con esta falla. ConnectWise actualizó los servidores de su nube, pero la vulnerabilidad está en el cliente, no en el servidor. El propio aviso recomienda reinstalar los clientes de Host y los agentes de acceso. Un servidor al día con clientes viejos deja el problema intacto.

¿Alcanza con desmarcar el permiso TransferFiles?

Es la mitigación que publica ConnectWise y reduce la exposición, pero el fabricante dice explícitamente que no sustituye a la actualización. Desmarcar TransferFiles apaga la función de la que se abusa; la condición defectuosa sigue ahí. Sirve para atravesar una ventana de mantenimiento o un congelamiento de cambios, no como solución.

¿Por qué el puntaje es 9,9 si hace falta una sesión activa?

Porque lo que CVSS castiga acá no es la dificultad de entrar sino hasta dónde llega el daño. El vector lo dice: PR:L reconoce que hace falta un privilegio bajo —una sesión en curso—, pero S:C indica que el alcance cambia, o sea que el impacto cae sobre un componente distinto del vulnerable. Una sesión de soporte rutinaria termina comprometiendo la máquina desde la que se administran todos los demás clientes.

El técnico se conectó a mi equipo esta semana. ¿Tengo que hacer algo?

Si tu equipo estaba limpio, el riesgo para vos es bajo: esta falla usa al cliente infectado para atacar al técnico, no al revés. Lo que sí corresponde es avisarle a tu proveedor, porque el que tiene que revisar su máquina es él, y si atendió a otro cliente comprometido el problema viaja hacia vos por la conexión siguiente. Dicho de otro modo: acá el que tiene que demostrar que está limpio es el que asiste.

¿Cómo distingo una instalación de ScreenConnect legítima de una falsa?

Por el origen, no por el aspecto: el instalador falso se ve igual que el real porque es ScreenConnect, apuntando al servidor del atacante. La comprobación práctica es confirmar con tu proveedor, por un canal que no sea el del pedido, que esa sesión la inició él. Las vías de entrada que documentó Huntress fueron estafas de soporte técnico, correos con instaladores y formularios de reembolso falsos en resultados de búsqueda: en los tres casos el instalador llegó porque alguien lo pidió o lo buscó.