Entraron por el puerto 5900 y salieron con root: el minero era lo de menos

El centro nacional de ciberseguridad de los Países Bajos actualizó su aviso NCSC-2026-0280 con una nota corta y desagradable, que la prensa recogió el 14 de agosto: han visto explotación activa del fallo de Compartir pantalla de macOS en varios sistemas que tenían el puerto 5900 accesible desde internet, y en todos los casos notificados el atacante había conseguido root y había dejado puesto un minero de Monero. Debajo del minero, que es lo que se ve, hay alguien con root en un equipo de la empresa.

Apple ya lo había arreglado. El 6 de agosto sacó fuera de ciclo macOS Tahoe 26.6.1, Sequoia 15.7.9 y Sonoma 14.8.9, con una frase de manual: un atacante en la red puede autenticarse contra Compartir pantalla sin credenciales válidas. No dijo que se estuviera explotando, y tampoco dijo lo contrario. Poco más de una semana después llegó el aviso de los holandeses, y con él la parte que no sale en las notas de seguridad: qué clase de máquinas eran esas.

Un validador que dice que sí cuando tocaba decir que no

El análisis técnico que ha publicado Huntress deja el fallo a la vista. En screensharingd, el demonio que sirve el escritorio remoto de macOS, la implementación de SRP —el protocolo que negocia la contraseña sin mandarla— tiene un validador de longitud de trama que devuelve un estado de éxito antiguo. Con eso basta: la conexión pasa a tratarse como autenticada. No hay contraseña que adivinar ni cuenta que exista. Es un fallo previo a la autenticación, que es el peor sitio donde puede estar.

Después no hay escalada de privilegios, porque ya se entra arriba. La ruta de autenticación VNC antigua se apoya en dos ayudantes privilegiados, SSFileCopySender y SSFileCopyReceiver, que por ahí corren como root. Y el primero no es un root cualquiera: SSFileCopySender lleva el entitlement kTCCServiceSystemPolicyAllFiles, que es acceso completo al disco saltándose TCC, el sistema que en macOS pregunta si tal aplicación puede leer tal carpeta. El receptor no lo lleva, y Huntress apunta el motivo probable: las implicaciones de saltarse TCC eran demasiado evidentes. Lectura y escritura arbitrarias, y ejecución de código como root. El minero de Monero, con eso a mano, es la opción menos ambiciosa que había encima de la mesa.

Y hay un segundo agujero en el mismo servicio, con menos ruido mediático: CVE-2026-43760, posterior a la autenticación, en el que cualquier usuario que haya entrado por el método VNC antiguo puede leer y crear cualquier fichero como root. O sea, que el mismo componente falla por delante y por detrás de la puerta.

El endurecimiento de siempre no tapaba este agujero

Hay una frase en el análisis de Huntress que casi no se ha repetido y que es la más importante de todo el caso: el endurecimiento estándar —quitar cuentas de la lista de usuarios permitidos, desactivar el VNC antiguo— no protege contra CVE-2026-65400. Quien había hecho los deberes estaba exactamente igual de expuesto que quien no los había hecho.

Y es un patrón, no una casualidad. Casi todo lo que llamamos endurecer consiste en limitar quién puede entrar: menos usuarios, menos métodos, menos permisos. Eso no cubre un fallo que precisamente no necesita que entres. Ayer mismo contábamos un caso de la misma familia en OpenSSH, donde bloquear el agente desactivaba precisamente las restricciones que uno le había puesto: el control existía, estaba bien configurado, y el fallo pasaba por otro sitio. Cuando el control y el fallo no comparten camino, el control no vale de nada por muy bien puesto que esté.

Compartir pantalla no viene encendido. Alguien lo encendió

En una instalación normal de macOS, Compartir pantalla está desactivado. Huntress lo señala con alivio explícito y añade el matiz que explica el resto del caso: está activado de fábrica en buena parte de los servicios de Mac alojado, esos Mac mini de alquiler que se usan para compilar aplicaciones o para tener una máquina de referencia.

La cifra que circula sobre cuántos hay expuestos viene de un escaneo de un investigador —Pedro Vilaça, que publica como @osxreverser— y la recoge The Hacker News: alrededor de 40.000 equipos con Compartir pantalla abierto en internet, casi la mitad en Estados Unidos. Quien hizo el escaneo matiza que la mayoría son direcciones residenciales, así que hay que tomarla por lo que es: la foto de un escaneo, no un censo. Pero en esa misma lista aparecen universidades, alguna empresa y hasta un servidor de la casa que hace BBEdit. Ahí es donde deja de ser un despiste doméstico y pasa a ser una decisión antigua que nadie ha vuelto a mirar.

La forma que tiene esto en una empresa mediana casi siempre es la misma, y no tiene nada que ver con macOS: alguien pide entrar desde casa a su equipo de la oficina, alguien deja accesible el Mac de la sala de reuniones para no subir a la primera planta, un proveedor conserva el acceso cuando el proyecto ya ha terminado. Se abre por una razón buena, se resuelve la urgencia y la regla del cortafuegos se queda ahí, sin dueño y sin fecha de caducidad.

La lista que casi nadie tiene

Casi toda empresa tiene una lista de equipos. Muy pocas tienen la otra lista, que es la que importaba aquí: qué escucha desde fuera, en qué IP, en qué puerto y por decisión de quién. El primero de esos inventarios sale del sistema de gestión del parque; el segundo hay que ir a buscarlo al perímetro de la red, y cambia cada vez que alguien toca una redirección de puertos.

Es lo mismo que escribíamos sobre los agentes de gestión remota de los proveedores de IT. Todo lo que sirve para llegar a una máquina de lejos —un agente, un escritorio remoto, un túnel— es a la vez la comodidad y la puerta, y casi siempre lo instaló alguien que ya no está en la conversación.

Qué se ve desde el equipo, si hay alguien mirando

Un servicio de detección gestionado hace aquí un trabajo muy concreto, y no es el que se suele vender. No impide el fallo: cuando el demonio te da por autenticado, no hay nada que impedir. Lo que hace es que la intrusión deje de ser invisible mientras dura. macOS publica los eventos de Compartir pantalla por su framework de Endpoint Security, y el análisis de Huntress da tres señales que valen para escribir una regla:

Un minero se delata solo: consume, calienta y no para. El problema del minero es que te acostumbra a pensar que el objetivo del atacante era tu factura de la luz. Con acceso completo al disco, en ese mismo equipo estaban las claves SSH, los tokens de sesión del navegador, el llavero y lo que hubiera sincronizado de la nube. Y ya escribimos hace unos días sobre familias de ransomware que lo primero que hacen es parar el agente de seguridad: si el que entra tiene root, tener un agente instalado y tener un agente vivo dejan de ser lo mismo. Por eso importa que alguien mire la telemetría desde fuera del equipo, y no solo que el icono esté en la barra.

Lo que haríamos esta semana

Cuándo esto no va contigo

Si en la empresa no hay ningún Mac, esto no es tu problema y no vamos a fabricarte uno. Si los hay pero ninguno publica nada hacia fuera, puedes esperar a tu ventana de mantenimiento habitual: la explotación que se ha visto necesita el 5900 alcanzable desde internet. Eso sí, no la alargues, porque la cronología de Huntress recoge pruebas de concepto publicadas por investigadores al poco de salir los parches de esta familia de fallos. Y tampoco te vamos a vender que un EDR habría evitado esto, porque no es verdad: habría hecho ruido, y a veces el ruido es todo lo que hay.

De todo el caso, lo que nos quedamos no es el CVE. Los CVE vienen y van, y este además tiene arreglo desde el 6 de agosto. Se queda que el fallo solo hizo daño donde había un puerto abierto que nadie recordaba haber abierto, y que ningún boletín de seguridad te va a avisar de eso: es una lista que te tienes que hacer tú, y que caduca cada vez que alguien resuelve una urgencia un viernes por la tarde.

Fuentes (verificadas el 17 de agosto de 2026): actualización del aviso NCSC-2026-0280 del NCSC de los Países Bajos sobre abuso activo en sistemas con el puerto 5900 accesible desde internet, con obtención de root y minero de Monero en todos los casos notificados, recogida el 14 de agosto por BleepingComputer (14-ago-2026), Security Affairs y SC Media; parche del 6 de agosto de 2026 en macOS Tahoe 26.6.1, Sequoia 15.7.9 y Sonoma 14.8.9, redacción de Apple («un atacante en la red puede autenticarse contra Compartir pantalla sin credenciales válidas», corregido con «gestión de estado mejorada»), crédito del hallazgo a Alfredo Pesoli (Bynario Atlas) y ausencia de mención a explotación en el momento del parche, según la nota de seguridad de Apple recogida por Security Affairs y 9to5Mac; detalle técnico del validador de longitud de trama de SRP que devuelve un estado de éxito antiguo, ayudantes SSFileCopySender y SSFileCopyReceiver ejecutándose como root por esa ruta (con el entitlement kTCCServiceSystemPolicyAllFiles solo en SSFileCopySender; el receptor no lo tiene), CVE-2026-43760 posterior a la autenticación, hecho de que Compartir pantalla no viene activado por defecto pero sí en muchos servicios de Mac alojado, inutilidad del endurecimiento estándar frente a CVE-2026-65400, cronología con pruebas de concepto publicadas por investigadores y las tres señales de detección por Endpoint Security, del análisis de Huntress; cifra aproximada de 40.000 equipos con Compartir pantalla abierto en internet (casi la mitad en EE. UU., la mayoría direcciones residenciales, con universidades y alguna empresa en la misma lista), de un escaneo del investigador Pedro Vilaça (@osxreverser) recogido por The Hacker News; los dos vectores CVSS y sus fechas (6 y 14 de agosto de 2026), de la ficha del NVD, cuya discrepancia con la puntuación de 7,1 publicada por SC Media el 14 de agosto queda así explicada. Las citas en castellano de textos originalmente en inglés son traducción nuestra. La lectura sobre los dos inventarios, la tesis de que el endurecimiento y el fallo no comparten camino y la lista de comprobaciones son nuestras, no de las fuentes.