La última actualización de macOS corrige una vulnerabilidad de Screen Sharing que permite la ejecución remota de código sin autenticación previa

Agradecimientos: Un agradecimiento especial a Bryan Masters y Stuart Ashenbrenner por sus aportes a esta investigación y a este artículo-informe.

TL;DR:

Si usas Screen Sharing en macOS y lo expones a internet, tenemos que hablar. Aunque en general no se recomienda exponer protocolos de acceso remoto al mundo, entendemos que algunos casos de uso pueden requerirlo. ¡Tú sabrás!

Con el auge de los dispositivos Apple bare-metal alojados, como las Mac mini disponibles para cargas de trabajo bajo demanda, SSH y Screen Sharing suelen estar habilitados de forma predeterminada en cualquier servicio recién aprovisionado.

Las actualizaciones de seguridad de Apple anunciadas la última semana de julio vinieron seguidas de una oleada de actividad, divulgaciones públicas de bugs recién parcheados y comentarios sobre la magnitud de los CVE publicados. Entre ellos hay referencias a bugs relacionados con el servidor de Screen Sharing. Una semana después, Apple  lanzó un parche para eliminar por completo un bug de consecuencias importantes.

Contexto

Apple, con su habitual sencillez, describe Screen Sharing en macOS como un servicio que "permite a los usuarios de otras computadoras de tu red conectarse de forma remota a tu Mac para ver tu escritorio y controlar tu Mac".

Screen Sharing en macOS usa el protocolo RFB (Remote Framebuffer), que es el protocolo principal en el que se basan VNC y sus derivados.

Se permiten dos rutas de autenticación distintas:

• Autenticación nativa de Apple: El tipo habitual de autenticación con nombre de usuario y contraseña, asociado a la cuenta de un usuario en este sistema

• Autenticación VNC heredada: Una única contraseña que no está asociada a ningún usuario específico de macOS, pero que permite interactuar con el usuario que tiene la sesión iniciada

Si eres un usuario visual, aquí tienes el panel de configuración de Screen Sharing en macOS Tahoe:

Figura 1: Configuración de Screen Sharing en macOS Tahoe

El daemon del sistema de Screen Sharing se apoya en dos procesos auxiliares con privilegios que gestionan las operaciones con archivos: SSFileCopySender y SSFileCopyReceiver. Con la ruta de autenticación nativa de Apple username:password, se ejecutan en el contexto del usuario; sin embargo, con VNC heredado, operan con privilegios de root.

El 29 de julio,  bynar.io divulgó su investigación sobre una de las vulnerabilidades parcheadas, CVE-2026-43760, que aprovechaba una condición de contexto confuso; su informe dependía, en última instancia, de una sesión autenticada para que se dieran las condiciones del exploit.

Esto permitía que cualquier usuario autenticado mediante el método VNC heredado leyera y creara cualquier artefacto del sistema de archivos como root.

Dada la naturaleza del servicio y la complejidad añadida de admitir dos métodos de autenticación, parece que muchos investigadores estaban dedicando tiempo (y tokens) a este vector.

Al corregir vulnerabilidades del servicio la semana pasada, Apple, de forma intencional o no, parece haber corregido parcialmente una vulnerabilidad previa a la autenticación en screensharingd.

Acceso root sin necesidad de autenticarse 

Tras la actualización de seguridad de Apple de julio y la investigación publicada por bynar.io, Pedro Vilaça (alias fG!) publicó una entrada de blog en la que confirmaba que Apple había parcheado un bug previo a la autenticación en el mecanismo de autenticación del daemon. La publicación venía acompañada de un binario ofuscado de prueba de concepto que permitía a cualquiera que tuviera la dirección IP de un endpoint macOS con Screen Sharing habilitado y con ≤ macOS 26.5.2 (o ≤ macOS 15.7.7, ≤ macOS 14.8.7) explotar el bug en sistemas sin parchear para revelar cualquier artefacto del sistema de archivos.

Cuando decimos "cualquier artefacto", lo decimos en serio. Como esta prueba de concepto (PoC) aprovechaba las operaciones con archivos que admite el proceso auxiliar SSFileCopySender, heredaba el codiciado entitlement privado firmado por Apple kTCCServiceSystemPolicyAllFiles, que otorga acceso total al disco y evita por completo las protecciones de TCC.

User@MacBook-Pro ~ % codesign -d --entitlements - /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender

Executable=/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender

La PoC, registrada como CVE-2026-65400, explotó con éxito un servicio de Screen Sharing con la autenticación VNC heredada deshabilitada y sin cuentas de usuario locales de Apple habilitadas para el acceso.

Screen Sharing usa Secure Remote Password (SRP) en su ruta de autenticación nativa de Apple, que, como mencionamos antes, autentica contra una cuenta de usuario real de macOS. El daemon del sistema screensharingd parece tener errores en su implementación de SRP: el validador de longitud de trama del daemon devuelve por error un estado de éxito obsoleto, por lo que la conexión se trata como autenticada. Además, la conexión continúa sin protección criptográfica, lo que da lugar a una sesión en texto plano.

En última instancia, esto permite a un atacante leer y escribir archivos arbitrarios como root. El análisis de la entrada de blog original de fG! dio lugar a una nueva PoC que distingue las funciones de lectura y escritura y las combina para lograr ejecución remota de código: un script de reverse shell con privilegios más un cron job que se conecta a un listener controlado por el atacante.

Huntress revisó esta PoC en el momento de su divulgación y determinó que el vector implementado no funcionaba, porque dependía de poder crear un nuevo cron job en /var/at/tabs/root, una ubicación protegida por TCC. Aunque SSFileCopySender tiene permisos de acceso total al disco al iniciar sesión, SSFileCopyReceiver no tiene esos entitlements, probablemente por las evidentes implicaciones de evasión de TCC que tendría otorgarle esa capacidad.
El informe de bl4sty se actualizó después para aclarar que el método anterior solo funciona en un sistema con System Integrity Protection (SIP) deshabilitado.

La ejecución remota de código se logra mediante varios mecanismos, lo que abre distintas posibilidades de éxito:

• Creación de un LaunchDaemon que activa la ejecución de un reverse shell guardado en disco al reiniciar

• Modificación de la persistencia en un archivo de inicio del shell (p. ej., .zshenv), que se activa al abrir Terminal.app

Las propiedades individuales de Screen Sharing, como eliminar las cuentas de usuario permitidas o la autenticación por contraseña VNC, no afectan el éxito de este bug. Hay que admirar la simplicidad de esta vulnerabilidad.

¿Cómo sé si mi Mac está expuesta?

Aunque el servicio Screen Sharing no está habilitado de forma predeterminada (¡por suerte!), hay casos que generan preocupación. A medida que Apple silicon gana popularidad, varios proveedores ofrecen servicios de Mac bare-metal alojados, que suelen aprovisionarse con estos servicios habilitados. Conociendo los ASN y los puertos no estándar que usan estos proveedores, una búsqueda rápida en Censys revela decenas de miles de endpoints potencialmente vulnerables.

Para empeorar el problema, al momento de escribir esto, algunos de estos proveedores todavía no han incorporado las últimas actualizaciones de Apple en su imagen base de aprovisionamiento y exponen con regularidad a internet endpoints recién aprovisionados con las versiones vulnerables (n-1). Además, el IPSW más reciente (la imagen de restauración de Apple) para macOS Sequoia y Sonoma se queda en 15.6.1 y 14.6.1, respectivamente. Esto significa que cualquier dispositivo creado con versiones de macOS más antiguas (pero compatibles) se aprovisionará vulnerable y seguirá así hasta que pueda actualizarse.

La conclusión es: actualiza todos tus dispositivos macOS sin excepción, aunque creas que Screen Sharing no está habilitado. Si no puedes aplicar el parche de inmediato, asegúrate de deshabilitar Screen Sharing. 

Oportunidades de detección

Endpoint Security (ES) es la API en C de Apple para monitorear eventos del sistema. Su uso principal es permitir que los proveedores de seguridad detecten actividad potencialmente maliciosa. Los proveedores de seguridad, incluida Huntress, usan esta fuente (entre otras) como flujo de telemetría para identificar actividad sospechosa y maliciosa.

ES_EVENT_TYPE_NOTIFY_SCREENSHARING

Apple introdujo los eventos de Screen Sharing _ATTACH y _DETACH en macOS 13.0.

Al suscribirnos a ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH mediante eslogger, la herramienta de Apple para suscribirse a eventos de ES especificados por el usuario, podemos observar lo siguiente en una explotación exitosa:

Cabe destacar que el nombre de usuario de la sesión, root, es un indicador sospechoso, ya que este usuario está deshabilitado de forma predeterminada en macOS y pocos administradores lo habilitarían y además lo usarían para Screen Sharing.

Al comparar la salida con una conexión legítima:

También observamos authentication_type: RSA-SRP, a diferencia de nuestro authentication_type: SRP malicioso (como señalamos antes, no se aplica criptografía a las sesiones establecidas mediante este bug).

Figura 2: ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH emitido por el framework de ES junto con una alerta codificada basada en authentication_type

EVENTOS DEL SISTEMA DE ARCHIVOS

Si recopilas eventos del sistema de archivos mediante ES, también observarás otros eventos ES_EVENT_TYPE_NOTIFY_ _LOOKUP, _OPEN, _GETEXTATTR, _FSGETPATH, _GETATTRLIST, _STAT, _CLOSE, etc., con la propiedad del ejecutable …SSFileCopySender y una ruta de destino que detalla el artefacto del sistema de archivos que se está manipulando o filtrando.

ES_EVENT_TYPE_NOTIFY_EXEC

Si no tienes acceso a eventos atómicos del sistema de archivos, puedes tener suerte observando los eventos de ejecución de procesos mediante ES con la siguiente línea de comandos:

/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender 0 80

/

Los intentos de explotación para revelar información generan una ejecución con los atributos <UID> <GID>, que serán 0 80 en los primeros casos. Sin embargo, estos valores no se mantienen fijos: si un actor de amenazas enumera otro usuario del sistema, puede evadir esta detección.

Deberías ver al menos un evento de root, ya que esta enumeración debe ocurrir primero en ese contexto. Si un actor de amenazas intenta adivinar una cuenta válida, los eventos de Screen Sharing incluirán el atributo session_username: null, lo que ofrece más oportunidades para detectar una enumeración ruidosa.

Remediación

Aplica el parche ya. Actualiza a macOS 26.6.1, 15.7.9 o 14.8.9 (publicadas el 6 de agosto de 2026). Son las únicas compilaciones que corrigen por completo el bug previo a la autenticación y cierran CVE-2026-65400.

Si no puedes aplicar el parche de inmediato, deshabilita Screen Sharing. 

Como se trata de un bug previo a la autenticación, el endurecimiento habitual no sirve: eliminar las cuentas de usuario permitidas, deshabilitar la autenticación por contraseña VNC heredada o rotar la contraseña VNC no tiene ningún efecto.

Cronología completa de la divulgación