El 8 de septiembre de 2026 Microsoft publicó uno de los lotes de actualizaciones de seguridad más grandes de su historia, según coinciden varias firmas de ciberseguridad que dan seguimiento a sus boletines mensuales. Dentro de ese lote había dos vulnerabilidades que ya estaban siendo explotadas activamente antes de que existiera el parche para corregirlas: CVE-2026-85880 y CVE-2026-81963, ambas de elevación de privilegios en Windows. Ese dato — no el volumen total del lote — es el que debería importarte, y es el punto de partida para hablar de algo más de fondo: la gestión de parches de seguridad como proceso de empresa, no como reacción del momento.
El Patch Tuesday de septiembre de 2026, en una frase
Microsoft agrupa sus actualizaciones mensuales de seguridad en un lanzamiento conocido como Patch Tuesday. El de septiembre de 2026 corrigió, entre otras, dos fallos de elevación de privilegios en Windows — CVE-2026-85880 y CVE-2026-81963 — que ya estaban siendo aprovechados por atacantes antes de que Microsoft tuviera una corrección lista. Una elevación de privilegios no es la puerta de entrada: es lo que hace un atacante una vez que ya está dentro, para pasar de una cuenta corriente a control total del equipo. Por eso este tipo de fallo suele aparecer combinado con otro método de acceso inicial, no solo.
CISA, la agencia de ciberseguridad de Estados Unidos, añadió ese mismo 8 de septiembre las dos vulnerabilidades a su catálogo de vulnerabilidades explotadas conocidas (KEV), con plazo de mitigación al 22 de septiembre de 2026 para las agencias federales de Estados Unidos. Ese plazo es una obligación de ese gobierno, no una norma que aplique a tu empresa; lo que sí te aplica es el hecho que confirma: un organismo independiente verificó, con fecha exacta, que ambos fallos ya se estaban usando en ataques reales antes del parche.
Por qué el volumen no es lo importante
La cobertura de este Patch Tuesday se centró en cuántas vulnerabilidades corrigió Microsoft en total. Esa cifra cambia según quién la cuente y con qué método, y ninguna fuente coincide con un total oficial único — por eso no la vas a encontrar en este artículo. Lo que sí es consistente entre las fuentes es lo que importa: hubo explotación activa antes de que existiera el parche.
Eso implica una ventana de exposición real: días o semanas en los que el fallo ya se podía aprovechar y tu empresa no tenía forma de saberlo, antes de que hubiera nada que instalar. Aplicar el parche el día que sale no borra esa ventana hacia atrás. La pregunta que importa no es "¿ya lo instalé?", sino "¿sabía que estaba expuesto, y desde cuándo?". Esa respuesta no depende de cuántas vulnerabilidades traiga el lote: depende de si tu empresa tiene un proceso capaz de darla en cualquier momento, no solo el día del anuncio.
Contar vulnerabilidades es un ejercicio de prensa especializada, útil para comparar un mes con otro, pero no dice nada sobre el riesgo real de tu empresa. Una sola vulnerabilidad explotada activamente en un sistema expuesto a internet pesa más que cien teóricas en sistemas internos. El titular habla de volumen; el riesgo se mide en explotación y en exposición, no en cantidad.
Los tres puntos donde la gestión de parches se rompe en la pyme
En la mayoría de las pymes que hemos visto operar, la gestión de parches se rompe en uno de estos tres puntos.
Inventario
Si no sabes con certeza qué equipos operan en tu empresa ni qué versión de software corre cada uno, no puedes saber qué te afecta cuando sale un boletín como este. Sin inventario, cada parche obliga a averiguar desde cero quién quedó expuesto.
Priorización
No todas las vulnerabilidades pesan igual. Una que ya está siendo explotada activamente, como las dos de este lote, no es comparable a una teórica que nadie ha usado todavía. Tratarlas por igual reparte mal el tiempo de tu equipo de TI.
Verificación
Aplicar la actualización no es lo mismo que confirmar que quedó aplicada en cada equipo. Sin ese último paso, una empresa puede creer que está al día y tener buena parte de su flotilla sin el parche instalado.
Cómo priorizar sin volverse loco con cada boletín de seguridad
El criterio se reduce a dos preguntas por cada vulnerabilidad que aparece en un boletín: ¿está siendo explotada activamente? ¿el sistema afectado es accesible desde fuera de tu red o solo desde dentro? Un fallo explotado y expuesto a internet — un servidor de correo, un portal de clientes, una VPN — va primero; uno teórico en un sistema interno, sin salida directa a internet, puede esperar al ciclo normal de mantenimiento sin que eso sea negligencia.
Catálogos públicos como el de vulnerabilidades explotadas conocidas de CISA sirven como referencia externa objetiva para responder la primera pregunta, no como sustituto del criterio propio sobre qué sistemas tiene realmente tu empresa. Tratar cada boletín con la misma urgencia agota al equipo y, en la práctica, baja la guardia justo cuando más importa: cuando aparece el fallo que sí es crítico.
Centralizar el proceso en vez de fiarlo a la memoria de alguien
Un proceso centralizado de gestión de parches responde tres preguntas en cualquier momento, no solo el día que sale un boletín: qué está pendiente, qué es urgente y quién lo va a aplicar. Cuando esa respuesta vive en la cabeza de una sola persona — o en ninguna — cada actualización se convierte en una carrera contra el tiempo.
Automatizar la parte mecánica del proceso — detectar qué necesita actualizarse, alertar al responsable y dar seguimiento hasta que quede confirmado — libera a tu equipo para dedicar su criterio a lo que sí lo requiere: decidir qué se prioriza y cuándo. La parte mecánica no necesita juicio humano, necesita disciplina; y la disciplina es justo lo que falla cuando depende de que alguien se acuerde en medio de otras diez tareas del día.
Esto no elimina el riesgo ni lo reduce a cero — ningún proceso lo hace —, pero lo vuelve visible y gestionable, que es lo que una pyme necesita de verdad para decidir con información y no por costumbre.
Qué hacer la próxima vez que un proveedor publique un lote así
La próxima vez que Microsoft, o cualquier otro proveedor, publique un lote grande de actualizaciones, el orden importa:
- Confirma inventario antes de reaccionar: qué sistemas de tu operación están realmente expuestos a lo que se acaba de publicar.
- Prioriza por explotación activa, no por el orden en que llegó el boletín.
- Documenta qué se aplicó, dónde y cuándo, para poder responder esa pregunta en cualquier momento, no solo el día del anuncio.
Si en tu empresa las actualizaciones se aplican cuando alguien se acuerda, el problema no lo resuelve el próximo Patch Tuesday: lo resuelve tener el proceso montado antes de que llegue. Si necesitas que implementemos un proceso de gestión de parches centralizado y automatizado en tu empresa, agenda una consultoría con Grupo LDE.