Un CVE ja no és una errada: Cisco ha canviat la unitat de mesura

Dijous vam mirar els avisos que Cisco va publicar dimecres i hi va haver un moment estrany. Tres CVE amb un 10.0 en un sol avís, dos més amb 10.0 en un altre, i en cap dels dos una llista d'errades que es pogués llegir una per una. No és un descuit de redacció: Cisco ho explica, i ho explica bé. Des del juliol, un identificador CVE seu no assenyala una errada, assenyala una classe d'errades. La notícia no és que hi hagi cinc deus. És que el número que fa anys que comptes ha canviat de mida.

Què diu l'avís quan diu «un CVE»

La frase és als quatre avisos, pràcticament amb la mateixa redacció: «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 agrupat aquests problemes per la seva classe de vulnerabilitat subjacent —CWE— i ha assignat un únic identificador CVE a cada agrupació de CWE). I a la pàgina on Cisco descriu el model nou hi ha una línia que tanca l'assumpte: les vulnerabilitats que comparteixen debilitat es consoliden en CVE «paraigua» i se'ls assigna la puntuació CVSS «based on the highest severity within that category» (segons la severitat més alta dins d'aquella categoria).

Llegeix-ho a poc a poc, perquè té dues conseqüències i cap no és òbvia. La primera: darrere d'un identificador hi pot haver dues errades o quinze, i l'avís no ho diu. La segona, més incòmoda: el 10.0 és la nota del pitjor element del grup, no la de tots. Si dins d'aquella bossa hi ha una errada remota sense autenticació i quatre més que exigeixen ser a dins, totes cinc es presenten sota un titular de 10.0. La puntuació no està inflada —el pitjor cas és real i per això mana—, però deixa de descriure el conjunt. És un sostre, no una mitjana, i fins ara el costum era llegir-la com si descrivís una cosa concreta.

Els quatre avisos d'agost, amb els seus números

Aquests són els quatre que hem obert i llegit sencers. No diem que siguin tots: Cisco va publicar força més avisos aquells dos dimecres —els previs del 5 i del 19 enumeren, entre altres, Catalyst SD-WAN Manager, IOS, BroadWorks, RoomOS o els commutadors IE1000— i no els hem revisat un per un. Aquests quatre sí que porten la fórmula del CVE agrupat.

• 5 d'agost — Catalyst SD-WAN. Cinc identificadors: tres en 9.9 (CVE-2026-20303, 20304 i 20310), un en 8.8 i un altre en 7.7. Afecta els quatre modes de desplegament, inclòs el gestionat al núvol. Primeres versions corregides: 20.9.10, 20.12.8.1, 20.15.6, 20.18.4 i 26.1.2.
• 5 d'agost — IOS XE. Set identificadors, el més alt un 9.8 (CVE-2026-20272) i un 9.0 al darrere. Branques afectades: 17.9, 17.12, 17.15, 17.18 i 26.1, en mode autònom o de controlador. Corregides a 17.9.10, 17.12.8, 17.15.6, 17.18.4 (o 17.18.4a) i 26.1.2.
• 19 d'agost — Crosswork. Quatre identificadors i tres d'ells en 10.0 (CVE-2026-20030, 20357 i 20358), més un 9.9. Afecta Data Gateway, Network Controller i Planning. La correcció és 7.2.1-SP.
• 19 d'agost — Secure Workload. Cinc identificadors, dos en 10.0 (CVE-2026-20315 i 20317), un en 9.9, un altre en 9.6 i un altre en 7.5. Afecta el servei al núvol i la instal·lació pròpia. Es corregeix a 3.10.9.1 i 4.0.4.16, i l'avís adverteix d'una cosa que se sol passar per alt: cal actualitzar el clúster, i els agents, i els connectors.

Sumen vint-i-un identificadors CVE i cinc deus —aquest recompte és nostre, fet sumant els quatre avisos—, i cap d'aquells vint-i-un equival a una errada. Hi ha dues frases més que es repeteixen literalment als quatre. Una és tranquil·litzadora: «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 té constància d'anuncis públics ni d'ús maliciós). Les va trobar Cisco, a casa seva, abans que ningú. L'altra frase no és gens tranquil·litzadora: «There are no workarounds that address these vulnerabilities» (no hi ha solucions alternatives que abordin aquestes vulnerabilitats).

El motiu, explicat en la seva versió forta

Abans de discrepar de res convé explicar l'argument de Cisco com l'explicaria Cisco, perquè és sòlid. Està signat el 2 de juny per Russ Smoak, vicepresident de seguretat de la informació, assegurament de la seguretat i resposta, i comença així: «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 […]» (l'escala de descobriment de vulnerabilitats ha canviat; els models d'IA de frontera i els entorns d'anàlisi agèntic estan traient errades en bases de codi grans a un ritme que el model tradicional de divulgació i pedaç no es va dissenyar mai per absorbir).

D'aquí surt tota la resta. Si una campanya d'anàlisi automatitzat treu dues-centes troballes de la mateixa classe al mateix mòdul, emetre dos-cents avisos amb dos-centes fitxes i dos-centes mitigacions puntuals no ajuda ningú: enterra el senyal sota el paperam. Cisco ho diu sense embuts —avaluar el risc de seguretat CVE a CVE i aplicar mitigacions puntuals «is no longer fit for purpose» (ja no serveix per al propòsit amb què es va crear)— i conclou que les versions endurides no portaran CVE individuals per errada perquè les correccions són transversals i el que toca és qualificar la versió i desplegar-la, no negociar amb cada troballa. Vist des del costat del fabricant, és difícil defensar el contrari.

El que es trenca no és el pedaç: és el recompte

Aquí és on el canvi deixa de ser un assumpte de Cisco i passa a ser teu. Mitja indústria de la gestió de vulnerabilitats compta CVE. Els quadres de comandament compten CVE oberts, els informes al comitè compten CVE crítics pendents, els qüestionaris de proveïdors pregunten quants CVE de severitat alta portes sense resoldre, i més d'una pòlissa i més d'un plec s'apuguen en aquesta mateixa aritmètica. Tot això dona per fet que un CVE és una cosa. Quan un fabricant comença a ficar classes senceres en un identificador, el compte continua sortint —però ja no mesura el mateix que mesurava l'any passat, ni el mateix que mesura el fabricant del costat, que continua emetent-ne un per errada.

I hi ha un segon efecte, més pràctic i més molest per a qui ha de decidir l'ordre de feina. L'excusa honrada de tota la vida —«aquesta errada no m'aplica perquè aquella funció la tinc apagada»— necessita saber quina és l'errada. Amb un CVE paraigua de classe CWE no pots fer aquell descart: no saps si el vector que et preocupa és o no és dins de la bossa. L'única lectura defensable és la conservadora, que és tractar el grup sencer pel seu pitjor cas. Ahir mateix escrivíem sobre una etiqueta de fabricant que rebaixava la urgència d'una errada; aquí no hi ha etiqueta que rebaixi res, hi ha un identificador que ja no es pot descompondre.

Zero mitigacions, i el que sí que pots tocar

«No hi ha solucions alternatives» és una frase de dos segons amb un cost de setmanes. Vol dir que no existeix la llista d'ordres amb què apagues la funció vulnerable i et compres un mes per planificar la finestra. L'únic camí és la versió corregida, i en equipament de xarxa la versió corregida no s'instal·la: es qualifica, es prova, s'agenda de matinada i es vigila el rearrencament. Un controlador d'SD-WAN mana sobre el que fan les seus; els edges no poden anar per davant d'ell, així que l'ordre és rígid i no admet improvisació. Del que passa quan algú entra en aquest pla de control i reconfigura les seus en comptes de tirar-les ja n'hem escrit, i allà no cau res: per això costa tant de veure.

Dit això, que no hi hagi mitigació del fabricant no vol dir que estiguis de braços plegats fins a la finestra. El que sí que pots tocar és qui hi arriba. Tres d'aquests quatre productes —Catalyst SD-WAN, Crosswork i Secure Workload— són pla de gestió i orquestració, i un pla de gestió no ha de ser abastable des d'on ho és avui. Restringir l'accés a la interfície d'administració a una xarxa de salt, exigir autenticació forta per entrar-hi i comprovar que res d'allò no respon des d'internet no tanca cap dels vint-i-un identificadors, però canvia qui pot intentar aprofitar-los. Amb IOS XE no serveix, perquè allà el programari afectat és el del mateix equip: l'avís diu que aplica «regardless of device configuration» (amb independència de la configuració del dispositiu). Ho apuntem perquè és el mateix raonament de l'orquestrador d'SD-WAN que estava exposat per disseny: quan l'errada no es pot tapar, el que queda és la superfície.

La cadència és la part bona (amb un però el dia 5)

L'altra meitat de l'anunci gairebé no s'ha comentat i és la que més ens agrada. Des del juliol, Cisco publica els avisos programats el primer i el tercer dimecres de cada mes a les 16:00 UTC, amb set dies d'avís previ dient quines tecnologies i plataformes sortiran. Els sistemes operatius de xarxa grans passen a ritme trimestral. Les dates d'agost quadren amb el calendari: el 5 i el 19 van ser el primer i el tercer dimecres, i l'avís de Crosswork porta estampat «2026 August 19 16:00 GMT». Compleixen la seva pròpia agenda, que ja és més del que es pot dir de moltes polítiques publicades.

Per a qui opera infraestructura això val força més que un CVE ben desglossat. Un avís amb set dies d'antelació converteix l'aplicació de pedaços en una tasca planificable: es pot reservar gent, avisar el client i preparar la tornada enrere abans que existeixi l'avís. El degoteig aleatori dels últims vint anys obligava al contrari, a improvisar una guàrdia cada vegada que sortia alguna cosa un divendres a la tarda.

El però, que posem com a observació nostra: l'article de Russ Smoak diu «Cisco will not release multiple core NOS products on the same day» (Cisco no publicarà diversos productes de sistema operatiu de xarxa centrals el mateix dia), i defineix aquella llista com «Cisco IOS XE, IOS XR, NX-OS, Firepower/ASA, and SD-WAN». El 5 d'agost van sortir l'avís d'IOS XE i el de Catalyst SD-WAN, tots dos el mateix dia. No sabem si internament Catalyst SD-WAN compta com el «SD-WAN» d'aquella llista, i no ho suposarem. Ho deixem anotat perquè si tens les dues plataformes, aquell dia se't van ajuntar dues qualificacions, que és just el que el compromís volia evitar.

Qui pot continuar a la seva

Toca la part que no ven. Si ja treballaves per versions i no per identificadors —és a dir, si el teu criteri era «els equips de xarxa van a la branca estable recomanada i es revisa cada trimestre»— aquest canvi no t'obliga a res. Fa anys que fas el que Cisco acaba de convertir en política. Tampoc cal córrer pel 10.0: són errades que va trobar el mateix fabricant, sense explotació coneguda, i l'avís ho diu. Sortir aquesta nit a actualitzar un clúster de producció per un titular de tres xifres és pitjor idea que fer-ho amb calma dins de la finestra trimestral que ara sí que pots preveure.

On sí que fa mal és a l'altre extrem: el parc que fa anys que és en una branca antiga perquè «funciona» i ningú no vol ser qui la toqui. Allà la resposta del fabricant ja no és un pedaç petit, és un salt de versió, i aquell salt arrossega qualificació, compatibilitat de plantilles i de vegades maquinari que no hi arriba. Dir-ho clar ens sembla més útil que vendre l'actualització com un tràmit. Nosaltres no som resellers de cap plataforma concreta ni cobrem comissió per llicències, així que la recomanació aquí no depèn de què se signi.

Què faríem aquesta setmana

• Apuntar-se a l'avís de set dies. És el més barat d'aquesta llista i el que més canvia la planificació: saber una setmana abans quines tecnologies entren a l'avís del dimecres permet reservar la finestra abans que existeixi la urgència.
• Treure l'inventari de versions, no el de CVE. Quina branca corre cada equip avui, al costat de la primera versió corregida de la llista de dalt. És una comparació de dues columnes i respon a l'única pregunta que ara importa: aquesta caixa està en versió endurida o no?
• Canviar l'indicador abans que el preguntin. Si el teu informe mensual diu «CVE crítics oberts», aquell número començarà a moure's per motius que no tenen a veure amb la teva seguretat. Canvia'l per percentatge d'equips en versió corregida vigent, que sí que és comparable mes a mes.
• Reservar la finestra trimestral ara. Si els sistemes de xarxa van a ritme trimestral, la finestra es pot posar al calendari de tot l'any d'una tirada, amb la seva gent i la seva tornada enrere escrita. És més fàcil moure una finestra reservada que crear-ne una a les nou del vespre.
• Comprovar des d'on respon el pla de gestió. No tanca res, però és l'única cosa accionable mentre arriba la finestra. Des d'una IP de fora: a veure què contesta la interfície d'administració del controlador. Si contesta, allà hi ha feina per a avui.

Ens sembla que això no es queda a Cisco. Si la premissa és certa —i el ritme al qual la IA treu errades de codi antic apunta que ho és—, la resta de fabricants grans es trobaran amb la mateixa aritmètica i prendran decisions semblants. Quan això passi, qui hagi muntat la seva gestió de vulnerabilitats sobre el recompte d'identificadors haurà de refer-la amb pressa. Es pot refer ara, sense pressa, amb un avís de set dies per davant.

Fonts (verificades el 21 d'agost del 2026): la fórmula d'agrupació per CWE, l'absència de solucions alternatives, la frase del PSIRT sobre ús maliciós, els identificadors amb les seves puntuacions i les primeres versions corregides, dels quatre avisos de Cisco: Catalyst SD-WAN i IOS XE (tots dos del 5 d'agost del 2026), Crosswork i Secure Workload (tots dos del 19 d'agost del 2026). La citació de Russ Smoak, el motiu del canvi, la renúncia als CVE individuals per errada, el calendari de primer i tercer dimecres amb avís previ de set dies, el ritme trimestral per als sistemes operatius de xarxa, la llista de sistemes centrals («Cisco IOS XE, IOS XR, NX-OS, Firepower/ASA, and SD-WAN») i el compromís de no publicar-ne diversos el mateix dia, de l'article «Strengthening the Foundation» del blog de Cisco, del 2 de juny del 2026. La consolidació en CVE «paraigua» amb la puntuació de la severitat més alta de la categoria, de la pàgina de divulgació basada en risc de Cisco. Les citacions es donen en el seu anglès original amb la nostra traducció entre parèntesis, perquè es puguin verificar paraula per paraula. Són càlculs i observacions nostres: la suma de vint-i-un identificadors i cinc puntuacions de 10.0 entre aquells quatre avisos, la comprovació que el 5 i el 19 d'agost del 2026 van ser el primer i el tercer dimecres, i la nota sobre els dos sistemes de xarxa publicats el mateix dia. No afirmem quantes errades hi ha dins de cada identificador perquè els avisos no ho publiquen.