Windows corrige un fallo ya explotado: probar el parche sigue siendo clave

El aviso de seguridad de Microsoft confirma que las correcciones para CVE-2026-96951, un fallo de Windows Shell ya explotado, se publicaron el 13 de octubre de 2026. Para los administradores, la prioridad es identificar los equipos Windows pendientes de actualizar y asociar cada versión con su paquete. La explotación estaba confirmada antes de que se publicaran las correcciones.

La cobertura de BleepingComputer identifica Mark of the Web como la función de seguridad que permite eludir el fallo. Esa marca de procedencia ayuda a Windows a decidir cuándo mostrar advertencias al abrir archivos obtenidos de Internet. La información pública no describe cómo se desarrollaron los ataques observados ni cuántos equipos resultaron afectados.

Por qué este fallo tiene prioridad

CVE-2026-96951 permite omitir una función de seguridad de Windows Shell. Si un archivo pierde la señal de que procede de Internet, puede no recibir una advertencia que habría influido en la decisión de abrirlo. Esa consecuencia explica la urgencia de corregir el fallo, aunque la omisión de una advertencia no demuestra por sí sola que cada intento de explotación haya terminado en una infección.

La explotación ya observada ofrece un criterio más útil para ordenar el trabajo que el total de vulnerabilidades corregidas en octubre. El ciclo mensual también incluye actualizaciones para Office, SharePoint Server, SQL Server, Exchange Server y Azure, entre otros productos. Esa lista describe el alcance del ciclo completo; no convierte a todos esos productos en afectados por este CVE concreto. En este caso, la comprobación empieza por Windows Shell y por las versiones de Windows presentes en el inventario.

Qué actualización corresponde a cada versión

En Windows 11, la versión instalada determina el paquete de octubre: 26H1 corresponde a KB5127646; 24H2, 25H2 y 26H2 comparten KB5127648; 23H2 tiene KB5126653. Las actualizaciones llegaron en el mismo ciclo, pero sus identificadores no son intercambiables. Aprobar un paquete en una consola de gestión tampoco acredita que los equipos de las otras ramas hayan quedado corregidos.

La relación publicada para Windows Server distingue igualmente las ediciones: Server 2025 usa KB5126646, Server 2022 usa KB5126655, Server 2019 usa KB5126651 y Server 2016 usa KB5126868. La comprobación debe separar estaciones de trabajo y servidores, además de registrar la versión y el estado de instalación de cada equipo. Así se puede localizar una rama pendiente sin esconderla dentro de una cifra general de despliegue.

En un equipo individual, la información de versión y compilación permite verificar qué rama está instalada; en una flota, esos datos deben poder cruzarse con el paquete aprobado y los reinicios pendientes. La prioridad recae en los sistemas que siguen expuestos al fallo explotado, mientras que las pruebas deben hacerse sobre el paquete correspondiente a cada rama. Para otras versiones, los problemas conocidos deben consultarse en la ficha de su propia actualización.

Qué exige probar KB5127646 en Windows 11 26H1

La ficha de Microsoft para KB5127646 identifica la actualización acumulativa de Windows 11 26H1, fechada el 13 de octubre de 2026, y la compilación resultante 28000.3231. También documenta dos problemas conocidos que siguen siendo relevantes para las pruebas: conexiones de Escritorio remoto de usuarios sin privilegios administrativos y determinados dispositivos USB Audio Class 1.0. Son condiciones concretas de funcionamiento, no una razón para tratar el paquete como inservible en todos los equipos.

El problema de Escritorio remoto puede impedir la conexión de usuarios no administradores a equipos remotos que tengan activada la protección de administrador. El intento puede devolver el error 0xC000000D y afecta principalmente a hosts empresariales gestionados con esa protección. La ficha plantea desactivarla temporalmente mediante la gestión de directivas en los equipos afectados mientras se prepara una solución. Como esa medida reduce una protección, exige una decisión acotada al entorno donde se reproduzca el error.

El problema de audio comenzó con la actualización de seguridad de septiembre y continúa documentado en la de octubre. Algunos dispositivos USB Audio Class 1.0 pueden no iniciarse, quedarse sin sonido, mostrar el código 10 en el Administrador de dispositivos o presentar controles de volumen que no responden. Una actualización extraordinaria resolvió los síntomas ligados al audio multicanal, pero permanecen pendientes otros síntomas. La prueba pertinente consiste en usar los periféricos de esa clase que realmente dependen de los equipos afectados.

Cómo avanzar con el despliegue

La prueba previa tiene dos resultados distintos: confirmar que el paquete de la versión instalada se aplica correctamente y comprobar los servicios que podrían verse afectados por sus problemas conocidos. En 26H1, la compilación resultante sirve para verificar la instalación; las conexiones de Escritorio remoto y los dispositivos USB Audio Class 1.0 requieren pruebas funcionales cuando forman parte del entorno. Un resultado satisfactorio en una rama no sustituye las pruebas de otra actualización acumulativa.

Tras esa validación, el despliegue puede ampliarse siguiendo las instalaciones fallidas, los reinicios pendientes y las incidencias reproducibles. Los equipos que presenten un problema conocido necesitan una decisión específica, pero deben seguir visibles en el inventario de sistemas pendientes de corregir. Mientras continúa el trabajo sobre los problemas de Escritorio remoto y audio, esa separación permite avanzar con las correcciones y reconocer dónde una prueba funcional aún condiciona su despliegue.

Lee también:

• GitLab corrige un fallo 10.0 ya explotado: revisa secretos además de actualizar
• Microsoft corrige dos zero-days explotados en su mayor Patch Tuesday
• Cisco ISE sufre un fallo 10.0 explotado: actualizar es la única mitigación