Un CVE ya no es un fallo: Cisco ha cambiado la unidad de medida

El jueves miramos los avisos que Cisco publicó el miércoles y hubo un momento raro. Tres CVE con un 10.0 en un solo aviso, dos más con 10.0 en otro, y en ninguno de los dos una lista de fallos que se pudiera leer uno por uno. No es un descuido de redacción: Cisco lo explica, y lo explica bien. Desde julio, un identificador CVE suyo no señala un fallo, señala una clase de fallos. La noticia no es que haya cinco dieces. Es que el número que llevas años contando ha cambiado de tamaño.

Qué dice el aviso cuando dice «un CVE»

La frase está en los cuatro avisos, prácticamente con la misma redacción: «Cisco has grouped these issues by their underlying vulnerability class - Common Weakness Enumeration (CWE) - and assigned a single Common Vulnerabilities and Exposures Identifier (CVE ID) to each CWE grouping» (Cisco ha agrupado estos problemas por su clase de vulnerabilidad subyacente —CWE— y ha asignado un único identificador CVE a cada agrupación de CWE). Y en la página donde Cisco describe el modelo nuevo hay una línea que cierra el asunto: las vulnerabilidades que comparten debilidad se consolidan en CVE «paraguas» y se les asigna la puntuación CVSS «based on the highest severity within that category» (según la severidad más alta dentro de esa categoría).

Léelo despacio, porque tiene dos consecuencias y ninguna es obvia. La primera: detrás de un identificador puede haber dos fallos o quince, y el aviso no lo dice. La segunda, más incómoda: el 10.0 es la nota del peor elemento del grupo, no la de todos. Si dentro de esa bolsa hay un fallo remoto sin autenticación y otros cuatro que exigen estar dentro, los cinco se presentan bajo un titular de 10.0. La puntuación no está inflada —el peor caso es real y por eso manda—, pero deja de describir el conjunto. Es un techo, no un promedio, y hasta ahora la costumbre era leerla como si describiera una cosa concreta.

Los cuatro avisos que hemos leído, con sus números

Estos son los cuatro que hemos abierto y leído enteros. No decimos que sean todos: Cisco publicó bastantes más avisos esos dos miércoles —los previos del 5 y del 19 enumeran, entre otros, Catalyst SD-WAN Manager, IOS, BroadWorks, RoomOS o los conmutadores IE1000— y no los hemos revisado uno por uno. Estos cuatro sí llevan la fórmula del CVE agrupado.

• 5 de agosto — Catalyst SD-WAN. Cinco identificadores: tres en 9.9 (CVE-2026-20303, 20304 y 20310), uno en 8.8 y otro en 7.7. Afecta a los cuatro modos de despliegue, incluido el gestionado en nube. Primeras versiones corregidas: 20.9.10, 20.12.8.1, 20.15.6, 20.18.4 y 26.1.2.
• 5 de agosto — IOS XE. Siete identificadores, el más alto un 9.8 (CVE-2026-20272) y un 9.0 detrás. Ramas afectadas: 17.9, 17.12, 17.15, 17.18 y 26.1, en modo autónomo o de controlador. Corregidas en 17.9.10, 17.12.8, 17.15.6, 17.18.4 (o 17.18.4a) y 26.1.2.
• 19 de agosto — Crosswork. Cuatro identificadores y tres de ellos en 10.0 (CVE-2026-20030, 20357 y 20358), más un 9.9. Afecta a Data Gateway, Network Controller y Planning. La corrección es 7.2.1-SP.
• 19 de agosto — Secure Workload. Cinco identificadores, dos en 10.0 (CVE-2026-20315 y 20317), uno en 9.9, otro en 9.6 y otro en 7.5. Afecta al servicio en nube y a la instalación propia. Se corrige en 3.10.9.1 y 4.0.4.16, y el aviso avisa de algo que se pasa por alto: hay que actualizar el clúster, y los agentes, y los conectores.

Suman veintiún identificadores CVE y cinco dieces —ese recuento es nuestro, hecho sumando los cuatro avisos—, y ninguno de esos veintiuno equivale a un fallo. Hay dos frases más que se repiten literalmente en los cuatro. Una es tranquilizadora: «The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities that are described in this advisory» (el PSIRT de Cisco no tiene constancia de anuncios públicos ni de uso malicioso). Los encontró Cisco, en su casa, antes que nadie. La otra frase no es tranquilizadora en absoluto: «There are no workarounds that address these vulnerabilities» (no hay soluciones alternativas que aborden estas vulnerabilidades).

El motivo, contado en su versión fuerte

Antes de discrepar de nada conviene contar el argumento de Cisco como lo contaría Cisco, porque es sólido. Está firmado el 2 de junio por Russ Smoak, vicepresidente de seguridad de la información, aseguramiento de la seguridad y respuesta, y arranca así: «The fundamental scale of vulnerability discovery has shifted. Frontier AI models and agentic analysis harnesses are now surfacing bugs across large code bases at a rate that the traditional, ad-hoc disclosure-and-patch model was never designed to absorb […]» (la escala de descubrimiento de vulnerabilidades ha cambiado; los modelos de IA de frontera y los entornos de análisis agéntico están sacando fallos en bases de código grandes a un ritmo que el modelo tradicional de divulgación y parche nunca se diseñó para absorber).

De ahí sale todo lo demás. Si una campaña de análisis automatizado saca doscientos hallazgos de la misma clase en el mismo módulo, emitir doscientos avisos con doscientas fichas y doscientas mitigaciones puntuales no ayuda a nadie: entierra la señal debajo del papeleo. Cisco lo dice sin rodeos —evaluar el riesgo de seguridad CVE a CVE y aplicar mitigaciones puntuales «is no longer fit for purpose» (ya no sirve para el propósito con el que se creó)— y concluye que las versiones endurecidas no llevarán CVE individuales por fallo porque las correcciones son transversales y lo que toca es cualificar la versión y desplegarla, no negociar con cada hallazgo. Visto desde el lado del fabricante, es difícil defender lo contrario.

Lo que se rompe no es el parche: es el recuento

Aquí es donde el cambio deja de ser un asunto de Cisco y pasa a ser tuyo. Media industria de la gestión de vulnerabilidades cuenta CVE. Los cuadros de mando cuentan CVE abiertos, los informes al comité cuentan CVE críticos pendientes, los cuestionarios de proveedores preguntan cuántos CVE de severidad alta llevas sin resolver, y más de una póliza y más de un pliego se apoyan en esa misma aritmética. Todo eso da por hecho que un CVE es una cosa. Cuando un fabricante empieza a meter clases enteras en un identificador, la cuenta sigue saliendo —pero ya no mide lo mismo que medía el año pasado, ni lo mismo que mide el fabricante de al lado, que sigue emitiendo uno por fallo.

Y hay un segundo efecto, más práctico y más molesto para quien tiene que decidir el orden de trabajo. La excusa honrada de toda la vida —«ese fallo no me aplica porque esa función la tengo apagada»— necesita saber cuál es el fallo. Con un CVE paraguas de clase CWE no puedes hacer ese descarte: no sabes si el vector que te preocupa está o no está dentro de la bolsa. La única lectura defendible es la conservadora, que es tratar el grupo entero por su peor caso. Ayer mismo escribíamos sobre una etiqueta de fabricante que rebajaba la urgencia de un fallo; aquí no hay etiqueta que rebaje nada, hay un identificador que ya no se puede descomponer.

Cero mitigaciones, y lo que sí puedes tocar

«No hay soluciones alternativas» es una frase de dos segundos con un coste de semanas. Significa que no existe la lista de comandos con la que apagas la función vulnerable y te compras un mes para planificar la ventana. El único camino es la versión corregida, y en equipamiento de red la versión corregida no se instala: se cualifica, se prueba, se agenda de madrugada y se vigila el rearranque. Un controlador de SD-WAN manda sobre lo que hacen las sedes; los edges no pueden ir por delante de él, así que el orden es rígido y no admite improvisación. De lo que pasa cuando alguien entra en ese plano de control y reconfigura las sedes en vez de tirarlas ya hemos escrito, y ahí no se cae nada: por eso cuesta tanto verlo.

Dicho eso, que no haya mitigación del fabricante no quiere decir que estés de brazos cruzados hasta la ventana. Lo que sí puedes tocar es quién llega. Tres de estos cuatro productos —Catalyst SD-WAN, Crosswork y Secure Workload— son plano de gestión y orquestación, y un plano de gestión no tiene por qué ser alcanzable desde donde lo es hoy. Restringir el acceso a la interfaz de administración a una red de salto, exigir autenticación fuerte para entrar en ella y comprobar que nada de eso responde desde internet no cierra ninguno de los veintiún identificadores, pero cambia quién puede intentar aprovecharlos. Con IOS XE no sirve, porque ahí el software afectado es el del propio equipo: el aviso dice que aplica «regardless of device configuration» (con independencia de la configuración del dispositivo). Lo apuntamos porque es el mismo razonamiento del orquestador de SD-WAN que estaba expuesto por diseño: cuando el fallo no se puede tapar, lo que queda es la superficie.

La cadencia es la parte buena (con un pero el día 5)

La otra mitad del anuncio casi no se ha comentado y es la que más nos gusta. Desde julio, Cisco publica los avisos programados el primer y el tercer miércoles de cada mes a las 16:00 UTC, con siete días de aviso previo diciendo qué tecnologías y plataformas van a salir. Los sistemas operativos de red grandes pasan a ritmo trimestral. Las fechas de agosto cuadran con el calendario: el 5 y el 19 fueron el primer y el tercer miércoles, y el aviso de Crosswork lleva estampado «2026 August 19 16:00 GMT». Cumplen su propia agenda, que ya es más de lo que se puede decir de mucha política publicada.

Para quien opera infraestructura esto vale bastante más que un CVE bien desglosado. Un aviso con siete días de antelación convierte el parcheo en tarea planificable: se puede reservar gente, avisar al cliente y preparar la vuelta atrás antes de que exista el aviso. El goteo aleatorio de los últimos veinte años obligaba a lo contrario, a improvisar una guardia cada vez que salía algo un viernes por la tarde.

El pero, que ponemos como observación nuestra: el artículo de Russ Smoak dice «Cisco will not release multiple core NOS products on the same day» (Cisco no publicará varios productos de sistema operativo de red centrales el mismo día), y define esa lista como «Cisco IOS XE, IOS XR, NX-OS, Firepower/ASA, and SD-WAN». El 5 de agosto salieron el aviso de IOS XE y el de Catalyst SD-WAN, los dos el mismo día. No sabemos si internamente Catalyst SD-WAN cuenta como el «SD-WAN» de esa lista, y no lo vamos a suponer. Lo dejamos anotado porque si tienes las dos plataformas, ese día se te juntaron dos cualificaciones, que es justo lo que el compromiso quería evitar.

Quién puede seguir a lo suyo

Toca la parte que no vende. Si tu casa ya trabajaba por versiones y no por identificadores —es decir, si tu criterio era «los equipos de red van en la rama estable recomendada y se revisa cada trimestre»— este cambio no te obliga a nada. Llevabas años haciendo lo que Cisco acaba de convertir en política. Tampoco hay que correr por lo del 10.0: son fallos que encontró el propio fabricante, sin explotación conocida, y el aviso lo dice. Salir esta noche a actualizar un clúster de producción por un titular de tres cifras es peor idea que hacerlo con calma dentro de la ventana trimestral que ahora sí puedes prever.

Donde sí duele es en el otro extremo: el parque que lleva años en una rama antigua porque «funciona» y nadie quiere ser el que la toque. Ahí la respuesta del fabricante ya no es un parche pequeño, es un salto de versión, y ese salto arrastra cualificación, compatibilidad de plantillas y a veces hardware que no llega. Decirlo claro nos parece más útil que vender la actualización como un trámite. Nosotros no somos resellers de ninguna plataforma concreta ni cobramos comisión por licencias, así que la recomendación aquí no depende de qué se firme.

Qué haríamos esta semana

• Apuntarse al aviso de siete días. Es lo más barato de esta lista y lo que más cambia la planificación: saber una semana antes qué tecnologías entran en el aviso del miércoles permite reservar la ventana antes de que exista la urgencia.
• Sacar el inventario de versiones, no el de CVE. Qué rama corre cada equipo hoy, al lado de la primera versión corregida de la lista de arriba. Es una comparación de dos columnas y responde a la única pregunta que ahora importa: ¿está esta caja en versión endurecida o no?
• Cambiar el indicador antes de que lo pregunten. Si tu informe mensual dice «CVE críticos abiertos», ese número va a empezar a moverse por motivos que no tienen que ver con tu seguridad. Cámbialo por porcentaje de equipos en versión corregida vigente, que sí es comparable mes a mes.
• Reservar la ventana trimestral ahora. Si los sistemas de red van a ritmo trimestral, la ventana se puede poner en el calendario del año entero de una sentada, con su gente y su vuelta atrás escrita. Es más fácil mover una ventana reservada que crear una a las nueve de la noche.
• Comprobar desde dónde responde el plano de gestión. No cierra nada, pero es lo único accionable mientras llega la ventana. Desde una IP de fuera: a ver qué contesta la interfaz de administración del controlador. Si contesta, ahí hay trabajo para hoy.

Nos parece que esto no se queda en Cisco. Si la premisa es cierta —y el ritmo al que la IA saca fallos de código antiguo apunta a que lo es—, el resto de fabricantes grandes se van a encontrar con la misma aritmética y van a tomar decisiones parecidas. Cuando eso pase, quien haya montado su gestión de vulnerabilidades sobre el recuento de identificadores tendrá que rehacerla con prisa. Se puede rehacer ahora, sin prisa, con un aviso de siete días por delante.

Fuentes (verificadas el 21 de agosto de 2026): la fórmula de agrupación por CWE, la ausencia de soluciones alternativas, la frase del PSIRT sobre uso malicioso, los identificadores con sus puntuaciones y las primeras versiones corregidas, de los cuatro avisos de Cisco: Catalyst SD-WAN e IOS XE (ambos del 5 de agosto de 2026), Crosswork y Secure Workload (ambos del 19 de agosto de 2026). La cita de Russ Smoak, el motivo del cambio, la renuncia a los CVE individuales por fallo, el calendario de primer y tercer miércoles con aviso previo de siete días, el ritmo trimestral para los sistemas operativos de red, la lista de sistemas centrales («Cisco IOS XE, IOS XR, NX-OS, Firepower/ASA, and SD-WAN») y el compromiso de no publicar varios de ellos el mismo día, del artículo «Strengthening the Foundation» del blog de Cisco, del 2 de junio de 2026. La consolidación en CVE «paraguas» con la puntuación de la severidad más alta de la categoría, de la página de divulgación basada en riesgo de Cisco. Las citas se dan en su inglés original con nuestra traducción entre paréntesis, para que se puedan verificar palabra por palabra. Son cálculos y observaciones nuestros: la suma de veintiún identificadores y cinco puntuaciones de 10.0 entre esos cuatro avisos, la comprobación de que el 5 y el 19 de agosto de 2026 fueron el primer y el tercer miércoles, y la nota sobre los dos sistemas de red publicados el mismo día. No afirmamos cuántos fallos hay dentro de cada identificador porque los avisos no lo publican.