CVE críticos mayo 2026: cómo priorizar parches en Chile

TL;DR. Mayo de 2026 ha sido un mes denso en vulnerabilidades activamente explotadas. CISA añadió a su catálogo Known Exploited Vulnerabilities varios CVE con CVSS 10.0 y plazos federales de remediación de pocos días: CVE-2026-20182 en Cisco Catalyst SD-WAN Controller (bypass total de autenticación, plazo 17 de mayo), CVE-2026-31431 en el kernel de Linux y CVE-2026-34926 en Trend Micro Apex One. A esto se suma la CVE-2026-22769 en Dell RecoverPoint explotada desde 2024 por un cluster chino. Para una empresa chilena bajo Ley 21.663 ANCI, parchar a tiempo dejó de ser higiene técnica y pasó a ser obligación regulatoria. Esta guía explica qué CVE priorizar, con qué marco decidir y cómo automatizar el triage.

¿Qué CVE críticos se sumaron a la CISA KEV en mayo de 2026?

Mayo 2026 dejó al menos cuatro CVE con explotación activa confirmada y CVSS muy alto. El más visible es CVE-2026-20182 en Cisco Catalyst SD-WAN Controller, con CVSS 10.0, añadido a la KEV el 14 de mayo con plazo federal del 17 de mayo (tres días). El 1 de mayo, CISA agregó CVE-2026-31431, una falla de “Incorrect Resource Transfer” en el kernel de Linux que permite escalada local a root, observada en intrusiones reales. El 21 de mayo se sumaron CVE-2025-34291 (Langflow Origin Validation Error) y CVE-2026-34926 (Trend Micro Apex One Directory Traversal). Como anclaje, sigue vigente y bajo explotación activa la CVE-2026-22769 de Dell RecoverPoint for VMs (CVSS 10.0), añadida en febrero con plazo de 3 días.

La señal es clara: en menos de 30 días, CISA marcó remediación urgente para cuatro tecnologías que están en el stack de buena parte de las empresas chilenas medianas y grandes (SD-WAN, Linux, Trend Micro endpoint, Dell EMC backup). El equipo de seguridad que sigue tratando los CVE como un backlog mensual está estructuralmente expuesto.

¿Qué hace al CVE-2026-20182 de Cisco SD-WAN tan crítico?

El CVE-2026-20182 es un bypass de autenticación en el servicio vdaemon que corre en Cisco Catalyst SD-WAN Controller (el antiguo vSmart) y SD-WAN Manager (el antiguo vManage). Un atacante remoto no autenticado puede comunicarse con el servicio vía DTLS en puerto UDP 12346, hacerse pasar por un peer legítimo del fabric SD-WAN e inyectar una clave SSH pública en el archivo authorized_keys del usuario vmanage-admin. Desde ese momento tiene acceso administrativo persistente. El CVSS 10.0 está justificado: acceso a la red, sin privilegios previos, sin interacción de usuario, e impacto máximo en confidencialidad, integridad y disponibilidad.

Cisco confirmó explotación activa el 14 de mayo de 2026 a través de su PSIRT. El threat actor identificado por Cisco Talos es UAT-8616, un grupo sofisticado que ataca infraestructura SD-WAN desde al menos 2023. CISA exigió remediación federal en 3 días. Las versiones afectadas son SD-WAN Manager 20.12 anteriores a 20.12.5.1, 20.13 anteriores a 20.13.1.1, y 20.15 anteriores al patch correspondiente. La acción técnica inmediata es actualizar y, si no es posible, restringir el acceso al puerto UDP 12346 solo a peers válidos del fabric. En el contexto chileno, la mayoría de los SD-WAN empresariales en Chile están con Cisco o Fortinet, así que el impacto local es relevante.

¿Qué riesgo trae el zero-day de Dell RecoverPoint en Chile?

El CVE-2026-22769 afecta a Dell RecoverPoint for Virtual Machines en todas las versiones anteriores a 6.0.3.1 HF1 (incluye 5.3 SP4, SP3, SP2 y anteriores). El problema es una credencial hardcoded para el usuario admin del Apache Tomcat Manager interno. Un atacante puede autenticarse en /manager/text/deploy, subir un web shell llamado SLAYSTYLE y ejecutar comandos como root en el appliance que orquesta la replicación. Es decir, el sistema que la empresa instaló para protegerse de desastres pasa a ser el vector de compromiso.

Mandiant/Google Cloud y Cisco Talos atribuyen la actividad al cluster UNC6201, un grupo china-nexus que explota la falla desde mediados de 2024. La carga útil principal es el backdoor BRICKSTORM y su evolución GRIMBOLT, escrito en C# y compilado con AOT nativo para evadir EDR. En Chile, las empresas más expuestas son las que estandarizaron stack Dell EMC para replicación entre sites: banca, retail grande, salud privada, gobierno. La acción urgente es actualizar a la versión 5.3 SP4 P1 o a la rama 6.x, rotar credenciales SSH y revisar logs Apache Tomcat buscando POSTs a /manager/text/deploy y archivos .war sospechosos. Es un caso donde la replicación de DR puede haber estado comprometida durante meses.

¿Cómo priorizar qué CVE parchar primero?

La realidad es que un equipo TI mediano en Chile recibe del orden de 200-400 CVE nuevos al mes que aplican a su stack. Parchar todos con la misma urgencia es imposible y parchar al azar es peligroso. El marco que funciona combina cuatro variables.

CVSS (NIST) como piso, no como techo. El CVSS v3.1 estima la severidad técnica máxima. Pero un CVE con CVSS 9.8 en software que no está expuesto a internet y casi nadie explota tiene menos urgencia operativa que uno con CVSS 7.5 ya en CISA KEV.

EPSS como predictor real de explotación. El Exploit Prediction Scoring System de FIRST publica diariamente un score de 0 a 1 que estima la probabilidad de que un CVE sea explotado en los próximos 30 días. EPSS >0.5 combinado con CVSS >9 es señal fuerte de prioridad. La gran mayoría de los CVE tienen EPSS bajo 0.05.

CISA KEV como filtro de “ya está pasando”. Si un CVE entró a la KEV de CISA, por definición hay explotación activa observada. Para una empresa chilena no es obligación legal directa, pero es el mejor indicador externo de urgencia. El plazo federal de CISA es una buena referencia para fijar SLA interno.

Exposición + criticidad del activo. Un mismo CVE en un servidor externo con datos personales bajo Ley 21.719 tiene 10× más urgencia que en una VM interna de pruebas. La matriz mínima es: ¿es internet-facing? ¿soporta proceso crítico de negocio? ¿guarda datos regulados?

¿Qué exige Ley 21.663 ANCI sobre patch management?

La Ley Marco de Ciberseguridad 21.663 y las Instrucciones Generales ANCI que entraron en vigor en febrero 2026 obligan a los Operadores de Importancia Vital (OIV) y a la Administración del Estado a tener un programa formal de gestión de vulnerabilidades. La IG N°4 (Plan de Continuidad Operacional) y la IG N°1 (Estándares Mínimos de Seguridad) exigen identificación, evaluación, priorización y remediación documentada, con plazos definidos y auditables.

En la práctica esto significa tres cosas. Primero, no basta con tener un antivirus o un EDR: debe haber un proceso documentado de scanning regular (típicamente semanal), inventario actualizado de activos críticos y matriz de priorización. Segundo, los plazos de remediación deben estar formalizados en el plan de continuidad operacional y ser consistentes con la criticidad del activo (CISA KEV en activos críticos = 72 h máximo es un benchmark defendible). Tercero, si una vulnerabilidad conocida no parchada deriva en un incidente, eso configura incumplimiento del deber de diligencia: la obligación de notificar a ANCI en 3 horas para alerta temprana y 72 horas para reporte completo se gatilla, y la responsabilidad civil/administrativa queda expuesta. Las primeras fiscalizaciones de ANCI ya reportan que el “no tener un proceso documentado de patch management” es uno de los hallazgos más comunes en OIV chilenos.

¿Cómo automatizar el triage de CVE en una empresa chilena?

Hacer el triage a mano de 300 CVE mensuales es inviable. El stack típico que funciona para una empresa chilena de 200-2.000 empleados combina cuatro piezas. Inventario de activos con un CMDB o un EDR que entregue software bill of materials (Tanium, CrowdStrike Falcon, Microsoft Defender for Endpoint con ARC). Scanner de vulnerabilidades que cruza inventario con NVD: Tenable Nessus / Tenable.io, Qualys VMDR, Rapid7 InsightVM. Feed enriquecido con CISA KEV y EPSS automático (la mayoría de scanners modernos ya integran ambos como atributos del CVE). Sistema de tickets que crea automáticamente cards en Jira/ServiceNow con SLA derivado de la matriz, asigna al owner del sistema y monitorea cierre.

Para empresas más chicas (hasta 200 empleados) el stack mínimo es Microsoft Defender for Endpoint + Microsoft Defender Vulnerability Management (incluido en licencias E5) o una solución cloud-native tipo SecPod SanerNow. El proceso interno mínimo es: revisión semanal del top 20 prioritario, sync mensual con tecnología para parches no críticos, y “war room” cuando entra un CVE en KEV con CVSS ≥9 que toque activos productivos. El equivalente a una hora a la semana de un analista de seguridad cubre el grueso si el tooling está bien.

¿Qué hacer en las próximas 72 horas?

Si la empresa tiene SD-WAN Cisco, hardware Dell EMC con RecoverPoint, endpoints Trend Micro Apex One, o cualquier servidor Linux expuesto a internet, la acción inmediata es estas cinco cosas. Uno, validar inventario contra cada CVE de la KEV de las últimas 4 semanas. Dos, ejecutar el patch test en ambiente de staging para los CVE críticos. Tres, planificar ventana de mantenimiento corta esta semana para SD-WAN Manager y RecoverPoint VM. Cuatro, revisar logs de cada appliance impactado en busca de IoCs publicados por Cisco Talos, Mandiant y SOC Prime. Cinco, documentar la decisión y el SLA: si por razones técnicas no se puede parchar dentro del plazo, dejar registrada la mitigación compensatoria (segmentación, ACL, EDR rule, monitoreo reforzado) y el plan de cierre del gap.

Para el resto del año la inversión que paga es construir el pipeline automático: cada nuevo CVE en KEV que toque su stack genera automáticamente un ticket con SLA. Eso convierte la gestión de vulnerabilidades de una pelea reactiva mensual en una operación de fondo. En Elite Center diseñamos e implementamos programas de vulnerability management alineados con Ley 21.663 ANCI y los estándares NIST/CIS, integrados a la operación de ciberseguridad. Si quieres evaluar el estado actual y definir una matriz que funcione para tu empresa, conversemos.