NAP Latino

Publicado el 18 de agosto de 2026 · Revisado el 18 de agosto de 2026

Microsoft corrigió 394 fallas en un solo Patch Tuesday — incluida una que ya estaban explotando activamente

El 11 de agosto, Microsoft publicó su actualización mensual de seguridad corrigiendo 394 vulnerabilidades de un solo golpe, entre ellas tres fallas de día cero —una ya explotada activamente— y varios errores críticos en SharePoint Server, Azure y PowerShell Core. Con un volumen así, la pregunta relevante para cualquier administrador ya no es "¿aplico el parche?", es "¿por dónde empiezo primero?".

El 11 de agosto, Microsoft publicó su Patch Tuesday mensual, el paquete acumulado de correcciones de seguridad que la empresa libera de forma programada cada segundo martes del mes. Esta vez el volumen fue inusualmente alto: 394 vulnerabilidades corregidas en un solo lanzamiento, repartidas en 150 fallos de escalada de privilegios y 132 de ejecución remota de código, más otras categorías menores. Entre ese total había tres vulnerabilidades de día cero —fallas que ya eran conocidas o explotables antes de que existiera un parche—, y una de ellas, catalogada como CVE-2026-68820, ya estaba siendo explotada activamente en el momento de la divulgación.

Esa falla activa vive en WinSock, el componente que gestiona las comunicaciones de red de Windows a bajo nivel. Permite que un atacante que ya logró un punto de entrada inicial en un sistema —por ejemplo, mediante un correo de phishing exitoso o una cuenta comprometida— escale sus privilegios hasta tomar control completo del dispositivo. No es la puerta de entrada en sí, es el paso siguiente: el que convierte un acceso limitado en control total. Junto a ella, Microsoft divulgó públicamente otras dos fallas de día cero sin evidencia de explotación activa todavía —CVE-2026-62832, en el servicio de perfiles de usuario de Windows, y CVE-2026-72971, en el sistema de aislamiento de contenedores de Windows (unionfs.sys), relevante para cualquiera que corra cargas de trabajo en contenedores sobre infraestructura Windows.

Lo que hace este Patch Tuesday particularmente relevante para administradores de infraestructura, más allá del volumen total, son las fallas específicas en productos de servidor que forman parte del día a día empresarial: SharePoint Server tuvo múltiples fallos de escalada de privilegios y ejecución remota de código, incluyendo CVE-2026-70321. Azure recibió una corrección crítica de ejecución remota de código en sus servicios de certificación, registrada como CVE-2026-71331. Windows Server tuvo correcciones relacionadas con su servicio DNS y su instalador. Y PowerShell Core, la herramienta de scripting que corre en buena parte de la automatización de administración de sistemas Windows y Linux por igual, recibió una corrección de ejecución remota de código propia, CVE-2026-70337.

Ya hemos insistido varias veces en esta sección en que el parche disponible no sirve de nada si nadie lo aplica a tiempo —fue exactamente lo que convirtió una falla de cPanel ya corregida en una ola de ransomware que golpeó a 44.000 servidores hace unos meses—. Pero un volumen de 394 correcciones en un solo paquete plantea un problema distinto al que veníamos discutiendo: no es solo "aplica el parche", es que ningún equipo de infraestructura tiene la capacidad de revisar, probar y desplegar 394 cambios de forma individual en el mismo día, y tratar de hacerlo termina, en la práctica, retrasando todo el proceso.

La forma sensata de priorizar en un escenario así no es intentar aplicar las 394 correcciones con la misma urgencia, es ordenar por dos criterios simples: primero, cualquier falla con explotación activa confirmada —en este caso, CVE-2026-68820— va antes que todo lo demás, sin excepción y sin esperar la ventana de mantenimiento habitual. Segundo, prioriza los sistemas expuestos directamente a internet o a redes no confiables sobre los que solo son accesibles internamente —un servidor SharePoint público o un servicio de Azure con acceso externo pesan más en tu lista que una estación de trabajo interna, incluso si técnicamente la vulnerabilidad afecta a ambos por igual—. El resto de las correcciones, las que no tienen explotación activa conocida y no están en sistemas expuestos, pueden seguir el ciclo normal de pruebas y despliegue sin que eso signifique estar descuidando la seguridad — es, simplemente, reconocer que no toda vulnerabilidad corregida representa el mismo nivel de riesgo real hoy mismo, aunque todas terminen en la misma lista de un boletín de seguridad.