Vas aplicar el pedaç del switch i continuaves exposat 128 dies

El 22 de setembre vam escriure aquí que el pedaç del teu switch feia 97 dies que estava publicat. Era veritat i el càlcul estava bé. El que no sabíem —i se sap des del 3 de novembre— és que aquell pedaç deixava a dins un desbordament que permet executar ordres com a root sense autenticar-se. Qui el va instal·lar el primer dia va continuar exposat fins al 22 d'octubre: 128 dies més.

Aquesta és una història de gent que va apedaçar, i el motiu pel qual tant se val cap en una línia de pseudocodi: la correcció de juny comptava els paràmetres després de copiar-los.

Què es va arreglar al juny i què no

El programa CGI d'aquests switches guarda els paràmetres de cada petició HTTP en un objecte global anomenat reqParameters. Són 140 ranures de 1.024 bytes —l'avís declara 143.364 bytes de reserva total; 140 × 1.024 són 143.360— i, enganxat just al darrere en el mateix segment .bss, el comptador que porta el compte de quantes ranures s'han fet servir: g_count. El comptador viu just darrere de l'array, sense res enmig.

Si envies un paràmetre número 140 més llarg que el seu buit, la còpia se surt de l'array i aterra al comptador. A partir d'aquí el paràmetre següent s'escriu on tu diguis, i això inclou la taula de punters a funcions del mateix programa. Ordres del sistema, amb usuari root, sense autenticar-se.

El que Zyxel va afegir al juny, segons el diff de binaris que publica Binarly, van ser dues comprovacions: incrementar el comptador i sortir si arriba a 140, i retallar-lo a 140 si arriba a 141. És a dir, una comprovació de límit correcta, posada al lloc equivocat. La frase de Binarly és més seca que qualsevol paràfrasi: «Aquest canvi no aborda la vulnerabilitat. La còpia sense límit a l'entrada 139 passa abans de la comprovació. Això vol dir que el valor de g_count es pot sobreescriure abans que es pugui comprovar.»

Els deu arxius de firmware publicats al juny, un per model, contenen exactament el mateix binari. Binarly dona l'empremta SHA-256 de la càrrega .bix i de cadascun dels set programes CGI, i és idèntica als deu. Eren deu descàrregues del mateix codi. La seva conclusió, literal: «En qualsevol dels dos casos, la vulnerabilitat descrita en aquest avís és present als deu llançaments de firmware que es van anunciar com a correccions.»

Les tres fonts que t'enviaven a apedaçar descrivien una altra fallada

Aquí hi ha el que de debò interessa a qui gestiona un parc, i té poc a veure amb Zyxel: va de com decideixes a què dediques el dimarts. Si al setembre prioritzaves pels tres senyals habituals, els tres apuntaven al lloc equivocat.

La fila del mig és la més interessant i la menys còmoda, perquè les dues puntuacions poden ser correctes alhora. La diferència entre 8,8 i 9,8 aquí no és tècnica, és topològica: Binarly diu que l'explotació va per HTTP i no té cap requisit d'adjacència a nivell de protocol, que n'hi ha prou amb «accessibilitat de xarxa al servei de gestió». Si la interfície web dels teus switches només viu en una VLAN de gestió aïllada, el 8,8 descriu el teu cas. Si és a la mateixa xarxa que els llocs de treball, el teu cas el descriu el 9,8. Ja ho vam explicar amb un altre fabricant: ho decideix la teva configuració, no la puntuació.

I sobre la tercera fila, una comprovació que hem fet avui per no refiar-nos: hem descarregat el catàleg KEV complet (versió 2026.11.04, 1.768 entrades) i hem buscat. CVE-2026-7273 hi és, des del 21 de setembre. CVE-2026-107441, la fallada que el firmware de juny es va deixar a dins i que implementa l'exploit capturat, no. A hores d'ara, qui governi el seu apedaçament pel catàleg no té oberta cap tasca per aquell desbordament.

La cronologia, que és el document més dur

Dos buits d'aquella taula valen una conversa sencera. El primer: entre el 22 d'octubre, quan apareix el firmware bo, i el 3 de novembre, quan s'explica per què cal, passen 12 dies. Dotze dies en què la correcció estava publicada com un «Patch 3» al fòrum de la comunitat del fabricant —una nota de versió entre altres— sense cap avís de seguretat que li donés urgència. Si el teu procés espera l'avís per moure peça, arribaves dotze dies tard fins i tot fent-ho tot bé.

El segon: nosaltres vam publicar el 22 de setembre i Binarly va tancar la seva verificació el 28. Sis dies. No teníem manera de saber-ho i no ens vam inventar res —tot el que vam escriure aleshores sortia dels registres oficials—, però el marc estava malament: vam comptar els dies que el pedaç feia que estava disponible com si instal·lar-lo tanqués l'assumpte. El nombre era correcte i la conclusió que convidava a treure, no.

El que es van endur no ho torna cap firmware

Aquesta és la part que es perd als titulars sobre pedaços. GreyNoise va documentar què va sortir d'aquells 996 switches a 48 països: les configuracions, les credencials de root (en forma de hash) i la informació de xarxa. El plànol de l'edifici. VLANs, adreçament, noms, què parla amb què.

I una dada del mateix informe que convé llegir dues vegades: 564 de les víctimes tenien les credencials de fàbrica. Més de la meitat. La fallada no necessitava contrasenya per entrar —és prèvia a l'autenticació—, així que aquells 564 no van caure per això; però quan s'exfiltra la configuració d'un equip amb la contrasenya de fàbrica posada, el que s'obté és una clau que continua sent vàlida després d'actualitzar el firmware. Actualitzar tanca la porta. No invalida les credencials que ja van sortir, ni fa que l'atacant oblidi la teva topologia.

De la classe d'equip del qual parlem ja vam escriure sobre el switch que no és de ningú: es compra un cop, es munta, funciona vuit anys i no apareix en cap inventari d'apedaçament. La diferència és que aquí ningú no se n'hauria assabentat des de dins. Un switch d'accés no porta agent, no té EDR i no et trucarà. El que queda és telemetria guardada i algú que la miri —l'argument de detecció i resposta gestionada— i aquest és justament el problema que ja vam tractar quan explicàvem que l'avís va arribar 47 dies tard i els teus registres duren 30.

Abans que això s'expliqui malament

Quatre acotacions, perquè la versió exagerada d'aquest post seria falsa i circularia millor.

Sis coses, i només una és apedaçar

Només el primer punt és «apedaçar». Els altres cinc són els que canvien alguna cosa, i cap no caduca amb el pròxim avís.

Els punts 2 i 5 són feina de xarxes i comunicacions gestionades i no es fan amb un butlletí: es fan un cop, amb la xarxa davant. El punt 6 és manteniment informàtic en una frase. I segmentar el pla de gestió és el que converteix la pròxima fallada d'aquest tipus —que arribarà, d'un altre fabricant i en un altre CGI— en un avís que llegeixes amb calma en lloc d'en una tarda.

La lliçó que ens enduem nosaltres no és sobre Zyxel ni sobre un comptador mal col·locat. És que «estem al dia» no descriu un estat de seguretat: descriu un número de versió que coincideix amb el que un fabricant va dir que estava bé.

Fonts. Consultades el 5 de novembre del 2026. L'anàlisi tècnica —la funció web_util_initParaPairs, l'objecte global reqParameters amb 140 entrades de 1.024 bytes i g_count immediatament al darrere a .bss, el diff de les línies afegides al juny, les dues cites literals, l'empremta SHA-256 idèntica de la càrrega .bix als deu arxius, la valoració AV:N / 9,8 i la cronologia de divulgació— és de l'avís BRLY-2026-057 de Binarly, publicat el 3 de novembre del 2026. Les dues fitxes oficials, assignades per Zyxel com a CNA, via l'API del CVE Program: CVE-2026-7273 (publicada el 16-06-2026, CWE-121, CVSS 3.1 8,8 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) i CVE-2026-107441 (publicada el 03-11-2026 a les 01:41 UTC, CWE-787, mateix CVSS i mateix vector). Els deu models i el pas de .2)C0 a .3)C0, l'historial de revisions d'una sola línia («2026-11-3: Initial release»), el crèdit a Yegor Vasilenko i Fernando Mercês de Binarly i l'absència de qualsevol menció a explotació activa o a rotació de credencials són de l'avís de Zyxel del 3 de novembre. Els 996 switches a 48 països, la data «al voltant del 17 d'agost», què es va exfiltrar (configuracions, credencials de root en hash i informació de xarxa) i les 564 víctimes amb credencials de fàbrica són de l'informe de GreyNoise «Open Season on Kapibala», del 21 de setembre del 2026, que atribueix l'activitat a un actor que anomena Kapibala i el situa com «el mateix o relacionat» amb la campanya Red Heron. L'alta de CVE-2026-7273 al catàleg KEV el 21-09-2026 amb termini federal el 24, i l'absència de CVE-2026-107441 en aquell catàleg, els hem comprovat nosaltres descarregant el JSON complet del KEV (versió 2026.11.04, 1.768 entrades, publicat el 04-11-2026 a les 20:00 UTC). Els càlculs de dies (128 de juny a octubre, 140 d'avís a avís, 12 del firmware a l'avís, 6 del nostre post a la verificació de Binarly) són nostres, sobre aquelles dates. L'ús de NetBox com a font de veritat i el criteri sobre segmentació del pla de gestió són de la nostra pròpia feina de xarxes gestionades, i no estan avalats per aquelles fonts.