Il 22 ottobre 2026 HPE ha pubblicato il bollettino di sicurezza HPESBNW05162, che raccoglie correzioni per 72 vulnerabilità nel sistema operativo di rete AOS-8 e AOS-10, quello che gira su controller wireless, gateway, Mobility Conductor e access point Aruba. Il dato che fa notizia è la gravità: otto delle falle ricevono il punteggio CVSS 10.0, il massimo possibile, e diverse permettono l'esecuzione di codice da remoto senza alcuna autenticazione. Al momento della pubblicazione non risultano sfruttamento attivo né exploit pubblici, ma è proprio questa la finestra in cui conviene muoversi.

Cosa è successo

Secondo le ricostruzioni di più testate di settore, le otto CVE con punteggio massimo sono le seguenti:

  • AOS-10: CVE-2026-79844 (bypass di autenticazione che può portare a esecuzione di codice, a determinate condizioni), CVE-2026-79845 (bypass di autenticazione nel protocollo di gestione PAPI), CVE-2026-79847 e CVE-2026-79851 (buffer overflow non autenticati con esecuzione di codice).
  • AOS-8: CVE-2026-79846 (command injection non autenticata, anch'essa subordinata a precondizioni), CVE-2026-79848 e CVE-2026-79849 (SQL injection non autenticate che arrivano all'esecuzione di comandi), CVE-2026-79850 (bypass di autenticazione con esecuzione di codice).

A queste si aggiunge la CVE-2026-79852, una SQL injection nell'interfaccia web di gestione valutata 9.8, che riguarda entrambe le linee. Per le CVE-2026-79844 e 79846 HPE precisa che lo sfruttamento richiede "precondizioni fuori dal controllo dell'attaccante", senza dire quali siano: un'indicazione che non va letta come rassicurante, perché non permette di capire se la propria configurazione sia esposta.

Un'avvertenza di metodo: le fonti non concordano su tutti i dettagli. I conteggi tra falle "critiche" e "alte" variano da un articolo all'altro (32 o 34 critiche), e il record pubblico della CVE-2026-79845 risulta, al momento, associato a un prodotto non correlato; per questa vulnerabilità il riferimento è quindi il solo bollettino HPE. Per la stessa ragione conviene sempre verificare il testo originale del bollettino prima di pianificare l'intervento.

Versioni coinvolte e correzioni

Le versioni corrette indicate nel bollettino sono:

  • AOS-10: 10.8.1.2, 10.7.2.7, 10.4.1.14 (sono vulnerabili i rilasci precedenti fino a 10.8.1.1, 10.7.2.6 e 10.4.1.13);
  • AOS-8: 8.13.3.1 e 8.10.0.24 (vulnerabili fino a 8.13.3.0 e 8.10.0.23).

I rami giunti a fine manutenzione (End of Maintenance) vanno considerati vulnerabili ma non sono coperti dal bollettino; quelli a fine supporto non sono stati nemmeno valutati da HPE. In entrambi i casi l'unica strada è la migrazione a un ramo supportato.

Sfruttamento: cosa sappiamo e cosa no

HPE dichiara di non essere a conoscenza di discussioni pubbliche o di codice di exploit alla data del bollettino, e al 25 ottobre nessuna delle 72 CVE compare nel catalogo CISA dei Known Exploited Vulnerabilities. Chi si occupa di sicurezza sa però cosa succede dopo la pubblicazione di una patch: gli attaccanti analizzano la differenza tra firmware vecchio e nuovo (patch diffing) e ricostruiscono la falla. Per vulnerabilità non autenticate su apparati di rete, il tempo tra bollettino e primi exploit funzionanti si misura spesso in giorni o poche settimane. Dire "non sfruttata" oggi significa solo che la finestra di vantaggio dei difensori è ancora aperta.

Cosa significa per le aziende italiane

Gli apparati Aruba sono molto diffusi in Italia: reti wireless di aziende medie e grandi, ospedali e strutture sanitarie, atenei, enti locali, hotel, catene retail e sedi distribuite delle PMI, spesso installati e gestiti da system integrator esterni. Questo produce tre rischi concreti.

Il primo è la visibilità: molte organizzazioni non hanno un inventario aggiornato dei controller e delle versioni AOS in esercizio, perché la rete wireless "funziona" e nessuno la guarda. Non si può correggere ciò che non si sa di avere. Il secondo è il ruolo dell'apparato: un controller o un gateway compromesso non è un semplice access point, è un nodo che vede il traffico di più segmenti e può fungere da trampolino verso la rete interna. Il terzo è l'esposizione dei servizi di gestione: se PAPI (UDP 8211) o le interfacce web e CLI sono raggiungibili da reti non fidate, per esempio la rete guest o, peggio, Internet, il rischio passa da teorico a immediato.

Sul piano normativo, per i soggetti che rientrano nel perimetro NIS2 (D.lgs. 138/2024) la gestione tempestiva delle vulnerabilità e la sicurezza della rete rientrano tra le misure di gestione del rischio che l'autorità può verificare. Un apparato critico lasciato non aggiornato dopo un bollettino di questa portata sarebbe difficile da giustificare in sede di vigilanza o dopo un incidente. Se poi un attacco portasse a una violazione di dati personali, scatterebbe anche la notifica al Garante entro 72 ore ai sensi dell'art. 33 GDPR, e una mancata applicazione di patch note sarebbe un elemento valutato nella verifica delle misure tecniche adeguate (art. 32 GDPR). Resta il fatto che queste valutazioni dipendono dal caso concreto: non è una conseguenza automatica.

C'è infine un aspetto organizzativo, tipico del contesto italiano: quando l'infrastruttura è gestita da un fornitore, la responsabilità dell'aggiornamento è spesso ambigua. Conviene chiedere per iscritto al partner se ha letto il bollettino, quali apparati sono coinvolti e con quale data prevede l'intervento.

Cosa fare subito

  • Censire tutti i dispositivi AOS-8 e AOS-10 (Mobility Conductor, controller, gateway, access point) e annotare la versione in esecuzione.
  • Aggiornare alle versioni corrette indicate da HPE, dando priorità ai sistemi raggiungibili da reti meno fidate; i gateway gestiti tramite HPE Networking Central richiedono un aggiornamento avviato dall'utente, quindi vanno verificati a parte.
  • Se l'aggiornamento non è immediato, confinare CLI e interfaccia web di gestione in una VLAN o segmento layer 2 dedicato e/o dietro policy firewall, come indicato da HPE.
  • Filtrare il traffico PAPI (UDP 8211) in modo che sia raggiungibile solo dai dispositivi Aruba legittimi, e verificare che nessuna interfaccia di gestione sia esposta su Internet.
  • Controllare i log di amministrazione alla ricerca di accessi, modifiche di configurazione o nuovi account non riconosciuti, e attivare l'accounting dei comandi dove possibile.
  • Se si usano rami a fine manutenzione o fine supporto, pianificare subito la migrazione: non riceveranno questi aggiornamenti.
  • Seguire i canali di CISA e di CSIRT Italia: se una delle CVE entrasse nel catalogo KEV, la priorità passerebbe da alta a emergenza.

In sintesi

Non c'è, per ora, evidenza di attacchi in corso, e va detto chiaramente. Ma otto falle a punteggio massimo su apparati di rete così diffusi, alcune sfruttabili senza credenziali, sono il tipo di bollettino che separa chi ha un processo di gestione delle patch da chi si affida alla fortuna. Il tempo per intervenire con calma è breve.