Zyxel GS1900 CVE-2026-107441: la patch di giugno non ha tenuto

Zyxel ha assegnato un secondo CVE ai suoi switch smart-managed GS1900 e ha rilasciato firmware nuovo, perché la correzione pubblicata a giugno non aveva mai chiuso davvero il buco. CVE-2026-107441 è un out-of-bounds write nel CGI di gestione web dello switch che permette a un attaccante non autenticato, adiacente alla LAN, di eseguire comandi di sistema con una singola richiesta HTTP — la stessa portata di CVE-2026-7273, la falla di giugno che GreyNoise ha visto usare per compromettere quasi mille switch nel mondo. I ricercatori di Binarly hanno scoperto che la patch di giugno si poteva attraversare di slancio, lo hanno segnalato a Zyxel, e ora ci sono un nuovo advisory, un nuovo CVE e firmware nuovo. Se a giugno avete aggiornato gli switch GS1900 e chiuso il ticket, quel ticket è di nuovo aperto.

Notizia in evoluzione — pubblicata alle 08:31 (07:31 UTC) del 5 novembre 2026. Aggiornata man mano che Zyxel, Binarly e CISA pubblicano.

In breve

CVE	CVE-2026-107441
Prodotto / versioni colpite	Switch smart-managed Zyxel serie GS1900 — 10 modelli; firmware 2.90(…​.2)C0 e precedenti (stringhe per modello più sotto)
Corretta in	Firmware per modello 2.90(…​.3)C0, rilasciato il 2026-10-22 (tabella completa in Remediation)
CVSS	8.8 HIGH · CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · assegnato da Zyxel; Binarly lo valuta 9.8 Critical, sostenendo che è raggiungibile via HTTP in chiaro da qualunque rete che arrivi allo switch; NVD "Awaiting Analysis", ancora senza punteggio NIST
Debolezza	CWE-787 out-of-bounds write nel CGI di gestione web (dispatcher.cgi)
Sfruttata attivamente	La campagna sui GS1900 (996 dispositivi · 48 Paesi, GreyNoise) era stata attribuita a CVE-2026-7273; Binarly ha mostrato che quella patch era aggirabile, quindi quale falla la campagna abbia davvero usato non è confermato
CISA KEV	Non elencata (catalogo 2026.11.04); la sibling CVE-2026-7273 è stata aggiunta il 2026-09-21
Advisory ufficiale	Advisory Zyxel, 2026-11-03

Una patch che non ha tenuto

A giugno Zyxel ha corretto CVE-2026-7273, un buffer overflow nel CGI di gestione web dei GS1900 che dava a un attaccante non autenticato, basato in LAN, l'esecuzione di comandi di sistema con una sola richiesta HTTP. A settembre BleepingComputer ha riportato la scoperta di GreyNoise: un attore di lingua cinese — tracciato come Kapibala e collegato alla campagna Red Heron — aveva usato quella falla per compromettere 996 switch GS1900 in 48 Paesi, estraendo configurazioni dei dispositivi, informazioni di rete e credenziali root in hash. Il 21 settembre CISA ha aggiunto CVE-2026-7273 al suo catalogo Known Exploited Vulnerabilities.

Il problema: la correzione di giugno aggiungeva un controllo, ma nel punto sbagliato. Mentre mappava l'infrastruttura di Red Heron, Binarly ha trovato un exploit Python offuscato — probabilmente generato da un LLM — per gli switch GS1900 in una directory esposta dell'attaccante, e ha scoperto che funzionava ancora su tutte e dieci le release firmware già corrette per CVE-2026-7273. Secondo l'analisi di Binarly, ripresa da securityonline, il gestore web dispatcher.cgi memorizza i parametri HTTP in ingresso in un blocco fisso di 140 slot da 1.024 byte ciascuno e copia i dati prima di verificare il conteggio dei parametri. Un valore sovradimensionato nell'ultimo slot deborda dal buffer e sovrascrive il contatore dei parametri; il conteggio negativo che ne risulta consente di scrivere nella memoria prima del blocco, sovrascrivere puntatori a funzione ed eseguire comandi di sistema come root. La patch di giugno aggiungeva un controllo del conteggio — ma il controllo gira dopo che il parametro sovradimensionato è già stato copiato, e non ha mai validato la lunghezza del singolo campo. Questa radice distinta e non affrontata è il motivo per cui Zyxel ha assegnato un CVE separato, CVE-2026-107441. (Binarly nota anche che il buffer corrotto vive in memoria globale, non nello stack, quindi la definizione originale di "stack-based overflow" era essa stessa imprecisa.)

Yegor Vasilenko e Fernando Mercês di Binarly hanno segnalato la falla a Zyxel il 29 settembre; Zyxel ha assegnato il CVE l'11 ottobre, rilasciato il firmware il 22 ottobre e pubblicato l'advisory il 3 novembre. Il firmware di ottobre limita la dimensione di ogni campo copiato e valida il conteggio dei parametri prima di copiarli in memoria — la correzione che la patch di giugno avrebbe dovuto essere.

Questa sequenza è tutta la lezione. Se la campagna in-the-wild abbia usato l'overflow originale o il bypass non è confermato — ma per chi aveva applicato il firmware di giugno l'esito operativo è lo stesso: la mitigazione di cui si fidava non ha fermato la tecnica.

"Quella l'abbiamo corretta a giugno." È questa la frase-trappola. Una patch è l'affermazione che un certo percorso di codice è ora sicuro. Qui il percorso era ancora raggiungibile, e l'unico modo di saperlo era eseguire l'exploit contro il firmware corretto — esattamente ciò che Binarly ha fatto e che chi aveva installato il firmware di giugno non aveva fatto.

Chi è esposto

I GS1900 sono switch Layer-2 smart-managed venduti a centinaia di migliaia in reti piccole e medie, filiali e armadi di cablaggio. Zyxel valuta l'attacco AV:A — adiacente alla LAN — quindi sulla carta l'esposizione è di chiunque raggiunga l'interfaccia di gestione web dello switch. Binarly contesta questa lettura e assegna 9.8, sostenendo che la falla è raggiungibile via HTTP in chiaro e non autenticato da qualunque percorso di rete verso lo switch; un GS1900 con la UI di gestione esposta a un segmento più ampio, a una rete d'ufficio piatta o a internet è di fatto raggiungibile da remoto. In ogni caso è la popolazione colpita a raccontare la storia vera: dei 996 switch compromessi contati da GreyNoise, 564 erano ancora con le credenziali di fabbrica, e le concentrazioni maggiori erano in Italia, Stati Uniti e Taiwan. Molte di queste interfacce sono raggiungibili da dove non dovrebbero, da attaccanti che per entrare non avevano nemmeno bisogno del bug.

Remediation

Sono vulnerabile?

Verificate il firmware in esecuzione su ogni switch GS1900 (UI web: Monitor → System Information, oppure la CLI dello switch). Siete colpiti se la versione è pari o inferiore alla stringa per modello 2.90(…​.2)C0 nella tabella sotto. Inventariate anche quali switch espongono l'interfaccia di gestione, e da dove — uno switch irraggiungibile da una subnet utente è molto più difficile da colpire con questo bug.

Patch — versioni corrette esatte

Zyxel ha rilasciato il firmware corretto il 22 ottobre 2026 per i dieci modelli "ancora nel loro periodo di supporto di sicurezza"; i modelli a listino non elencati sono indicati come non interessati. Applicate la build corretta per il vostro modello esatto:

Modello	Colpito (≤)	Corretto
GS1900-8	2.90(AAHH.2)C0	2.90(AAHH.3)C0
GS1900-8HP	2.90(AAHI.2)C0	2.90(AAHI.3)C0
GS1900-10HP	2.90(AAZI.2)C0	2.90(AAZI.3)C0
GS1900-16	2.90(AAHJ.2)C0	2.90(AAHJ.3)C0
GS1900-24	2.90(AAHL.2)C0	2.90(AAHL.3)C0
GS1900-24E	2.90(AAHK.2)C0	2.90(AAHK.3)C0
GS1900-24EP	2.90(ABTO.2)C0	2.90(ABTO.3)C0
GS1900-24HPv2	2.90(ABTP.2)C0	2.90(ABTP.3)C0
GS1900-48	2.90(AAHN.2)C0	2.90(AAHN.3)C0
GS1900-48HPv2	2.90(ABTQ.2)C0	2.90(ABTQ.3)C0

Fonte: l'advisory Zyxel del 3 novembre 2026. Se il vostro modello è fuori supporto e non è in tabella, non riceverà questo firmware — consideratelo vulnerabile in modo permanente e pianificate la sostituzione.

Non potete aggiornare subito? Controlli compensativi

Il bug ha bisogno di raggiungere via rete il CGI di gestione web, quindi tagliate quella raggiungibilità:

• Mettete la gestione degli switch su una VLAN di management dedicata e isolata, e consentite la UI web solo da un jump host o da una breve ACL amministrativa — non dalle subnet utente o guest.
• Disattivate la gestione web HTTP/HTTPS sugli switch amministrati in altro modo; usate la CLI su un canale controllato.
• Bloccate al confine del segmento l'accesso in ingresso alle porte di gestione dello switch per tutto ciò che non è la sorgente amministrativa.

Nessuno di questi corregge la falla; riducono l'insieme degli host che possono raggiungerla finché non applicate il firmware.

Caccia alla compromissione

Il comportamento pubblicato, mappato su MITRE ATT&CK, vi dà qualcosa da cercare. Lo sfruttamento è T1190 Exploit Public-Facing Application contro il CGI dello switch; dopo l'esecuzione di comandi, l'exploit scarica uno script collector dal server dell'attaccante via TFTP (T1105 Ingress Tool Transfer), che raccoglie configurazione del dispositivo, informazioni di rete e credenziali root in hash (T1552 Unsecured Credentials, T1005 Data from Local System) e deposita il bottino in una cartella leggibile via web sullo switch per il recupero. In concreto:

• Esaminate i log dello switch e i flow record a monte per connessioni avviate dallo switch stesso — in particolare TFTP in uscita, e qualunque sessione in uscita da un dispositivo che dovrebbe solo ricevere connessioni di gestione.
• Cercate accessi all'interfaccia di gestione da indirizzi sorgente fuori dal vostro intervallo amministrativo, e richieste HTTP al CGI con set di parametri anomalmente lunghi o malformati.
• Binarly ha collegato questa attività al backdoor JITTERLY e al rootkit SIXZUT e ha pubblicato gli hash SHA-256 di entrambi; prendete il set di IOC dall'advisory di Binarly e confrontatelo con i vostri log di egress. Attenzione: SIXZUT è un rootkit userland LD_PRELOAD costruito per nascondere file, processi e connessioni dagli strumenti sul dispositivo — quindi non fidatevi della vista che lo switch ha di sé stesso; cacciate dalla rete e dai log a monte, non dalla scatola.

Bonifica + verifica

Uno switch che ha eseguito comandi dell'attaccante e ha fatto trapelare la propria configurazione non è pulito una volta aggiornato, e un dispositivo che porta un rootkit LD_PRELOAD non può essere creduto quando riporta il proprio stato. Per ogni switch con segni di compromissione, scrivete il firmware corretto da un'immagine affidabile anziché aggiornare in place, e trattatelo come baseline. Poi: ruotate le credenziali admin e root dello switch e qualunque segreto condiviso (community SNMP, chiavi RADIUS/TACACS, token delle API di gestione) comparso nella configurazione rubata; considerate le credenziali root in hash come craccabili e ruotate tutto ciò che è riusato altrove; e rivedete la configurazione per modifiche non autorizzate — nuovi account admin, ACL alterate, porte in mirror. E se lo switch era su credenziali di fabbrica, date per scontato che l'attaccante non avesse nemmeno bisogno dell'exploit e allargate l'indagine. Infine, confermate la correzione come ha fatto Binarly: l'unica prova che la patch tiene è che l'exploit non gira più contro la build corretta.

Cosa non si sa ancora

• Se la campagna osservata sui GS1900 abbia usato CVE-2026-7273, il bypass CVE-2026-107441 o entrambi; le fonti primarie lasciano la questione aperta, e il conteggio di 996 dispositivi di GreyNoise era riferito al CVE più vecchio.
• La severità reale: NVD indica "Awaiting Analysis" senza punteggio base NIST, Zyxel dice 8.8 adiacente, Binarly dice 9.8 raggiungibile via HTTP in chiaro. Il vettore può cambiare dopo l'analisi.
• Se i CGI gemelli httprestorecfg.cgi e httpupload.cgi contengano la stessa routine di copia debole — dettaglio riportato da un'unica fonte secondaria, non ancora in un advisory primario.
• Se CISA aggiungerà CVE-2026-107441 al catalogo KEV a titolo proprio.

Provare la patch, non fidarsi

Il fallimento qui non è stato che uno switch aveva un bug — è stato che un'organizzazione credeva chiusa una vulnerabilità che non lo era, perché nessuno aveva rieseguito l'attacco contro il firmware corretto. È proprio il divario che un red team autonomo basato su AI è costruito per chiudere. Zero Hunt gira su un apparato on-premise con modelli privati propri, con un umano che approva ogni azione che conta: il motore generativo identifica prodotto e firmware esatti sotto test e, tramite l'Exploit Forge, itera una proof-of-concept eseguibile contro la vostra build installata finché non funziona in modo dimostrabile o non funziona in modo dimostrabile — lo stesso metodo con cui Binarly ha mostrato che la correzione di giugno era vuota, eseguito in continuo e in black-box contro il vostro perimetro invece che una volta l'anno. Quando un dispositivo come un GS1900 compare su un segmento, una campagna attivata dal cambiamento può testarlo entro un'ora.

Validazione e remediation chiudono il cerchio. Una volta provato che una falla è sfruttabile, l'AI Remediation Advisor la classifica per sfruttabilità reale, indica il firmware corretto esatto con note di rollout e rollback e un controllo compensativo per gli switch che non potete ancora aggiornare, e poi ri-verifica con la stessa prova che aveva dimostrato il problema — così "l'abbiamo corretta" diventa qualcosa da mostrare, non da sperare. Per le ragioni di residenza del dato che rendono l'on-prem il modello giusto per apparati come questi, vedi la nostra guida all'acquisto di piattaforme di pentest on-premise; per la falla più vecchia negli stessi switch, vedi la nostra nota su CVE-2026-7273.