• Passa al contenuto principale
  • Skip to header right navigation
  • Skip to site footer
Fabbri Enrico

Fabbri Enrico

Appunti, idee, qualsiasi cosa possa servire

  • IT
    • MacOS
    • Windows
    • Synology
    • Networking
    • Ubiquiti
    • Storage
    • Web
    • VMWare
  • Le mie passioni
    • Tesla
    • Apple
    • DJI
    • BMW GS
    • Bambu Lab
    • Xbox
  • Contatti
Cavi di rete grigi collegati alle porte di uno switch con i LED di attività accesi

HPE Aruba AOS-8 e AOS-10: otto vulnerabilità critiche, le versioni da installare

Articolo aggiornato al 25 ottobre 2026. La situazione è ancora in evoluzione: lo aggiornerò se HPE rilascia nuove correzioni o revisioni del bollettino.

Se in azienda avete access point Aruba Instant, un controller Aruba o dei gateway gestiti da HPE Aruba Networking Central, questo è uno di quei fine settimana in cui conviene aprire la console e controllare la versione del firmware. Dal lato utente non si vede niente: il Wi-Fi funziona, i client si collegano, nessun allarme. Ed è proprio questo il punto.

Il 22 ottobre HPE ha pubblicato il bollettino HPESBNW05162, che corregge 72 vulnerabilità in ArubaOS 8 e ArubaOS 10. Otto hanno punteggio CVSS 10.0, il massimo: bypass dell’autenticazione, command injection, SQL injection e buffer overflow che portano all’esecuzione di codice da remoto senza credenziali e senza interazione dell’utente. Al momento HPE dichiara di non essere a conoscenza di exploit pubblici o di attacchi in corso, ma con difetti di questo tipo è questione di giorni, non di mesi.

Chi è coinvolto

Il bollettino riguarda i dispositivi che eseguono AOS-8 e AOS-10:

  • access point Instant con AOS-8 (i classici IAP in cluster con Virtual Controller, molto diffusi nelle PMI);
  • Mobility Conductor e Mobility Controller con AOS-8;
  • access point e gateway con AOS-10 gestiti da HPE Aruba Networking Central.

Non sono coinvolti gli switch con AOS-CX né la linea Aruba Instant On, quella che si gestisce dall’app e che spesso si trova negli uffici più piccoli: sono prodotti con un sistema operativo diverso.

Queste sono le versioni vulnerabili e quelle corrette indicate nel bollettino:

  • AOS-10.8: vulnerabile fino a 10.8.1.1, corretta in 10.8.1.2;
  • AOS-10.7: vulnerabile fino a 10.7.2.6, corretta in 10.7.2.7;
  • AOS-10.4: vulnerabile fino a 10.4.1.13, corretta in 10.4.1.14;
  • AOS-8.13: vulnerabile fino a 8.13.3.0, corretta in 8.13.3.1;
  • AOS-8.10: vulnerabile fino a 8.10.0.23, corretta in 8.10.0.24.

Attenzione: i rami fuori manutenzione (per esempio AOS-8.11, AOS-8.9 e precedenti, AOS-10.5 e precedenti) non sono stati valutati da HPE e non riceveranno correzioni, quindi vanno considerati vulnerabili. Per AOS-8.12 il bollettino non prevede una build corretta: la strada è passare a 8.13.3.1 o successiva.

Perché è grave

Le otto vulnerabilità critiche vanno da CVE-2026-79844 a CVE-2026-79851. Diverse colpiscono le interfacce di gestione, altre il protocollo PAPI, quello che access point e controller usano per parlarsi e che viaggia sulla porta UDP 8211. In una rete piatta, dove la gestione degli AP è raggiungibile da qualunque PC della LAN o, peggio, dalla rete ospiti, basta un dispositivo compromesso per arrivare al controller del Wi-Fi aziendale.

Una nota per chi tiene traccia delle CVE: in questi giorni alcuni database pubblici associano CVE-2026-79845 a una vulnerabilità diversa. Io vi consiglio di fare riferimento al bollettino HPE, che resta la fonte autorevole.

Prima di iniziare

Un aggiornamento firmware del Wi-Fi comporta il riavvio degli access point, quindi pianificatelo in un orario in cui l’assenza di rete wireless non blocca nessuno. Prima di toccare qualcosa:

  • salvate una copia della configurazione: sui cluster Instant da Maintenance → Configuration → Backup Configuration, sui controller AOS-8 da Maintenance → Configuration Management → Backup;
  • scaricate dal portale HPE Networking Support il firmware esatto per il vostro modello e il vostro ramo, e leggete le release notes: se un modello di AP vecchio non è supportato dalla nuova versione, meglio scoprirlo adesso;
  • verificate di avere accesso alla console anche via cavo o via rete cablata, nel caso il Wi-Fi non torni su.

Come verificare la versione e aggiornare

  1. Controllate la versione in uso. Dall’interfaccia web la trovate nella pagina iniziale del Virtual Controller o del controller; da CLI, collegandovi in SSH (qui con un indirizzo di esempio):
ssh [email protected]
show version
  1. Confrontate la versione con l’elenco qui sopra. Se siete su un ramo supportato, restate sullo stesso ramo e installate la build corretta: è il salto più breve e meno rischioso.
  2. Sui cluster Instant AOS-8 aggiornate dal Virtual Controller in Maintenance → Firmware: caricate l’immagine o indicate l’URL e lasciate che il cluster aggiorni tutti gli AP. Sui controller AOS-8 usate Maintenance → Software Management → Upgrade, caricando l’immagine sulla partizione non attiva, così la versione precedente resta disponibile per un rientro.
  3. Per AP e gateway AOS-10 l’aggiornamento passa da HPE Aruba Networking Central, nella sezione di gestione del firmware: scegliete la versione corretta per il gruppo di dispositivi e pianificate l’installazione.
  4. A riavvio completato rieseguite show version, verificate che tutti gli AP siano tornati online e fate una prova di connessione su ogni SSID, compresi quelli con autenticazione 802.1X.

Se non potete aggiornare subito

Le mitigazioni non sostituiscono la patch, ma riducono molto la superficie di attacco nel frattempo. Sono le stesse che HPE suggerisce da tempo e che io applico comunque, patch o non patch:

  • spostate le interfacce di gestione (web e SSH) su una VLAN di management dedicata e filtratene l’accesso sul firewall, consentendolo solo alle postazioni degli amministratori;
  • limitate il traffico PAPI (UDP 8211) ai soli peer previsti, cioè le subnet degli AP e i controller; nei cluster Instant valutate anche UDP 8209;
  • verificate che la rete ospiti non possa raggiungere in nessun modo gli indirizzi di gestione degli AP;
  • attivate il logging dei comandi e l’invio dei log a un server syslog centrale, per avere traccia di accessi anomali.

Se avete apparati fuori supporto

È il caso più scomodo, ma nelle PMI è frequente: AP comprati anni fa, fermi su un ramo che non riceve più aggiornamenti. Qui non c’è firmware che tenga: le mitigazioni descritte sopra diventano l’unica difesa e la sostituzione va messa a budget il prima possibile. Sconsiglio di rimandarla al prossimo esercizio: un controller Wi-Fi con esecuzione di codice da remoto non autenticata è un punto di ingresso perfetto nella rete interna.

Avete già aggiornato i vostri cluster Instant o i controller? Raccontate nei commenti come è andata e se avete trovato modelli di AP non più supportati: possono essere utili ad altri.

Enrico Fabbri

Enrico Fabbri, classe 1989, appassionato da sempre da tutto ciò che circonda il mondo della tecnologia.
Se una cosa funziona, sento la necessità di scoprire come e perché.

Post precedente:Primo piano dell'interno di un disco rigido con il piatto e la testina di letturaPHP2Shell sui NAS Synology e QNAP: pacchetti da aggiornare e mitigazioni

Interazioni del lettore

Lascia un commento Annulla risposta

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito utilizza Akismet per ridurre lo spam. Scopri come vengono elaborati i dati derivati dai commenti.