NetStaX EtherNet/IP, buffer overflow critico nei kit Pyramid Solutions: aggiornare alla versione 5.6.1

Una vulnerabilità critica nello stack NetStaX EtherNet/IP di Pyramid Solutions può provocare corruzione della memoria e arrestare i dispositivi che lo integrano. Il problema, identificato come CVE-2026-78012, è sfruttabile attraverso la rete senza autenticazione e senza interazione dell’utente.

CISA ha pubblicato l’advisory il 3 settembre 2026, come ripubblicazione iniziale di una comunicazione di Pyramid Solutions. Sono interessate tutte le versioni precedenti alla v5.6.1 di otto kit EtherNet/IP, comprese le varianti con CIP Security.

Al momento dell’advisory non risultavano casi pubblicamente noti di sfruttamento mirato. La vulnerabilità non va però considerata marginale: ha un punteggio CVSS v3.1 di 9.8 su 10 e può essere attivata inviando una richiesta Class 3 di dimensioni superiori al buffer gestito dall’applicazione.

Otto kit EtherNet/IP vulnerabili prima della v5.6.1

CVE-2026-78012 riguarda il Pyramid Solutions NetStaX EtherNet/IP Stack. La condizione vulnerabile è presente in tutte le release anteriori alla v5.6.1 dei seguenti componenti:

• EtherNet/IP Adapter DLL Kit (EIPA): versioni precedenti alla v5.6.1;
• EtherNet/IP Adapter DLL Kit with CIP Security (EIPA-SECURE): versioni precedenti alla v5.6.1;
• EtherNet/IP Adapter Development Kit (EADK): versioni precedenti alla v5.6.1;
• EtherNet/IP Adapter Development Kit with CIP Security (EADK-SECURE): versioni precedenti alla v5.6.1;
• EtherNet/IP Scanner DLL Kit (EIPS): versioni precedenti alla v5.6.1;
• EtherNet/IP Scanner DLL Kit with CIP Security (EIPS-SECURE): versioni precedenti alla v5.6.1;
• EtherNet/IP Scanner Development Kit (ESDK): versioni precedenti alla v5.6.1;
• EtherNet/IP Scanner Development Kit with CIP Security (ESDK-SECURE): versioni precedenti alla v5.6.1.

La presenza di “Secure” nel nome non esclude il rischio. Le varianti dotate di CIP Security restano vulnerabili quando utilizzano una release dello stack inferiore alla soglia corretta.

Non è stato pubblicato un elenco più granulare di build interessate. Per verificare l’esposizione occorre quindi identificare il kit incorporato nel prodotto e controllare che la versione effettivamente distribuita sia almeno la v5.6.1.

Questo passaggio può richiedere il coinvolgimento del costruttore dell’apparato. NetStaX può infatti essere integrato all’interno di dispositivi industriali, senza necessariamente comparire con un nome evidente nelle interfacce di gestione o nell’inventario software.

Una richiesta Class 3 troppo grande supera il buffer

Il difetto è classificato come CWE-121, stack-based buffer overflow. Si trova nel percorso che gestisce le richieste Class 3 explicit-message di EtherNet/IP.

Un attore remoto può inviare una richiesta sufficientemente grande da oltrepassare il buffer di ricezione predisposto dall’applicazione. Il software non genera preventivamente un errore o un avviso capace di bloccare o segnalare correttamente la condizione.

La scrittura oltre i limiti del buffer può alterare la memoria dello stack. Gli effetti documentati comprendono:

• corruzione della memoria;
• crash o arresto del dispositivo;
• apertura di un possibile vettore di attacco remoto;
• mancata ricezione, da parte del dispositivo di origine, di un errore CIP che indichi la mancata elaborazione della richiesta.

L’ultimo elemento può complicare il monitoraggio. Il sistema che trasmette il messaggio anomalo potrebbe non ottenere una risposta d’errore coerente con il malfunzionamento avvenuto sul destinatario.

Non è invece confermata come conseguenza certa l’esecuzione di codice arbitrario. Il buffer overflow e la corruzione della memoria rendono il difetto grave, ma le informazioni disponibili non dimostrano che un aggressore possa trasformarlo in modo affidabile in esecuzione remota di codice.

Perché la vulnerabilità ha gravità critica

CISA assegna a CVE-2026-78012 un punteggio CVSS v3.1 di 9.8, con vettore:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

La valutazione descrive un attacco eseguibile via rete, a bassa complessità, senza privilegi preventivi e senza richiedere azioni a un operatore. Gli impatti potenziali su confidenzialità, integrità e disponibilità sono tutti considerati elevati.

Anche il punteggio CVSS v4.0 è critico: 9.3, con vettore:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

In termini operativi, la disponibilità è il rischio più immediato esplicitamente documentato. Un dispositivo industriale che si arresta dopo avere ricevuto un messaggio appositamente costruito può interrompere comunicazioni, supervisione o funzioni integrate nel processo.

Le conseguenze reali dipendono però dal ruolo del componente vulnerabile, dall’architettura dell’impianto e dalle protezioni di rete. Non sono stati resi noti modelli specifici di apparati finali che incorporano lo stack, né sono disponibili indicatori di compromissione associati a una campagna.

Impatto possibile negli ambienti industriali

I prodotti risultano distribuiti a livello mondiale. I settori critici indicati sono manifatturiero, energetico, idrico e delle acque reflue, e chimico.

In questi contesti, un crash non equivale soltanto alla perdita temporanea di un servizio informatico. Può rendere indisponibile un apparato di comunicazione industriale, richiedere un riavvio o costringere gli operatori ad attivare procedure di ripristino e continuità.

L’effettiva esposizione dipende soprattutto dalla raggiungibilità del servizio vulnerabile. Un sistema accessibile da reti non fidate, da segmenti aziendali poco separati o direttamente da Internet offre a un aggressore una superficie molto più ampia.

Pyramid Solutions ha segnalato il problema a CISA. Al momento della pubblicazione dell’advisory, l’agenzia non aveva ricevuto segnalazioni di sfruttamento pubblico specificamente diretto contro CVE-2026-78012.

Non è riportata l’inclusione della vulnerabilità nel catalogo Known Exploited Vulnerabilities (KEV) di CISA e non è indicata alcuna scadenza federale di correzione. Manca quindi, allo stato delle informazioni disponibili, la conferma operativa di uno sfruttamento attivo che l’ingresso nel KEV normalmente fornisce.

Aggiornamento e verifiche da eseguire

La correzione primaria consiste nel portare ogni kit interessato alla versione v5.6.1 o successiva. Non è stata resa nota una procedura universale di aggiornamento, perché le modalità possono dipendere dal prodotto che incorpora lo stack.

I responsabili OT e ICS dovrebbero partire dall’inventario degli asset, cercando sia il nome NetStaX sia le sigle EIPA, EIPA-SECURE, EADK, EADK-SECURE, EIPS, EIPS-SECURE, ESDK ed ESDK-SECURE. Dove la versione non è visibile, occorre richiedere conferma al fornitore del dispositivo o dell’applicazione.

Prima della distribuzione in produzione è opportuno valutare gli effetti dell’aggiornamento sul processo industriale, provarlo in un ambiente controllato e predisporre un piano di ripristino. La necessità di test operativi non dovrebbe però trasformarsi in un rinvio indefinito.

In assenza di un aggiornamento immediato, CISA raccomanda di ridurre la raggiungibilità dei sistemi interessati:

1. evitare l’esposizione diretta su Internet;
2. collocare dispositivi e reti di controllo dietro firewall;
3. separare le reti industriali dall’infrastruttura aziendale;
4. consentire soltanto i flussi strettamente necessari;
5. usare VPN aggiornate quando serve un accesso remoto;
6. applicare controlli di difesa in profondità agli asset ICS.

Una VPN non corregge il buffer overflow e non protegge un impianto se gli endpoint autorizzati sono già compromessi. Serve a restringere il percorso di accesso, non a sostituire la patch.

Che cosa cercare durante il monitoraggio

Non sono stati pubblicati indirizzi IP, firme di malware o altri indicatori associati allo sfruttamento. Il monitoraggio deve quindi concentrarsi sui comportamenti compatibili con il difetto.

Tra gli eventi da esaminare rientrano richieste Class 3 explicit-message insolitamente grandi, crash o riavvii non spiegati degli apparati EtherNet/IP e anomalie immediatamente successive alla ricezione di traffico da sistemi non abituali.

È utile anche correlare l’assenza di risposte CIP con arresti o instabilità del destinatario. Da sola, una risposta mancante non prova un attacco, ma può aiutare a ricostruire la sequenza che ha preceduto il guasto.

Eventuali attività sospette dovrebbero essere gestite attraverso le procedure interne di risposta agli incidenti. La priorità resta comunque chiara: identificare le integrazioni di NetStaX, limitare l’esposizione di rete e aggiornare almeno alla v5.6.1.