Laboratorio demuestra ejecución de código en enclave SFAPE de Windows (CVE-2026-83498) y parche

Investigadores de la firma Doyensec han demostrado en laboratorio que es posible ejecutar código elegido por un atacante dentro de una porción de memoria de Windows que debería permanecer sellada incluso cuando el resto del sistema ha sido comprometido. El componente afectado es una librería VBS (Virtualization-Based Security) usada por la función Enhanced Phishing Protection de Microsoft Defender SmartScreen —concretamente la enclave SFAPE.dll— y Microsoft corrige la vulnerabilidad en el parche acumulativo publicado el 8 de septiembre de 2026 (KB5124008). El fallo figura como CVE-2026-83498, fue calificado por Microsoft como "elevación de privilegios" con severidad Crítica (CVSS 7.8) y, según la compañía, no había sido explotado en entornos reales ni era público antes del arreglo; Microsoft además detectó el mismo problema internamente.

Desde el punto de vista técnico, la arquitectura VBS aísla librerías firmadas —las enclaves— dentro de un mundo de mayor confianza gestionado por el hipervisor de Windows (VTL1 o Isolated User Mode). Un proceso del sistema en el mundo ordinario (VTL0), como LSASS.exe —que maneja credenciales y corre como SYSTEM—, puede cargar la enclave pero no leer ni modificar su memoria. El propósito es proteger secretos críticos (por ejemplo, hashes de contraseña para la protección anti‑phishing) aun cuando un atacante haya conseguido privilegios en el kernel o SYSTEM.

Lo que los investigadores consiguieron no fue una puerta de entrada remota, sino una escalada desde dentro: la explotación requiere que ya exista código local con acceso bajo nivel al equipo y la posibilidad de invocar la enclave cargada por LSASS. Doyensec documenta una cadena de fallos encadenados: una segunda llamada a la función Initialize provoca que la enclave escriba un valor de error fijo de cuatro bytes en una dirección controlada por el proceso llamante; esa segunda llamada omite una comprobación que sí hace la primera invocación. Por sí sola esa escritura es limitada, pero si afecta el dato que la enclave utiliza para distinguir su propia memoria de la del host, las comprobaciones de seguridad dejan de funcionar. A partir de ahí, un bug de sincronización (timing) en otra función permite forzar un borrado controlado que redirige una búsqueda interna, lo que deriva en lecturas y escrituras que permiten reemplazar la tabla de funciones que decide qué código puede ejecutar la enclave. El resultado final descrito por Doyensec es la ejecución de código elegido por el atacante dentro de la enclave.

Es importante separar hechos confirmados de extrapolaciones: está demostrado en laboratorio que la enclave vulnerable puede ser manipulada para ejecutar código arbitrario, y Microsoft y Doyensec coinciden en que la mitigación corrige estos vectores. No hay evidencia pública de explotación en entornos reales ni de robo comprobado de contraseñas a partir de este fallo; Microsoft define el impacto como posible filtración de datos o ejecución de código dentro de la enclave. La investigación de Doyensec tampoco afirma haber recuperado hashes de contraseñas de usuarios en equipos reales —eso permanece sin confirmar— pero el control de la enclave abre ese riesgo teórico si se combina con otras condiciones de ataque.

Microsoft publicó la corrección en su actualización acumulativa para Windows 11 (versiones 24H2 y 25H2) del 8 de septiembre de 2026 y, según Doyensec, el archivo parcheado añade la comprobación de dirección anterior al primer write y endurece la función afectada por la condición de carrera. Además, la actualización instala una política que impide cargar la versión antigua y vulnerable de SFAPE.dll, de forma que sistemas actualizados no ejecutan la enclave insegura. No existe un procedimiento alternativo separado: la acción recomendada para todos los usuarios es instalar la actualización correspondiente.

Queda, sin embargo, una brecha en la estrategia de mitigación general: Windows no dispone de una lista de bloqueo global para enclaves vulnerables, análoga a la que mantiene para drivers. La mitigación aplicada en septiembre bloquea únicamente la versión afectada de SFAPE.dll; Doyensec advierte que otras enclaves firmadas con fallos conocidos pueden seguir siendo cargadas —por ejemplo, una enclave de Microsoft Edge con CVE-2023-36880 que tenía una vulnerabilidad de lectura/escritura sigue siendo, según Doyensec, permitida—. Esa diferencia puede dejar abierta la táctica conocida como "bring your own vulnerable enclave", en la que un atacante carga deliberadamente una enclave firmada pero defectuosa para ocultar código o datos frente a herramientas de seguridad, una técnica debatida en trabajos previos de la industria.

¿A quién afecta esto? En términos prácticos, el riesgo mayor está para entornos donde un atacante puede ejecutar código con privilegios bajos a medios en la máquina objetivo —por ejemplo, a través de un exploit local, un servicio mal configurado o acceso físico— y donde LSASS u otro proceso privilegiado cargue la enclave vulnerable. Equipos aislados y sistemas sin cuentas locales expuestas tienen menos probabilidad de ser objetivos, pero en organizaciones con usuarios que alcanzan elevación local con relativa facilidad (por phishings posteriores, malas configuraciones RDP, o software que permita ejecución de código), el vector es relevante.

Recomendaciones concretas y verificables: primero y ante todo, instale la actualización KB5124008 o aplique las políticas de Windows Update que su organización utilice; esa es la única medida ofrecida por Microsoft para mitigar este defecto. Verifique el estado de actualización en servidores y endpoints que ejecuten Windows 11 24H2/25H2 y priorice máquinas con cuentas administrativas o con servicios que carguen enclaves. Para entornos empresariales, integre el parche en su ciclo de gestión de parches y confirme la presencia de la política que bloquea la versión antigua de SFAPE.dll.

Más medidas defensivas que reducen la probabilidad y el impacto de este tipo de ataques incluyen limitar el acceso local privilegiado, deshabilitar servicios innecesarios que permitan ejecución de código, aplicar el principio de menor privilegio, y desplegar soluciones EDR que monitoricen cargas y llamadas a procesos sensibles como LSASS. Activar y mantener mitigaciones de Virtualization‑Based Security (Credential Guard, HVCI) actualizadas y usar controles de aplicación (application allowlisting) ayudan a reducir la superficie de ataque. Para equipos críticos, audite las enclaves cargadas y contraste firmas y versiones con las fuentes oficiales después del parche.

Finalmente, conviene seguir dos frentes: por un lado, confirmar la instalación del parche en todos los endpoints y servidores; por otro, presionar a los fabricantes para que implementen un mecanismo de bloqueo centralizado para enclaves firmadas defectuosas, como existe para drivers, de modo que técnicas de "bring your own vulnerable enclave" no sigan disponibles. Para documentación técnica sobre VBS y el aislamiento que proporcionan las enclaves, Microsoft mantiene material en su portal de documentación: https://learn.microsoft.com/en-us/windows/security/virtualization-based-security/. La investigación de Doyensec está publicada por la firma y puede consultarse en su sitio como referencia sobre la metodología y el análisis: https://doyensec.com/.

En síntesis: el hallazgo demuestra que, incluso en capas diseñadas para confinar secretos frente a un kernel comprometido, errores lógicos y de sincronización pueden permitir al atacante escalar su presencia y ocultar código dentro de ese nivel confiable. La mitigación existe y debe aplicarse urgentemente; la discusión abierta es cómo prevenir que otras enclaves firmadas y vulnerables queden disponibles para explotaciones similares en el futuro.