Un Mac con Compartir pantalla activado y el puerto 5900 alcanzable desde Internet se entrega entero a quien conozca su dirección IP. No hay contraseña que adivinar ni correo trampa que abrir. El atacante llega con permisos de root, y en todos los casos observados hasta ahora acaba instalando un minero de la criptomoneda Monero.
El aviso lo dio el centro nacional de ciberseguridad de Países Bajos (NCSC-NL), que actualizó su alerta al recibir constancia de explotación real. La noticia se difundió el 14 de agosto de 2026, ocho días después de que Apple publicara la corrección de CVE-2026-65400.
Cronología: ocho días entre el parche y el aviso de explotación
El fallo no apareció solo. Forma parte de una tanda de problemas en el servidor de Compartir pantalla de macOS que Apple fue corrigiendo a lo largo de dos semanas, y esa secuencia explica por qué mucha gente perdió la cuenta de qué había parcheado y qué no.
El 27 de julio Apple publicó la oleada 26.6, 15.7.8 y 14.8.8. El 29 de julio se difundieron dos investigaciones el mismo día: una sobre un fallo posterior a la autenticación y otra que apuntaba a un problema previo a la autenticación en el propio proceso en segundo plano del servicio. A primeros de agosto circulaba ya código de prueba público. El 6 de agosto Apple publicó la actualización que cierra CVE-2026-65400 en macOS Tahoe 26.6.1, Sequoia 15.7.9 y Sonoma 14.8.9. El 14 de agosto se difundía el aviso del NCSC-NL sobre abuso activo, según recogen BleepingComputer y The Hacker News.
Ocho días entre la corrección y el aviso de explotación activa. Para un servicio de este perfil, ese margen se agota antes de que el asunto llegue siquiera al comité de cambios.
Un apunte sobre el impacto, porque las fuentes no coinciden: el registro de la NVD puntúa el fallo con un 9,8 sobre 10, mientras que SC Media publicó un 7,1. El número no debería decidir el parcheo. Aquí lo determinante es otra cosa: hay explotación confirmada y no se necesitan credenciales.
Qué falla exactamente, en términos conceptuales
Compartir pantalla es la función de escritorio remoto que trae macOS de serie. Habla el protocolo RFB, la base de VNC, sobre el puerto TCP 5900, y admite dos caminos de autenticación: el nativo de Apple, contra una cuenta real del sistema, y uno heredado de VNC con una contraseña única no asociada a ningún usuario.
El camino nativo se apoya en SRP, un protocolo de contraseña remota segura. El análisis de Huntress describe el defecto en términos que cualquier desarrollador reconoce: el proceso en segundo plano (demonio) comprueba la longitud de la trama recibida y, ante una de tamaño excesivo, devuelve un valor de éxito que en realidad arrastraba de la operación anterior. La máquina de estados lee ese valor como «este paso de autenticación ha ido bien» y avanza. La sesión continúa además en claro, sin cifrado.
Apple lo resume en su aviso como un problema de autenticación resuelto mediante una mejor gestión de estados, y acredita el hallazgo al investigador Alfredo Pesoli, de Bynario. No hay corrupción de memoria, ni condición de carrera que ganar, ni protección de memoria que sortear: es un fallo de lógica. Por eso no depende de la suerte, y contra una máquina sin parchear se comporta de forma determinista.
El resultado práctico es lectura y escritura de ficheros arbitrarios como root, apoyándose en los procesos auxiliares que el servicio usa para copiar ficheros. Uno de ellos porta un permiso especial firmado por Apple que concede acceso total al disco y esquiva por completo el marco de privacidad TCC del sistema.
Hay dos identificadores que se confunden a diario. CVE-2026-43760 es un fallo posterior a la autenticación: exige que el atacante ya tenga la contraseña VNC heredada. CVE-2026-65400 no exige nada parecido. Según el análisis de Calif, lo único que necesita es nombrar una cuenta existente del sistema, y los nombres de usuario no son secretos: macOS los muestra en la pantalla de inicio de sesión.
Por qué el endurecimiento habitual no sirve aquí
Aquí falla lo que uno haría por instinto. Quitar las cuentas autorizadas para el acceso remoto no cambia nada. Desactivar la autenticación heredada por contraseña VNC tampoco. Rotar esa contraseña, lo mismo: cero. El fallo se dispara antes de que ninguna de esas comprobaciones entre en juego, así que el endurecimiento de configuración no reduce la exposición en absoluto.
Solo hay dos medidas que funcionan: aplicar la actualización o apagar el servicio.
¿Quién está expuesto de verdad?
Compartir pantalla no viene activado de serie, y esa es la buena noticia. La mala es dónde sí viene activado.
Huntress señala un foco concreto: los proveedores de Mac alquilados en la nube, esos Mac mini que se han vuelto habituales para compilar aplicaciones de Apple o ejecutar cargas de trabajo puntuales. Varios de esos proveedores entregan la máquina con SSH y Compartir pantalla ya encendidos, y algunos seguían aprovisionando imágenes con versiones anteriores a la corregida. Una búsqueda somera en Censys, apunta la firma, deja ver decenas de miles de equipos potencialmente vulnerables. Un investigador independiente citado por The Hacker News habla de unos 40.000 servicios de Compartir pantalla abiertos en Internet, en su mayoría domésticos, y el resto repartido entre universidades y empresas.
El segundo foco no aparece en ningún inventario de servidores, y es el que más nos interesa desde una organización europea. Hablamos del Mac de dirección, del que usa el equipo de diseño, del portátil del desarrollador que un día activó Compartir pantalla para que le echaran una mano en remoto y nunca volvió a apagarlo. En una oficina detrás de NAT ese equipo no está expuesto a Internet, pero sí lo está para cualquiera que ya se encuentre en la red interna. Y esa distancia se acorta con muy poco: un reenvío de puertos en el router de una sede pequeña, una conexión desde casa, una red de invitados mal segmentada.
El sesgo es siempre el mismo: la superficie de ataque se inventaría en servidores y se olvida en los puestos de trabajo, y dentro de los puestos, los Mac suelen quedar en tierra de nadie entre el equipo de sistemas y el de seguridad. En los trabajos de gestión de la superficie de ataque nos topamos con ese patrón una y otra vez: servicios de administración remota escuchando en equipos que nadie clasificó como infraestructura.
El minero es la advertencia, no el daño
Lo que el NCSC-NL ha observado en todos los casos reportados es lo mismo: acceso de root y un minero de Monero instalado. Es cryptojacking clásico, el uso no autorizado de recursos ajenos para minar criptomoneda, y responde a la lógica de siempre: monetizar rápido y sin criterio todo lo que se pueda alcanzar por automatismo. Es la misma economía de la capacidad de cálculo robada que analizamos en el caso del robo de capacidad de inferencia de IA.
Interpretarlo como «solo era un minero» sería un error de lectura. El minero indica que el acceso de root funciona y está automatizado; quién lo aproveche después es una cuestión de oportunidad. Un equipo con acceso de root a disposición de terceros puede entregar contraseñas guardadas, credenciales de sesión (tokens) de las herramientas corporativas, claves SSH, documentos y correo. El NCSC-NL no ha detallado cuándo empezaron los ataques, cuántos sistemas hay afectados ni si la actividad va más allá del criptominado.
Hay además una señal que trasciende este caso concreto. La empresa Calif, que analizó ambos fallos, afirma que construyó código de explotación funcional para los dos en cuatro horas apoyándose en un agente de inteligencia artificial, y que retiene detalles adicionales hasta que la mayoría del parque esté actualizado. Si esa cifra se sostiene como norma, la ventana entre publicar un parche y enfrentarse a explotación en masa se estrecha para todos los fabricantes, y la planificación de parcheo mensual deja de encajar con el ritmo del atacante.
Detección: qué buscar en un Mac
La telemetría útil existe y viene del propio sistema. Endpoint Security es el marco de Apple para que las herramientas de seguridad observen eventos, y desde macOS 13 emite eventos específicos de conexión y desconexión de Compartir pantalla.
Huntress documenta dos señales aprovechables en esos eventos. La primera es el nombre de la sesión: una conexión establecida como root no tiene explicación legítima en la mayoría de parques, porque en macOS esa cuenta viene desactivada de serie y no es habitual habilitarla para escritorio remoto. La segunda es el tipo de autenticación: las conexiones legítimas por el camino nativo aparecen como RSA-SRP, mientras que las sesiones abiertas mediante este fallo se registran como SRP, sin la capa criptográfica. Distinguir una cosa de otra es una regla de correlación sencilla de escribir.
A partir de ahí, vigila la actividad del proceso auxiliar de copia de ficheros sobre rutas que no tienen nada que ver con una sesión de soporte, y las ejecuciones de ese mismo auxiliar con atributos anómalos. Un intento de adivinar cuentas deja además un rastro ruidoso: eventos de conexión con el nombre de sesión vacío.
En la capa de red el trabajo es más simple y más rentable: inventaría quién escucha en el puerto 5900 dentro del parque y comprueba desde fuera si alguno responde. Las conexiones salientes sostenidas hacia grupos de minería (pools) y un consumo de CPU que no cuadra con lo que la máquina debería estar haciendo completan el cuadro. Un SOC gestionado con cobertura real de macOS ve estas dos cosas; uno que solo ingiere telemetría de Windows, no.
Qué hacer esta semana
Actualizar es la medida principal y no admite demora: macOS Tahoe 26.6.1, Sequoia 15.7.9 o Sonoma 14.8.9. Son las únicas versiones que cierran el fallo previo a la autenticación.
Cuando la actualización no pueda aplicarse hoy, desactivar Compartir pantalla en Ajustes del Sistema, en General → Compartir, es una mitigación efectiva mientras tanto. Y como criterio permanente: si alguien necesita escritorio remoto sobre un Mac, que llegue por VPN o por un túnel SSH, nunca con el puerto 5900 asomado a Internet.
La revisión debe ir más allá de los equipos donde uno cree que el servicio está encendido. Huntress recomienda actualizar todo el parque macOS aunque se dé por hecho que Compartir pantalla está desactivado, sencillamente porque esa suposición falla más de lo que gusta admitir. En equipos alquilados a proveedores de Mac en la nube, verifica también con qué imagen se aprovisionan.
Si aparece un equipo comprometido, el criterio de respuesta a incidentes es el de cualquier compromiso con acceso de root: aislarlo, reinstalarlo desde cero y rotar las contraseñas, claves y sesiones que hayan pasado por él, incluidas las de servicios en la nube. Retirar el minero y cerrar el caso ahí no responde por lo que el atacante se haya llevado antes.
Para las organizaciones que quieran comprobar de forma ordenada qué servicios de administración remota tienen realmente expuestos, en Hard2bit abordamos esa revisión dentro de la gestión de vulnerabilidades: es ahí donde este tipo de hallazgo sale a la luz antes de que lo encuentre otro. Elegir una empresa de ciberseguridad que cubra macOS con el mismo detalle que Windows deja de ser un matiz cuando el fallo del mes está en el portátil de dirección.
El servicio que nadie inventarió
El sistema operativo que buena parte del sector considera el seguro por defecto acaba de regalar acceso de root sin credenciales, y lo ha hecho por una función que se activa con un interruptor y se olvida en el mismo gesto. Aquí no hay una comparación entre macOS y Windows: hay un problema de inventario.
La pregunta que queda no es si hay que parchear, sino cuántos servicios de administración remota siguen encendidos ahora mismo en equipos que nadie cuenta como infraestructura. En los inventarios que revisamos, esa cifra casi nunca existe.
Este artículo tiene carácter divulgativo y defensivo. Las pautas de detección y endurecimiento descritas deben adaptarse y probarse en cada entorno antes de aplicarse en producción. La información sobre la explotación procede de las divulgaciones públicas disponibles en la fecha de publicación (agosto de 2026) y puede evolucionar.
