L'avís de Cisco del 28 d'octubre diu dues coses a la mateixa pàgina. Una: «no hi ha solucions alternatives que resolguin aquesta vulnerabilitat». L'altra, més avall: pots mitigar-la retirant l'autenticació secundària del grup de túnel, i el mateix avís reconeix que això redueix la teva postura de seguretat. Totes dues hi són, i l'avís no tria per tu.
És CVE-2026-76418, al servei de VPN SSL d'accés remot de Cisco Secure Firewall ASA i FTD. Un atacant sense autenticar envia una petició preparada i el tallafocs es recarrega. Puntua 8,6 i el PSIRT diu haver tingut notícia d'explotació activa abans de publicar l'avís. Sobre què significa que una fallada d'aquest servei només afecti la disponibilitat ho vam explicar aleshores, quan a l'agost va passar una cosa molt semblant; aquest post va de la part que a l'agost no existia.
Què demana l'avís per considerar-te vulnerable
Tres condicions, i totes tres surten de la configuració en marxa, no de l'inventari:
- 1Hi ha un bloc
webvpna la configuració. - 2A dins hi ha un
enable <interfície>, és a dir, la VPN SSL d'accés remot està habilitada en almenys una interfície. - 3Algun grup de túnel té
secondary-authentication-server-group.
Si en falla qualsevol de les tres, l'avís no t'aplica. Això és més gent de la que sembla, i per això la tercera condició mereix el seu propi apartat: s'està llegint malament gairebé pertot.
secondary-authentication no és el mateix que «tenir MFA»
La condició és aquesta ordre, literalment, no la idea de tenir un segon factor. I són coses diferents. En molts desplegaments el doble factor es resol amb un únic grup d'autenticació —un RADIUS que per dins fa la contrasenya i l'empenta al mòbil, o SAML contra el proveïdor d'identitat— i aleshores no existeix cap secondary-authentication-server-group a la configuració. Aquest muntatge no compleix la tercera condició, per molt MFA que tinguin els teus usuaris.
Ho diem perquè la lectura que circula —«si vas posar doble factor, et toca»— enviarà gent a una finestra de servei que no necessita. El que decideix no és la teva política d'identitat: és si aquesta ordre apareix en llegir la configuració. Comprova-ho abans de moure res.
El grup que ningú no va crear a mà
Hi ha una instrucció de l'avís que es salta gairebé tothom. Si tens tunnel-group-list enable, Cisco demana revisar tots els grups de túnel, i anomena expressament DefaultWEBVPNGroup. És el grup que ve de fàbrica, el que ningú no va crear expressament i el que no apareix quan preguntes a l'equip quins grups hi ha muntats. Si algú li va posar autenticació secundària en algun moment —o l'hi va deixar posada una migració de fa sis anys— compleixes la tercera condició sense saber-ho.
Què perds amb cada opció
Si compleixes les tres condicions, el menú de l'avís és aquest:
| Opció | Què et costa | Què et deixa |
|---|---|---|
| Actualitzar | Una finestra de servei, amb el seu tall | La fallada tancada i l'autenticació com estava |
| Mitigar | L'autenticació secundària d'aquest grup de túnel | Un equip que ja no es recarrega, i una porta amb una volta de clau menys |
| Esperar | Res avui | El mateix tall, a l'hora que triï un altre |
La fila del mig és la que convé mirar dues vegades. Cisco l'ofereix i alhora recomana actualitzar, perquè sap què costa. Si la fas servir, que sigui com a pas d'unes hores, amb data de caducitat escrita al tiquet i al calendari d'algú amb nom. Un doble factor retirat «mentrestant» és la mena de canvi que continua allà dos anys després perquè ningú no recorda per què es va fer.
El segon del mateix servei des de l'agost
L'11 d'agost del 2026 Cisco va avisar de CVE-2026-20349: mateix producte, mateix servei de VPN SSL d'accés remot, mateixa puntuació de 8,6, mateix atacant sense autenticar i també explotat abans de l'avís, per comprovació d'errors insuficient en processar peticions HTTP. Entre aquell avís i aquest han passat 78 dies. Els terminis que CISA va donar en tots dos casos van ser de tres dies —el d'ara venç l'1 de novembre, que cau en diumenge— i sobre aquesta aritmètica de caps de setmana ja vam comptar els dies sobre el mateix fitxer de CISA.
Dos avisos no són una tendència estadística, i no te la vendrem com a tal. Però sí que canvien la pregunta de planificació: si el mateix servei t'ha demanat una finestra d'urgència dues vegades en onze setmanes, el calendari de pedaços que tenies escrit per a ell s'ha quedat curt.
Si has de casar identificadors per a un informe
Un apunt pràctic que ens vam trobar en descarregar el catàleg de CISA i que no hem vist citat: les dues fonts no anomenen igual la mateixa fallada. El catàleg titula l'entrada de CVE-2026-76418 com a «desreferència de punter nul per valor de retorn sense comprovar», mentre que la prosa de l'avís de Cisco parla d'«errors de lògica». Amb el d'agost passa el mateix: CISA el cataloga com a «vulnerabilitat d'inspecció de monticle» i Cisco en descriu una altra cosa. No és contradictori —una pot ser la causa arrel de l'altra— però si estàs muntant un informe que creua totes dues fonts, esperar el mateix text et costarà una estona.
Sobre la xifra que circula aquests dies: Shadowserver veu més de 51.000 dispositius Cisco ASA amb la VPN SSL exposats a internet. Ho apunta el mateix mitjà que la publica i convé repetir-ho: això compta serveis visibles, no equips vulnerables. No distingeix versió, no sap quins tenen autenticació secundària configurada —que és la tercera condició— i no separa els esquers. És una mesura de superfície, no un recompte de víctimes.
El que el pedaç no canvia
Les versions corregides d'ASA són 9.16.4.104 per a la branca 9.16 i anteriors, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48 i 9.24.1.27 (o 9.24.10.1) segons la branca on visquis. Actualitza. Però quan tanquis la finestra continuaràs tenint al davant dues preguntes que el pedaç no toca:
- →Per on hi entres a arreglar-ho. Si el camí d'administració passa per l'aparell que cal administrar, no tens accés d'emergència. Una via fora de banda existeix exactament per a nits com aquesta.
- →Què més acaba en aquesta caixa. Usuaris remots, túnels entre seus i accés de proveïdors solen acabar al mateix lloc per comoditat, i aleshores se'n van junts. I un enllaç de reserva que acaba al mateix equip amb la mateixa versió no és un segon camí: ja vam escriure sobre per què dos camins només compten com a dos si no comparteixen res.
Repartir aquestes peces —que l'accés d'usuaris i el de seus no visquin a la mateixa caixa, que el pla d'administració tingui porta pròpia— és feina de disseny de xarxa i comunicacions. Quan hi ha diverses seus pel mig, és la conversa d'una SD-WAN ben plantejada: diversos camins, commutació automàtica i la política escrita en un lloc.
Com ho mirem nosaltres
No som resellers de cap fabricant de tallafocs: recomanem segons el cas, no segons la comissió. Som operador amb xarxa pròpia —BGP, trànsit i peering, amb el looking glass públic a lg.everywan.com— i muntem accés remot i interconnexió de seus amb WireGuard i SD-WAN segons el cas. Quan cau un avís així, dues coses ens estalvien la nit: la xarxa documentada a NetBox, que converteix «a quants llocs nostres els toca això?» en una consulta en comptes d'una ronda de correus; i un monitoratge —Zabbix i SmokePing, amb alertes que importen i no soroll— que distingeix un equip que s'ha recarregat d'un equip que respon al ping.
I una cosa que faríem encara que no compleixis les tres condicions: llegir-te la configuració sencera dels grups de túnel aquesta setmana. No per aquesta fallada, sinó perquè si cal mirar-la amb pressa diumenge al matí, ja has perdut la part difícil.
Fonts (verificades el 30 d'octubre del 2026): Avís de seguretat de Cisco cisco-sa-asaftd-tunnel-dos-s6mgkb75, publicat el 28-10-2026 a les 19:15 GMT, versió 1.0 final — d'allà surten CVE-2026-76418, la puntuació base 8,6 amb vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, la causa («logic errors when secondary authentication is configured on a tunnel group»), les tres condicions de producte vulnerable (webvpn amb enable en una interfície, secondary-authentication-server-group, i la revisió de tots els grups inclòs DefaultWEBVPNGroup quan hi ha tunnel-group-list enable), la frase «there are no workarounds that address this vulnerability» juntament amb la mitigació i el seu advertiment d'impacte en la seguretat, les versions corregides (9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27 / 9.24.10.1) i la nota d'explotació activa l'octubre del 2026. Dades de la fallada de l'agost: avís cisco-sa-asaftd-vpn-dos-dzv4mQFF (CVE-2026-20349, 11-08-2026, 8,6, comprovació d'errors insuficient en processar peticions HTTP al servei de VPN SSL d'accés remot). Dates d'alta i terminis: catàleg de vulnerabilitats explotades de CISA, versió 2026.10.29 amb 1.764 entrades, descarregada i llegida per nosaltres — CVE-2026-76418 amb alta el 29-10-2026 i termini 01-11-2026, titulada allà «Unchecked Return Value to NULL Pointer Dereference»; CVE-2026-20349 amb alta l'11-08-2026, termini 14-08-2026 i titulada «Heap Inspection Vulnerability». La xifra de més de 51.000 ASA amb VPN SSL exposats, i l'advertiment que no equival a equips vulnerables, són de BleepingComputer (29-10-2026). Els 78 dies entre l'11 d'agost i el 28 d'octubre i l'apunt sobre la diferència de denominació entre CISA i Cisco són aritmètica i lectura nostres. La distinció entre secondary-authentication-server-group i «tenir MFA», la taula d'opcions i les dues preguntes de disseny també són nostres.
Saps avui quins grups de túnel tens i quina autenticació porta cadascun?
A everyWAN dissenyem i operem l'accés remot i la interconnexió de seus d'empreses que no es poden permetre una tarda a les fosques. Et fem el mapa de què depèn de què i et diem on és la peça única.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN