PUBLICADO EL 18 DE AGOSTO DE 2026
Microsoft corrigió un número récord de 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 un volumen inusualmente alto de 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, muy por encima del promedio habitual, con los fallos de escalada de privilegios y de ejecución remota de código como las categorías más numerosas, junto a otras de menor peso. 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 (wcifs.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 miles de servidores hace unos meses—. Pero un volumen tan alto de 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 cientos de 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 todas las 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.
