Zyxel GS1900 CVE-2026-7273: RCE non autenticata, ora sfruttata in the wild

Il 21 settembre 2026 CISA ha aggiunto CVE-2026-7273 al proprio catalogo Known Exploited Vulnerabilities, con scadenza per le agenzie federali fissata al 24 settembre. La falla è un buffer overflow su stack nel programma CGI di web management della serie GS1900 di Zyxel — switch smart-managed venduti a centinaia di migliaia nelle reti piccole e medie. Un attaccante adiacente alla LAN, non autenticato, invia una singola richiesta HTTP costruita ad hoc ed esegue comandi di sistema operativo sullo switch.

Zyxel ha rilasciato la patch a giugno. L'advisory porta la data del 16 giugno 2026. Tre mesi dopo, gli attaccanti la stanno usando e CISA impone una scadenza. Quel divario — patch pubblicata in estate, sfruttamento confermato in autunno — è tutta la storia, ed è una storia che si ripete ogni anno sugli apparati di rete embedded.

Che cosa è davvero CVE-2026-7273

Zyxel la descrive senza giri di parole: "un buffer overflow su stack nel programma CGI del firmware degli switch della serie Zyxel GS1900 potrebbe consentire a un attaccante LAN, non autenticato, di sfruttare la falla ed eseguire potenzialmente comandi OS tramite una richiesta HTTP costruita ad hoc." Il punteggio base CVSS 3.1 è 8.8.

Scomponendo quella frase, ogni clausola è una cattiva notizia:

• Programma CGI — il codice vulnerabile è l'interfaccia HTTP di gestione dello switch, la stessa web UI in cui accede l'amministratore. È raggiungibile da chiunque possa aprire una sessione TCP verso l'IP di management.
• Buffer overflow su stack — una primitiva classica di corruzione di memoria. Su uno switch embedded MIPS/ARM privo di mitigazioni moderne (niente ASLR significativo, spesso niente stack canary, con il web server frequentemente eseguito come root), un overflow nel parser delle richieste è una via diretta all'esecuzione di codice.
• Non autenticato — nessun login, nessuna sessione, nessuna credenziale. L'overflow scatta prima dell'autenticazione.
• Esegue comandi OS — non un crash, non una modifica di configurazione. Controllo a livello di shell sull'apparato.

I ricercatori non hanno pubblicato codice proof-of-concept, e l'inserimento in KEV di CISA segnala sfruttamento attivo pur in sua assenza. Vale la pena fermarsi su questa combinazione: qualcuno ha fatto reverse engineering della patch di giugno, ha costruito un exploit funzionante e lo sta usando privatamente, mentre il resto del settore non ha un PoC pubblico su cui testare le rilevazioni. Lo sfruttamento è davanti alla curva di divulgazione pubblica, non dietro.

"LAN-based" non è la rassicurazione che sembra

Il vettore CVSS marca la falla come adiacente (AV:A), non remota di rete, e la reazione istintiva è il sollievo: l'attaccante deve già essere sulla mia LAN, quindi sono al sicuro dietro il firewall. Quel ragionamento è esattamente la falla che gli attaccanti monetizzano, ed è il motivo per cui un punteggio CVSS grezzo dice quasi nulla sulla tua esposizione reale.

"LAN-based" descrive la posizione dell'attaccante, e nel 2026 quella posizione costa poco. Pensa a chi è già seduto sullo stesso dominio di broadcast o su una VLAN adiacente ai tuoi switch di accesso:

• Un portatile compromesso che ha cliccato la fattura sbagliata.
• Una telecamera IP, un lettore di badge, un telefono VoIP, una stampante — la popolazione IoT non gestita che vive sulle porte degli switch ed è un serbatoio permanente per Mirai.
• Una VLAN "guest" o "IoT" che doveva essere isolata ma condivide la subnet di management dello switch perché in fase di deployment qualcuno aveva fretta.
• La web UI stessa dello switch, esposta deliberatamente per l'amministrazione remota. Durante la campagna del 2023 contro i firewall Zyxel, Rapid7 contò circa 42.000 interfacce web Zyxel esposte su internet — gli amministratori espongono questi apparati di continuo.

La vera domanda che pone CVE-2026-7273 non è quindi "il mio switch è su internet?". È: qualcosa di cui non mi fido pienamente può raggiungere la CGI di management dello switch? È una domanda di segmentazione di rete, e la maggior parte delle organizzazioni non sa rispondere con prove alla mano. Hanno un diagramma di VLAN che descrive un'intenzione. Se la configurazione in esecuzione su ogni switch imponga davvero quel diagramma — se il management plane sia realmente irraggiungibile dalla VLAN delle telecamere — è un fatto diverso, e si conosce solo mettendolo alla prova.

"I server li abbiamo patchati." "Qualcuno ha patchato gli switch?" "…gli switch hanno un'interfaccia web?"

Quella terza battuta è dove si arena la maggior parte delle chiamate d'emergenza. Gli switch sono infrastruttura; l'infrastruttura è invisibile finché non diventa il punto di pivot.

Perché rootare uno switch è peggio che rootare un server

Un server è una destinazione. Uno switch è il tessuto su cui viaggia tutto il resto, e l'esecuzione di codice su di esso consegna all'attaccante capacità che nessun controllo basato su host può vedere:

Capacità dopo RCE sullo switch	Cosa ci fa l'attaccante
Port mirroring / SPAN	Copia in silenzio ogni pacchetto che attraversa lo switch verso una porta controllata — credenziali, token, traffico interno in chiaro.
Riconfigurazione VLAN	Fa collassare la segmentazione costruita. La VLAN OT o dei dati di carta "isolata" diventa instradabile verso l'attaccante.
Modifica ACL / route statiche	Redirige o intercetta il traffico (man-in-the-middle); disabilita proprio il filtraggio pensato per contenerlo.
Persistenza a livello firmware	Sopravvive ai riavvii e vive sotto ogni agente EDR, che gira sugli host, non sullo switch.

Su un GS1900 non c'è alcun agente endpoint. Non c'è telemetria EDR, non c'è cattura di memoria semplice, non c'è un'immagine forense immediata. L'apparato che di norma farebbe parte del tuo monitoraggio diventa un punto cieco nel momento in cui viene posseduto — e poiché vede tutto il traffico, è il luogo ideale da cui osservare e da cui fare pivot.

CVE-2026-7273 patchata a giugno, sfruttata a settembre: il pattern dell'embedded

Nulla di tutto ciò è inedito, ed è proprio il punto. L'hardware Zyxel è una base fissa per le botnet da anni. CVE-2023-28771, una falla di command injection non autenticata nei firewall Zyxel, fu sfruttata in massa da una variante Mirai a poche settimane dalla divulgazione e arruolò migliaia di apparati in una botnet DDoS. Gli apparati di rete embedded sono attraenti proprio perché vengono patchati raramente: nessun aggiornamento automatico, un flash del firmware manuale che rischia di bloccare uno switch che nessuno vuole toccare in orario di lavoro, e un parco installato che comprende unità montate in rack anni fa e dimenticate.

Il ritardo di tre mesi tra l'advisory Zyxel di giugno e lo sfruttamento confermato di settembre è la finestra di patching dei difensori, e si è chiusa mentre la maggior parte di questi switch era ferma al firmware di fabbrica. È anche il pattern che la direttiva BOD 26-04 di CISA — la direttiva risk-based che nel 2026 ha sostituito la regola fissa dei 14 giorni sul KEV — è pensata per comprimere: gradua l'urgenza della remediation in base alle prove di sfruttamento anziché al solo CVSS, e una RCE non autenticata attivamente sfruttata su infrastruttura di rete finisce nella fascia più rapida. Il motivo per cui la direttiva è dovuta cambiare è lo stesso per cui questo CVE conta: un 8.8 che a giugno nessuno sfruttava è un 8.8 che ora sì, e il punteggio non si è mai mosso.

Remediation

Un runbook difensivo completo per CVE-2026-7273. Esegui il controllo di esposizione e la caccia alla compromissione anche se applichi la patch subito — uno switch rimasto per tre mesi su firmware vulnerabile va trattato come possibilmente già toccato, non come semplicemente da aggiornare.

1. Sono interessato?

Inventaria ogni switch Zyxel GS1900 e leggine il firmware in esecuzione dalla web UI (System → General Setup mostra la stringa firmware) o, con accesso seriale/console, dal banner di boot. Confronta con la lista dei modelli sotto. Qualsiasi GS1900 su firmware 2.90(...).1C0 o precedente è vulnerabile. Se non riesci a enumerare i tuoi switch, quello è il reperto numero uno — uno switch non gestito è esattamente l'apparato che resta al firmware di fabbrica.

Dall'esterno, conferma che nessuna interfaccia di management GS1900 risponda da una rete non fidata. Da fuori della VLAN di management:

# Il management HTTP/HTTPS NON dovrebbe rispondere da un segmento utente/IoT/guest
curl -sk --max-time 5 https://<ip-mgmt-switch>/ -o /dev/null -w "%{http_code}\n"
# Tratta qualsiasi 200/302/401 raggiungibile da un segmento non fidato come
# un'esposizione da correggere, indipendentemente dalla patch.

2. Patch — versioni corrette esatte

Il firmware corretto di Zyxel, per modello (dall'advisory del 16 giugno 2026):

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

Verifica la stringa firmware dopo il flash; su uno switch embedded un aggiornamento fallito o applicato a metà fallisce in silenzio.

3. Non puoi patchare subito? Controlli compensativi

L'overflow è nella CGI di web management, quindi l'intera superficie di esposizione è la raggiungibilità del management plane:

• Limita l'accesso di management a una VLAN di management dedicata e isolata, con una ACL che consenta solo gli host amministratori noti. È il controllo singolo più efficace, ed è un controllo che dovresti mantenere anche dopo la patch.
• Disabilita il web management HTTP/HTTPS dove lo switch è amministrabile per altre vie, oppure vincolalo alla sola interfaccia di management.
• Blocca gli IP di management dello switch dalle VLAN IoT, guest, stampanti/telecamere e utenti al confine di livello 3. All'attaccante serve raggiungere la CGI; negagli il percorso.
• Applica rate-limit / drop al traffico HTTP anomalo verso gli IP di management su un firewall a monte, se lo switch deve restare web-managed.

4. Caccia alla compromissione

Non c'è EDR sullo switch, quindi la caccia parte dalla rete e dallo stato dello switch stesso:

• Drift di configurazione — confronta la config in esecuzione di ogni switch con una baseline nota-buona. Cerca sessioni di mirroring (SPAN) nuove/inattese, appartenenza VLAN o config di trunk modificate, route statiche nuove, ACL di management alterate e nuovi account locali. Una sessione SPAN abusiva è l'indizio più chiaro che qualcuno sta esfiltrando traffico (contesto ATT&CK T1200; T1040 network sniffing).
• Egress dagli IP di management dello switch — uno switch non dovrebbe quasi mai iniziare connessioni in uscita verso internet. Qualsiasi beacon, connessione verso un ASN mai visto o burst DNS originato da un IP di management è ad alto segnale (ATT&CK T1071 C2, T1571 porta non standard).
• Riavvii inattesi / anomalie firmware — gli exploit di corruzione di memoria sono inaffidabili e spesso mandano in crash il servizio; uno switch con riavvii inspiegati attorno alla finestra di sfruttamento merita attenzione.
• Comportamento da botnet — scansioni in uscita sostenute o SYN flood originati dall'IP dello switch indicano che è stato arruolato (il pattern Zyxel/Mirai; ATT&CK T1498 dal punto di vista della botnet).

Mappa l'intrusione come T1190 (sfruttamento di applicazione esposta / raggiungibile) → esecuzione comandi OS → persistenza a livello firmware T1542 e cattura del traffico T1040.

5. Bonifica + verifica

• Prima la patch, poi tratta l'apparato come non fidato finché non è provato pulito.
• Reset di fabbrica e ri-flash di ogni switch che mostra indicatori — sull'embedded una patch non rimuove un impianto, e la persistenza a livello firmware può sopravvivere a un semplice upgrade. Riporta ai default, applica il firmware corretto e ricostruisci la configurazione dalla tua baseline, non dalla config in esecuzione dello switch (che l'attaccante può aver modificato).
• Ruota tutto ciò che lo switch può aver visto o custodito: credenziali admin locali dello switch, community string SNMP, secret condivisi RADIUS/TACACS configurati su di esso e — poiché una sessione SPAN abusiva può averle catturate — credenziali e token transitati in chiaro attraverso di esso.
• Ri-verifica la segmentazione dopo la ricostruzione: conferma che il management plane sia irraggiungibile da ogni VLAN non fidata e che non resti alcuna sessione di mirroring o route che non hai creato tu.

La raggiungibilità è tutta la domanda — ed è testabile

Tutto quanto sopra si riduce a una domanda operativa a cui il punteggio CVSS non può rispondere per te: dal punto in cui un attaccante atterra davvero — un portatile phishato, una telecamera Mirai, una VLAN guest — può raggiungere la CGI di management del tuo GS1900 sulla tua configurazione in esecuzione? Uno scanner di vulnerabilità ti dice la versione del firmware. Non ti dice se il percorso esiste. Solo percorrerlo lo dice.

È il divario operativo che il pilastro AI Generative Pentest di Zero Hunt è costruito per chiudere. Lo sciame di 10 agenti non si ferma al fingerprinting di una stringa firmware; gli agenti Post-Exploit e Pivot prendono un foothold realistico a basso privilegio — l'esatta posizione da VLAN-telecamere o endpoint-compromesso che CVE-2026-7273 presuppone — e provano se il management plane dello switch è raggiungibile da lì, sulla tua topologia reale, non su un diagramma. L'agente Exploit scrive una probe per-target con un LLM locale anziché scaricare un PoC pubblico che, per questo CVE, non esiste ancora. Ogni passo è backtestato nell'AI Gym contro il corpus di CVE di Vulhub prima di girare in produzione, e ogni reperto è firmato ECDSA al momento della scrittura, così l'output è "ecco da quale segmento questo switch era raggiungibile, ed ecco la prova", non un 8.8 rimandato su un foglio di calcolo. Una campagna change-triggered parte entro l'ora quando una nuova interfaccia di management compare sul perimetro — che è esattamente il modo in cui uno switch non gestito e "che non doveva essere raggiungibile" viene colto prima che lo scanner di una botnet lo trovi per primo.

E poiché uno switch rootato possiede i propri log — può azzerare il buffer degli eventi e riscrivere la config con la stessa facilità con cui un attaccante abilita una sessione SPAN — l'attività post-exploitation si legge in modo più affidabile dal traffico. Il modello di AI Traffic Analysis di Zero Hunt, con quattro teste di inferenza sulla GPU dell'appliance a oltre 2,7 Gbit/s, segnala il beacon verso un ASN mai visto, l'egress anomalo da un IP che dovrebbe solo commutare traffico e la scansione in uscita di un nodo botnet appena arruolato — mentre accade, non nel digest SIEM del mattino dopo, e da un punto di osservazione che lo switch compromesso non può modificare.

Lo switch è la rete. Quando può essere preso con una singola richiesta non autenticata, "i server li abbiamo patchati" non è una risposta. Saperlo — con le prove — che cosa può raggiungerlo, sì.