Cisco actualiza Meraki OS para corregir siete vulnerabilidades de seguridad

Cisco actualizó el 15 de octubre su aviso de seguridad para Meraki OS y otras familias de campus gateway. Cisco presentó el lote como un hardening release y el boletín reúne siete CVE detectadas durante pruebas internas, con fallos de control de acceso, memoria, validación de entradas y gestión de recursos. La puntuación máxima es 9,6 para CVE-2026-76464; las otras seis vulnerabilidades no tienen esa misma severidad, así que el número no debe copiarse como si describiera el conjunto completo.

Qué equipos entran y qué dice Cisco sobre la explotación

El aviso incluye Campus Gateways, pasarelas celulares MG, puntos de acceso MR, switches MS, cámaras MV y appliances MX de seguridad y SD-WAN. Cisco indica que los productos de esas familias recogidos en la tabla están afectados con independencia de la configuración del dispositivo. La empresa no conoce anuncios públicos ni uso malicioso de estos fallos, y señala que no hay workarounds que los corrijan.

El boletín agrupa los fallos por clase de debilidad y usa un CVE por grupo. Por eso, CVE-2026-76464 resume la clase de restricciones de memoria y carga la puntuación CVSS máxima de 9,6; las demás entradas tienen máximos entre 7,4 y 8,8. La cifra alta merece priorización, pero no significa que cada modelo tenga idéntico vector ni que todos los fallos sean críticos. Secure ISS también destaca que el alcance y la primera versión corregida dependen de la familia y de su rama.

-InfraCrew dice: En Meraki, “actualizar el firmware” no es una instrucción completa hasta que se sabe qué familia y rama hay en cada sede.-

La versión fija depende del modelo

La tabla de Cisco publica una versión inicial corregida para cada rama afectada. Entre las referencias de mayor utilidad para inventario están:

Una versión de una familia no sirve como atajo para otra: por ejemplo, 19.2.9 no es una recomendación genérica para todos los MX, y algunos builds de Campus Gateway todavía aparecen como disponibilidad futura. Antes de programar el cambio, compara el inventario con la tabla completa del advisory y confirma en Dashboard qué actualización está ofrecida para el modelo concreto.

-InfraCrew dice: Un número de versión no adivina la rama que quedó desplegada en la sede; eso lo tiene que saber el inventario.-

La operación necesita dos comprobaciones, no solo el botón de actualización. Identifica los equipos y ramas realmente activos; después valida memoria, compatibilidad de la configuración y ventana de mantenimiento, tal como recomienda Cisco para las actualizaciones. Si la versión fija aún no aparece, documenta el activo pendiente y consulta el calendario del fabricante: no hay una mitigación equivalente que permita cerrar el riesgo mientras se espera.

-InfraCrew dice: Una lista de modelos con una sola versión “segura” suele describir mejor una hoja de cálculo que una red real.-

No hay en el aviso una explotación activa conocida, pero ese estado puede cambiar y no sustituye la actualización. Al tratarse de equipos de acceso, inalámbricos, switching, vídeo y SD-WAN, una rama sin corregir puede afectar funciones distintas según su ubicación. El orden razonable es empezar por los dispositivos expuestos o centrales para la conectividad, sin omitir el resto de las familias presentes en el inventario; la prioridad final dependerá de la topología y de los modelos instalados.

Diccionario de la Crew

CVE — identificador público asignado a una vulnerabilidad divulgada.

CVSS — escala estandarizada que puntúa la severidad técnica de una vulnerabilidad; no expresa por sí sola la exposición de una red concreta.

Hardening release — versión de software que agrupa correcciones surgidas de una revisión de seguridad y endurece el producto.